51 Set it and Forget it

I personally don’t mind the concept of browser prefixes. However when thinking objectively about them, the do feel basically like sophisticated hacks. It’s a shorter and cleaner way of browser sniffing (and it works better). But like I said, I don’t mind writing them.

However, I do think that a unified prefix could be beneficial for everyone involved. First and foremost, it reduces file size, which means faster load times, which Matt Cutts has recently mentioned is becoming a factor. Secondly, while we all would love to be our clients’ web designers from now until the day the internet is turned off, it doesn’t always happen that way. I have a handful of clients who I have not heard from since I received final payment from them. In these instances, while I agree with you Eric that vendor prefix usage will dwindle overtime, this will only occur if we as the designer are still involved in the site. If we are no longer in the loop, the client is stuck with extra code that is only slowing down their load times.

posted at 04:34 am on July 15, 2010 by desertwebdesigns

52

More CSS is better than more markup. Reduces traffic and keeps presentational stuff out of your HTML.

Interesting read, thanks!

posted at 09:59 pm on July 19, 2010 by designvibe

53 Its not about Browsers Fixing themselves

shez,

Its not about browsers fixing themselves in a given time span. Its about users. Any time a new browser is released, users start using it—and they don’t stop using it.

I would much prefer prefixes over exploiting parser differences.

posted at 01:43 pm on July 22, 2010 by Stargazer

54 Rethink: Vendor-Specific & Beta Prefixing

Insightful article! I liked your observations about the experimental nature of working with CSS3 in its early stages—that designers should expect various browsers’ implementations of CSS3 properties might change over time—as well as the careful ordering of rules, from vendor-specific to general.

Here are my thoughts on how the current system could be modified for the benefit of CSS designers and developers:

1) Allow the use of vendor-specific prefixes to target browsers at ANY stage of CSS implementation.

Browser differences are invevitable and, from time to time, need to be accomodated. We already have conditional comments for IE; why aren’t we able to target other browsers when necessary? Adding a vendor-specific prefix to a rule and placing it AFTER a general (or conflicting) rule could accomplish this quickly and easily.

2) Create a -beta prefix (maybe just a hyphen by itself?) to target new properties, with the option to override via vendor-specific prefixes.

This approach could offer the best of both worlds: simplicity, with an option for specificity. When differences between implementations of a new CSS3 property are negligible, designers could rely on a single rule:

Or even simpler:

When implementations are not so compatible, vendor-specific prefixes could be invoked:

An obvious question regarding a broader application of vendor-specific prefixes (allowing them to denote both experimental and standardized versions of a property) is: Could this cause a design to fail once the specs/implementations change? Your article seems to respond by suggesting that such changes are to be expected regardless. Moreover, I suspect that careful placement of a more general rule would distinguish one case from other, and render the first case harmless:

a) -ms-text-curl: minor; text-curl: minor;

b) text-curl: minor; -ms-text-curl: minor;

On the other hand, perhaps notation should more accurately reflect intent? In that case, vendor-specific prefixes (e.g., -ms) would best be used to target browsers, a beta prefix to target experimental CSS properties, and a combination of the two to target browser-specific, experimental implementations:

Much ado over a minor text-curl, huh?

posted at 10:00 pm on August 4, 2010 by Doug Downing

55 What bout browser updates?

One major flaw in all this is the assumption that once a new browser is available, everyone will flock to and download it. I believe the persistence of IE6 is a testament to what will likely happen. A less extreme example can be found by digging through your analytics. I know I still see plenty of early builds of Firefox that have spotty prefix support at best.

So, what’s the problem you might ask? How long do we leave the prefixes in our code? You talk as if one day in the near future everything will be all green fields and summer time, skies the purest blue, and web developers all frolicking as if Pan himself. I think it’s more likely that these prefixes are a more permanent feature of our CSS and thus less of a temporary fix to a problem, the working group not working fast enough.

Interestingly enough, I see Safari being updated in my analytics at a much faster pace then anything else and that’s because Apple throws Safari updates in with OS software updates. Oh, if another vendor in Washington State cold get away with the same thing without getting a bunch of geeks panties all in a bunch, what a world that would be. We might be closer to your green fields and summer time, blue skies and frolicking.

posted at 02:12 pm on November 21, 2010 by stubear

56 IE causes problems

One problem with the vendor prefixes occurs when you access prefixed properties through JavaScript.

In every browser, a dash indicates that the next letter of the property name in JavaScript is a Capital Letter. So “border-radius” becomes “borderRadius” in JavaScript. The same is true for vendor prefixes. “-moz-transform” becomes “MozTransform”. That makes it pretty easy to create a name translation algorithm.

…if it weren’t for IE. IE does this differently. I discuss this at my blog

posted at 09:42 pm on November 23, 2010 by atornblad

57 Thoughts

I agree prefixes are better than all other options when different browsers use the same property differently.

However, they are better because they are the lesser evil, which doesn’t make them better in the true sense of the word.

There should be homogenous syntax in all browsers. Vendors are to blame here: it’s not that much of a complication to talk with eachother and do things the same way. Declaring gradients with positions first and colours later and vice-versa isn’t something that is complicated to unify. It’s not like vendors have to change the whole rendering engine, just how they parse parameters p1=position, p2=colour. EASY. They just have to discuss and think about what the Open Web is all about, because I can tell you it’s not about petty rivalry. They aren’t suppose to be first to the finish line to “sell” the product first. No one will “buy” Mozilla because THEY have rounded corners nailed and others don’t yet. It’s a different market.

As for “you can drop the prefix once all is good” part, that will never work. You can’t trust people to always have the latest version of a browser. Just think of the high percentage IE6 still owns after what, 10 years or so?

However, this WAS a very good article. So thank you.

Stick a fork in me, I’m done.

posted at 07:21 pm on April 2, 2011 by Francisc

58 optimistic nonprefixing

I have very simple idea. If any browser implementing new property would parse prefixed version as well as the non-prefixed version from the very beginning, than we could just stop to use the prefixed properties until we see that anything brakes. If for example new property text-curl is proposed then we just use

text-curl: minor;

in our stylesheets and wait what happens. When browsers start to implement the behavior properly, than we do not have to do anything. If for example IE implements it with bugs, then as soon as we read about it in designers blogs we just use the prefix to correct it by saying

text-curl: minor;
-ie-text-curl: normal;

Yes, I am suggesting to put the prefixed version after the normal one, so we can override the behaviour for buggy browser.

Before you start to criticize the idea, think about it – in fact this is exactly what we are already doing by automatically use the four different prefixes for any new property introduced. By writing

-ie-text-curl: minor;
-moz-text-curl: minor;
-webkit-text-curl: minor;
-o-text-curl: minor;
text-curl: minor;

we just say “I hope that everyone is implementing the property correctly” and only if/after we find out a bug we are correcting the css. So why not use the same approach with much less hassle?

posted at 10:29 pm on January 29, 2012 by gorn