Skip to main content

Flags vs Vendor Prefixes for Experimental CSS

Google recently announced that it will be switching Chrome's rendering engine to a fork of Webkit, called “Blink”. If you're interested, you can read their blog post about Blink.

One of the changes we will be seeing in Blink, is the use of browser flags in place of vendor prefixes.

What this means, is that rather than prefixing experimental CSS with -webkit-, -moz-, -ms-, -o-, -khtml-, etc.; We will be required to enable these attributes using a flag in the browser (like the ones currently at chrome://flags).

If you ask me, both ways have their advantages and disadvantages. Though, in the end, I lean towards the flags over the vendor prefixes, and here's why:

#1 Code Bloat

On average, using CSS with vendor prefixes requires writing it 5 times. Every time you use it.

#2 Future Friendly

Eventually, prefixed code will be replaced by the unprefixed code.

#3 Browser Dev Friendly

Browsers tend to continue to support the prefixed code, even if it doesn't make it to the spec or gets changed. If they didn't, they could break existing sites that relied on this code. This compounds and grows as more experimental features are added, which adds overhead to the browsers and more work for browser devs.

Conclusion

By moving support for experimental (spec not yet approved) CSS into an optional flag in the browser, and supporting only a single version of the code, we may lose the opportunity to expose these features to the masses early, but we gain a much more stable and maintainable environment.

Comments

Popular posts from this blog

Be Careful Using SASS @extend, CSS3 Selectors, and IE8

I recently ran into a situation where some of my styles were broken in Internet Explorer 8. What makes this different from all the other times my styles broke in IE8 was that, as far as I could tell, it was correct. Consider the following code: %highlighted { background-color: #ff0; color: #333; } .keyword.is-active { @extend %highlighted; padding: 10px; text-transform: uppercase; } No problem, right? Then why isn't it working? I wasn't sure, until I looked at the compiled CSS and saw something like this: .some-list:nth-child(2n), .is-highlighted, .keyword.is-active { background-color: #ff0; color: #333; } .keyword.is-active { padding: 10px; text-transform: uppercase; } Since IE8 doesn't support the css selector nth-child , it ignores the entire rule . Without looking at the final output, there's no way of knowing if this will happen ahead of time. So what can you do? Well,...

SASS Mixin for Creating CSS Triangles

I feel like one of the most common shapes that we can reliably create with CSS vs images is the triangle. One of the reasons for this is that it works as far back as IE7 (IE6 works, but doesn't support background-color: transparent ). Another is how frequently a little triangle icon can be used (e.g., ascending/descending buttons, expanding menus, open/close state, etc.) I'm not going to cover the techniques of creating triangles with CSS . That's been done already , and probably better than I would do it. What I'm going to share with you, is a little SASS mixin that I've been using to generate triangles. See the Pen SASS Triangles by Thomas Pietrosanti ( @Rykus0 ) on CodePen . I'm using a SASS placeholder ( %triangle-base ) as a base to contain the common styles. This makes it easy to extend without generating tons of extra code each time I want to make a triangle. When this compiles, it creates a rule that applies to all of th...

SASS Converts Zero Opacity 'rgba' To 'transparent'

I recently had a strange problem after updating SASS. I have a modal dialog with a semi-transparent overlay behind it. For modern browsers, I'm using a CSS transition from rgba(0,0,0,0) to rgba(0,0,0,.5) For older browsers (namely IE8), I'm using some JavaScript to apply the transparency and animate the transition. To make sure the background gets set correctly, I'm using the standard fallback strategy of defining the background as background: rgb(0,0,0); right before the rgba line. This worked fine, until SASS optimized my code by changing background: rgba(0,0,0,0); to background: transparent; The reason? It's 2 characters shorter. Yes, we've now saved 2 bytes of easily compressible text in exchange for breaking my code. Why did it break? Well, if you haven't already figured it out, normally a browser that doesn't support rgba will simply skip that property and move on. But transparent is supported. So now, instead of h...