Easy-to-follow video tutorials help you learn software, creative, and business skills.Become a member
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.
Get unlimited access to all courses for just $25/month.Become a member
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.
Your file was successfully uploaded.