Table XI

Stop Worrying about Vendor Prefixes

The rise of web standards made authoring CSS easier than ever. However, the browser vendors wanted to move quicker. Their solution was to implement features before the standard was finalized using a vendor prefix for the property.

.awesome-new-property {
  -webkit-standard: use-me;
  -moz-standard: or-me;
  -ms-standard: dont-leave-me-out;
  -o-standard: please-download-me;
  standard: not-yet-finalized;
}

It gave us a way to start using these properties while ensuring that our code didn't break as browsers eventually implemented the finalized specs. Doesn't mean it wasn't a pain. The good news is that we don't have to worry about it anymore. Here's a quick video I put together talking more about the history of the issue and a new tool, Autoprefixer, that we're using so we don't have to worry about it anymore.

Transcript

Mike Gibson:

[Slide 1 - 0:00] Hey, it's another edition of XI to Eye. I'm Mike Gibson. I am a designer here at Table XI, and I'm pretty excited. I'm going to be checking in every now and then to tell you all about some tips, tricks, and techniques that we're using here to make better work faster.

[Slide 2 - 0:17] Today we're going to be talking about CSS. As a designer I've been writing CSS for quite some time now. Most days I spend most of my time writing CSS along with HTML. One of the most important tools to what I do, and there's a new tool we've come across recently that's actually changing how I write it, but CSS itself has changed quite a bit over time. Let's go back in time a little bit to when I was first starting to write and design websites.

[Slide 3 - 0:53] We saw this a lot. We saw the dreaded "enter site link." I thought this was crazy. We were already on the site. Why do we need to enter it? Aren't we already there? That's an aside. If we dug into the code a little bit and started looking at how this link was created, how the colors were added beyond just the typical blue, red, and purple...

[Slide 4 - 1:19] ...we would see something like this after digging through loads and loads of tables and nested tables and table cells and way too many "Ts" to even exist in HTML. We would see something like this. We'd see the link tag with attributes on that tag that would have the coloring values on there, the link, the a link, the v link. I didn't even know what v link was when I first saw it, but I saw that other people were doing it so I just kind of threw in a color. From there eventually my links would turn that color and I'd be like, "Awesome. That does something." This was a terrible way to write code. I hated this. I don't think many people liked writing their websites like this, but this is what we knew. This is what we could do at the time. We want to move forward another year, two years or so...

[Slide 5 - 2:13] We still have these "enter site links" all over the web. I don't know what it was about these title pages that people loved, but I would hover the link...

[Slide 6 - 2:20] and then I noticed this. I was very confused. I would look and was like, "Where did that underline go? That underline is ugly. I would love to get rid of that underline. How did you do this?"

[Slide 7 - 2:35] I looked at the source code again. That's what we did a lot of. I saw this weird, weird tag that I'd never seen before. It said style. I said, "Yes, I can get behind this. What are you?" Then I looked at the letters inside of it, and I noticed some punctuation that I had never seen before on websites. It was all looking really, really weird, but I was instantly in love. I did all the research I could do. I dove head first into CSS. I had no idea what was going on, but I just learned and learned and learned. Legitimately it was the first step, the first point in time that completely changed how I wrote websites. It's cool. I'm still using it nowadays. We fast forward a little bit, and CSS had definitely grown up from the late 90s, early 2000s. We've had the explosion of CSS3. We had the web standards movement as well that laid the groundwork for all the CSS3 stuff. Now we have a situation where we can do really, really, really beautiful graphic interfaces solely in CSS. All of this gave rise, a few years after I discovered CSS...

[Slide 8 - 3:57] ...to the old gradient button. We would have buttons with rounded corners and gradient backgrounds and small shadows. This was prevalent for quite some time.

[Slide 9 - 4:10] In CSS this was actually quite easy. You would just throw your three properties there. This is the color of my type. This is the radius of my corner. This is the background image. I want it to be this radiant that the browser is creating. The reality, though, is that, as browser vendors moved forward, they moved faster than web standards. They would implement web standards before they were full standards. In doing so, they would add what were vendor prefixes.

