As you learn CSS, you'll often see examples of code with some very curious syntax.
In front of the CSS properties, you'll often see a prefix, or a series of prefixes,
that looks something like this. So, what are those?
Those are vendor prefixes, and they can seem a little confusing the first
time you run into them,
especially since they seem to set the same rule multiple times.
Vendor prefixes allow browser manufacturers to add support for proprietary
features or features that are still in development.
You might have noticed, for example, that the prefixes all correspond with a
browser or browser developer.
And typically, each vendor prefix includes an abbreviation representing the
browser manufacturer, which is surrounded on the side by a dash and followed by
the property that they are going to support.
And here's a list of some of the more common vendor prefixes.
We have Microsoft, Mozilla, Opera, Konqueror, and WebKit.
Now, at first glance, it may seem like vendor prefixes tend to confuse things,
but in reality they are very important part of the evolution of CSS.
Remember, CSS is still a work in progress.
Many of the new features are still being standardized and refined.
During this process, browser developers may choose to implement these features
a little bit early.
Now, this could be the result of them wanting to experiment with the best
implementation method or a desire to drive a feature forward to improve the
browser's capabilities.
This means that we've reached a point where modern browsers will offer support
for features that may see significant changes in how those features are
supported or implemented down the line.
Now, this actually a good thing for designers, as we get to start using these new
features much earlier than we would have in the past.
This early adoption also creates a very dangerous situation, where the same code
could behave differently between browsers or even between the later versions of
the same browser based on those implementation changes.
This is why we need vendor prefixes. By using them, browser developers can support
implementations that are experimental without breaking valid syntax.
Once implementations have been solidified or the property specification is
finished, the prefix can then be safely dropped.
This will keep older code from failing if the implementation of the property
changes between now and then.
To give you an example of this, I want to talk about the history of browser
support for CSS gradients.
Mozilla and WebKit both started supporting gradients while the syntax was still
being developed. At first, WebKit and Mozilla decided to take different approaches
to the syntax of gradients,
meaning that to create the same gradient in both the browsers you had to know
the differences in syntax between them.
As of early 2011, WebKit changed its syntax to more closely match the shape the
syntax was taking in the specification, which put its syntax in line with how
Mozilla was developing it.
Now this can lead to extremely convoluted code, such as this example.
If I want to create a simple black-to-white gradient that works across multiple browsers,
I'll need this line as a fallback for unsupported devices, this for support in
older WebKit browsers, this for support in Firefox, this for support in recent
WebKit browsers, this line for support in Opera, and this one for Internet
Explorer, and I'll also need to include these filters if I want to support older
versions of Internet Explorer.
Now finally, I'll add this code
that's based on the specification for when user agents decide to go ahead
and drop the prefix.
On the surface, this seems like a huge pain, but imagine if we didn't have those prefixes.
It would mean that as browsers begin to implement these features, our syntax
would break in the some browsers and not in others, or be rendered differently
depending upon which browser our viewers were using.
By using vendor prefixes, we get to decide which features we want to add without
breaking our design.
Now, essentially they give designers a bit of a trade-off.
There prefixes allow us to use properties before they're finalized, but they
also result in a fair amount of additional code and the steeper learning curve
in terms of mastering the syntax.
Basically, if you're interested in using many of the CSS3 modules now,
you'll need to learn these prefixes and when to use them.
A little bit later on, I'll introduce you some online tools that can
make generating the syntax and keeping track of their changes a little easier.
Just don't lose sight of the fact that, as a designer, the responsibility for keeping
up with those changes lies with you.