- [Voiceover] 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 series of prefixes
that look 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.
Well, 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.
Now typically, each vendor prefix
includes an abbreviation representing
the browser manufacturer
which is surrounded on each side
by a dash and followed by the property
that they're going to support.
Now 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're a 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 the 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 is 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 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 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 lines
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 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 tradeoff.
Their prefixes allow us to use properties
before they're finalized,
but they also result in a fair amount
of additional code and a 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
to 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.