[Slide 10 - 4:40] Instead of writing these nice three lines, we would end up with something that looked a little bit more like this. We would have to declare multiple border radiuses. We'd have five lines here for the gradient, and, if you looked, there is actually two different ways to declare this for Web Kit because they did it one way and then they did it another way. While CSS was becoming far more powerful, the fact that we had to add all these vendor prefixes was making our jobs more difficult. We had to keep track of what vendor supported what specks, the different syntaxes related to each of these different specs, and things were getting a little bit crazy.

[Slide 11 - 5:28] I think that is most easily seen if we look at Flexbox. This is a simple Flexbox layout. We have a container. We want our boxes vertically centered in it, and we want them centered horizontally in the center as well.

[Slide 12 - 5:42] This should be easy with Flexbox. You say, "Hey, this is a flex container. We want to align our items to the center line, and we want to justify our content center."

[Slide 13 - 5:54] The reality, though, is that there are actually three different standards and three different specs for Flexbox. We have recently gotten to a final standard, but there are still browsers out there that support all three standards. So instead of writing these three lines, we have to write these...I'm not even going to count them. There are just way too many lines of code here. It is crazy. It is absolutely insane. No human being should have to write this. The next big leap in writing CSS actually came from preprocessors, though, things like SASS and LESS and Stylus.

[Slide 14 - 6:34] They allow us to write mixes. Instead of writing all 2,000 lines of code like this every time we want to use it, we can write a single mix in that would say we're going to call something a flex container. We can tell it which way to align. We can tell it which way to justify...

[Slide 15 - 6:50] ...and just write out all of these lines of code so that every time we want to use it we just call that mix in. We just say, "Hey, include flex container and use these values." That made life easier, but we still had to do things like remember what browser supported what version of the spec, remember what vendor prefixes we needed. We ended up with a lot of CSS files that, once they were compiled, had a lot of vendor prefixes in there that we did not need. Our files were bigger than they had to be, and we were wasting brain cycles trying to figure this stuff out.

[Slide 16 - 7:27] What we really wanted was to just write this. We wanted to write, "Display flex," align our items, justify it, and do that.

[Slide 17 - 7:36] We've come across a tool recently that I heard about, and I've used it on three projects now that let us do this.

[Slide 18 - 7:44] It's a tool called Autoprefixer. It is really cool. You can find out more about Autoprefixer here at the website github.com/ai/autoprefixer. It looks at your files when you compile them. We use this as a Rails gem.

[Slide 19 - 8:04] When our asset pipeline compiles our file, it finds all of our lines of CSS that may need vendor prefixes and then compiles them into the prefixed code based on browser support that we set. If I write ".box { display:  flex;" it outputs, in our compiled code, the five lines that we need for Flexbox. If we write "border radius for pixels," then it's not going to give us any vendor prefixes, because we don't need those anymore. It's really, really cool. As I mentioned, we're using it with the Rails gem. You can use it with Grunt. You can use it with Node. It works with Middleman. There's a Middleman gem for it. There's a Sublime Text plug‑in, so if you just have a plain CSS file and Sublime Text, you can set it so that when you save it goes through your files and handles your vendor prefixes for you. It works with Compass. There is pretty much not a thing out there that Autoprefixer doesn't have some way of supporting. It's really, really cool. How do we use it?

[Slide 20 - 9:10] Let me show you. Right here in our gem file we simply add "gem 'autoprefixer rails'." We do our bundle install. It installs the gem for us.

[Slide 21 - 9:18] Then we just set up a config file at config/autoprefixer.yml, and it is as easy as this. We tell it what browsers we're going to support. It has really simple language to do this. Like you see right here we have the last three Chrome versions, the last three Safari versions, the last three iOS versions. We're doing Firefox 20 and up. In this case we're doing Android 3 and up, Internet Explorer 8 and Opera 12 and up. You can support single versions of browsers. I could say, "Just support Opera 20 and nothing else." You can do that. It's really, really cool. It's really, really easy to use, and, as a result, we are now just writing standard CSS. We are not writing any vendor prefixes. We are not managing our mix‑ins to support vendor prefixes. We are simply writing mix‑ins to make writing codes easier. It has been an absolutely amazing change in how we write CSS. I think everybody out there should be using this tool.

[Slide 22 - 10:27] I want to thank you for checking in. I'll be back every week, two weeks, three weeks, sharing more tips, tricks, and tools that we are using here in the design department at Table XI. You can find us online at tablexi.com. Our Twitter feed is @tablexi. Thanks a lot.