W3C Member Proposes "Fix" For CSS Prefix Problem

Pieroxy writes "The W3C is proposing a set of new rules for CSS prefixing by browser vendors. This would greatly mitigate the problem caused today where vendor specific prefixing is seeing its way through production sites. The problem is so bad that some vendors are now tempted to support other browsers' prefixing. The article also has a link to an email from Mozilla's Henri Sivonen that does a nice job of addressing many potential issues and shortcomings of this new proposal." I was under the impression that browser prefixes existed to allow use of experimental CSS features before standardization; just ditching the vendor prefix seems like a step backward.

Comments

The solution is..

[Psylok]

Drop them all.

I always wondered why they've put them there in the first place. I mean: since you are implementing the function, why call it with a different name?

Re:The solution is..

[Anonymous Coward]

Yes, they should just use the standard.

Stupid microsoft.

Re:The solution is..

[Sarten-X]

Because IE's implementation of a given function might be different from WebKit's, so a designer has to resort to more painful workarounds to get a perfect design. It's easier to just duplicate the same detail with different prefixes (and slightly different parameters, as needed), and know that the directive will be ignored by browsers that don't do exactly what the designer wanted.

It's like back in the bad old days of web design, where websites ran JavaScript to detect what browser was in use, so the page elements could be repositioned on the fly as needed, and the right objects would be used in other scripts.

Re:The solution is..

[WrongSizeGlass]

Yes, they should just use the standard.

Stupid microsoft.

Many of the browser vendors are to blame. I'd love to point the finger at Microsoft, but they aren't the only one who isn't compliant with the supposed standards (CSS, DOM, Javascript, etc).

Re:The solution is..

[Anonymous Coward]

Because before it's allowed to be a recommendation, it has to have "beta'd" in 2 browsers. So, usually they prefix with the vendor-name (minus webkit browsers which use the engine-name).

Sometimes they have competing syntaxes, such as in gradients, which webkit and gecko duked out.

Basically, they need to allow to experiment, allow backwards compatibility (NEVER BREAK THE WEB), and still be able to ship. Prefixes solve this problem.

The problem most are having with this, is web developers are getting lazy, and on mobile sites only including (pretty much) webkit. So now, IE9Mobile and Firefox Fennac(? is it still called that), are having to implement the -webkit- features because sites look terrible on them, because developers got lazy.

Re:The solution is..

[chrissigler]

In some cases, different engine authors have different ideas of what the best way to define the spec would be. And given that there's no solid standard yet, they want to do it the way they want to do it. And over time, they can even change their minds, perhaps submitting to the weight of the broader industry.

For example, consider Webkit's two implementations of a simple linear gradient, from black at the top to white at the bottom:

-webkit-gradient(linear, left top, left bottom, color-stop(0%,#000000), color-stop(100%,#ffffff)); /* older webkit method */
-webkit-linear-gradient(top, #000000 0%, #ffffff 100%); /* newer webkit method */

Note that the "new" approach to the arguments is based more on the emerging "standard" (implemented the same way with -ms-, -moz, and -o- prefixes). But when you're out there before the standard emerges (or better yet, is defined), you don't just presume to define the standard.

Or, at least that's how I imagine it went down...

Re:The solution is..

[xouumalperxe]

Because many of the prefixed CSS properties have not actually been fully standardised, so having vendors support them with prefixes and varying (possibly incomplete!) implementations/syntaxes means we actually get to try the various approaches being proposed, and only pick one to standardise on once the dust has settled and people have made up their minds as to which one is better.

Re:The solution is..

[gl4ss]

Yes, they should just use the standard.

Stupid microsoft.

Many of the browser vendors are to blame. I'd love to point the finger at Microsoft, but they aren't the only one who isn't compliant with the supposed standards (CSS, DOM, Javascript, etc).

I think it was a sarcastic jest at the parent post, which suggested that a browser producer should name a css property superblubbery instead of ms-superblubbery, which is what ms did and got flak for?

who really gives a fuck about w3c anyways? it's not like they're ever on the leading edge. devices api group? oh they're only 5 years late and based on vendor specific stuff that shipped 5 years ago, how very nice.

Re:The solution is..

[pmontra]

Agreed but there is more to that. W3C should take its share of blame for not having standardized yet rounded corners and the like. But among W3C members there are also browser vendors, so maybe it's them who don't like to agree on standards with their competitors.

Re:The solution is..

[QuasiSteve]

It's like back in the bad old days of web design, where websites ran JavaScript to detect what browser was in use

Those bad old days are ongoing. Just because everybody and their dog are including jquery now doesn't mean the sites aren't still using browser-specific javascript, css, markup, etc.

It's easier to just duplicate the same detail with different prefixes (and slightly different parameters, as needed), and know that the directive will be ignored by browsers that don't do exactly what the designer wanted.

Which, unfortunately, got broken with the popularity of WebKit (whether one blames Apple or Google, doesn't really matter), because designers just started using the webkit prefixed CSS and ignored the rest because it still looked 'okay enough' in other browsers, so why bother making those look 'great'?
The same applies to things outside of the CSS realm, like the apple-touch-icon link. Android uses it. Yep - want pretty bookmarks on Android? Specify the Apple (by name) icons.
Largely this is because the standards people are moving way, way too slow.

But then there's the flipside of the coin. The Opera article in which they announced - along with Mozilla - to support some webkit prefixes, was hilarious.

Their solution is to essentially alias the webkit prefixes to their own. Fine, right? But what happens if there's directives for both? Well, the last one specified overrides. Note that not the vendor-specific one that applies to that vendor's browser overrides, just the last one specified.

So when it comes time to build a site that works well on all browsers, including the ones that use such aliasing, what do they suggest?

blah {
-webkit-foo : bar;
-moz-foo : bar;
-ms-foo : bar;
-o-foo : bar;
foo : bar;
}

But then they also note that for some features, they don't support the prefix-less version for reasons of it not being finalized yet.

So let's say webkit specifies a blue background, moz specifies a yellow one, and o specifies red. When you view it in Opera it will be? red.
Now you view it in a Mozilla browser, using the same aliasing nonsense, what color will it be? red. Opera's. Because that was specified last.
Want to fix it to yellow? You'll have to specify the moz line last.
Except that then Opera will also render it in yellow.

It's all good and well to want to accept other vendors' prefixes, but why would you not let your own override, rather than the last-specified? I realize that as CSS goes, last-specified is supposed to override when there are conflicting specifications... but given the vendor-specific prefixes, there is no actual conflict.

Most hilariously, they already anticipated one response... "So I only need to use -webkit- prefixes now? w00t!" and answered it with "absolutely not." and then go on to give a very, very weak defense for why developers shouldn't do exactly that. Use the webkit prefixes where webkit doesn't make use of the non-prefixed version, use the non-prefixed version to make the page future-proof (assuming the behavior stays the same, but them's the breaks), and call it a day, because Opera now supports the webkit prefix, Mozilla apparently intends to support it, and IE... well, IE...

Re:The solution is..

[mwvdlee]

I used to think that too, but then I started to do web development.
Usually I develop a site on Chrome.
Then verify that everything works on Safari, FireFox, Opera and iOS/Android if applicable.
Then replace CSS styling with images to make it work on IE9.
Then reduce layout to make it work on IE8.
Then replace the div layout with nested tables to make it work on IE6.
Then thank the gods I don't have to support IE5.5 any more.

Yes, all browsers have compliancy issues. IE is just far, far worse than all the others.
Even IE9 is more troublesome than a version of FireFox from a few years ago.
IE10 improves a lot, but is still worse than the other major browsers.

Re:The solution is..

[Anonymous Coward]

What we need is a more "amateur" web, where people only do the work in your first step, maybe also do the second step (test on one or more other (non-IE) browsers) which only takes a minute or two, and then say they're done -- simply blowing off the question of whether or not the site looks perfect on IE.

You can't do that (neither can I) at our jobs but for a situation where there isn't some boss telling you "21% of our users are still using IE so the site has to look ok," then blowing off IE is simply no problem.

I mean it's not a problem for anyone, not even the IE users, because they would either accept they're not seeing the same web as everyone else (and there's actually nothing wrong with that) or else they'd upgrade. Or, worst case, they would bitch like they always do and balkanize off to their own web and the world wouldn't miss them.

Nobody loses, if only we had a less professional approach. "Pro" doesn't mean "better."

Re:The solution is..

[Piata]

I really hope you're exaggerating about using nested tables to make a site work in IE6. A custom stylesheet that only targets IE6 can do the job just as well. The only hard part is knowing all of IE6's quarks.

Personally, I prefer to go the slightly more controversial route and not support anything below IE8. If a client wants IE6 support, they're going to pay through the nose for it.

Re:The solution is..

[mcgrew]

W3C should take its share of blame for not having standardized yet rounded corners and the like.

What the GP said about lazy (and perhaps incompetent) developers applies here. My old site had rounded corners in 1997, and in fact had most of the web2.0 crap without the annoying "chase the moving link" game and the more annoying "page scrolls up by itself after I scroll down" (sj-r.com is a really bad offender here).

You also need to remember that nobody comes to your site because of what it looks like (although it may keep them away because it looks amateurish and unprofessional), they come to your site for its content.

Re:The solution is..

[Anonymous Coward]

You've not done much work with IE6, have you? Heisenberg's uncertainty principle is definitely in play.

GP is right, though; an IE6-only stylesheet is usually enough (even if you have to degrade support slightly in IE6).

Re:The solution is..

[Eponymous Hero]

i was with you until IE6. it's your duty as a developer to royally bitchslap the living fuck out of anyone still using that browser. no mercy, no excuses. IE6 is unsupported and dead. dead dead. 0xDEADDEAD, microsoft says STOP, error. 0xDEADBEEF dead. your memory of IE6 has been freed up and you may no longer reference it. fuggetaboutit. if you're being paid enough money to convince yourself otherwise, a simple IE targeted stylesheet (included via conditional comments) is enough to pixel push it back into shape.

Re:The solution is..

[jc42]

we need is a more "amateur" web, where people only do the work in your first step, maybe also do the second step (test on one or more other (non-IE) browsers) which only takes a minute or two, and then say they're done -- simply blowing off the question of whether or not the site looks perfect on IE.

What we really need is to learn to strongly resist the idea that a page need look perfect on any browser. This is a "drop-dead" requirement that can't be achieved. Even if you think you've done it for one browser, the next upgrade (which is probably being installed by some of your clients right now) will shoot down your perfection. And the developers of commercial browsers (e.g. IE) have taken great pains to ensure that you can't succeed. They want walled gardens, and they're building them. The concept of "perfection" in web pages is one of their tools. The only way to win this game is not to play it.

Since the start of the Web, the main function of HTML has been to make documents that are usable as widely as possible, despite the huge differences in displays, window systems, input devices, etc. The right way to test pages is to verify the usability of a page on a wide range of devices, now including handhelds. Web designers that design a "perfect" page and insist that it look the same everywhere are missing the main point of it all. The vendors are guaranteeing that you can't do this, no matter what your design.

If your page insists on a "perfect" display of the page, it will simply fail on display and/or window systems that don't permit your page's requirements. So aim for "functional" instead, with design aesthetics a distant second, and you'll produce much more usable pages.

This may require educating your boss(es) about the nature of your "market". But they should be used to this. After all, consider the canonical auto analogy: What would you think of a boss who thought that a single model car can be built that will satisfy all customers? That's just dumb, right?

Re:The solution is..

[drkstr1]

What about the webkit and moz prefixes? It's not just MS this time I'm afraid. I curse Adobe for this madness!

Re:The solution is..

[QuasiSteve]

The CSS rules specify that the last one overrides. So they're still following the rules.

No, the CSS rules say that when there are conflicts, the last one overrides.
For example, if I specify background-color twice for the same selector (or selectors that end up selecting the same elements), then the last-specified overrules any prior ones.

In the case of the vendor-specific prefixes, however, there is no conflict. Keep in mind that browsers aren't even supposed to be reading other browers/vendor/engine/whatever prefix rules.
I.e. -webkit-thing -moz-thing and -o-thing do not conflict because they by definition do not conflict.
That of course changes if you start doing a search&replace for -webkit- to replace with -o-, then all of a sudden you get -o-thing -moz-thing and -o-thing. Then you get a conflict. But that's an enthusiastically stupid method of doing it for the very reason I outlined in my post; if everybody started aliasing everybody else, then web developers will definitely not bother with small marketshare browsers anymore because they can't even be sure which one gets applied anymore.

I know what you're thinking.. "That's the point! Hopefully those web developers will then just drop the prefixes altogether!" - except that Opera has themselves explained that they don't even support some of the non-prefixed versions because they are not set in stone in the standard.
So what's the more likely outcome? -webkit- prefixes for everyone.
( And no, I'm not one of those developers - I actually try to stay away from anything that requires a prefix for the very reason that I'd be writing prefixes all day long even with macros. It may make a page less shiny, not have a pretty icon on iPhones, etc. but then I don't care about that. Others, however, do. It's them, among others, who should take issue with this. )

Why the hell would you want each browser to have a specific color?

It's called an example. I can go into features that are far more subtle in difference between browsers, but pointing you to google should be enough.

Which brings me to..

Your website should look the same regardless of browser, that's what CSS and HTML is for.

Excellent. Mind telling the browser vendors that, so that people don't even have to use any browser-specific bits anymore? That includes letting things be dealt with automatically using jquery and other frameworks. Just because you've passed that burden off to a third party doesn't mean it's not there. I swear I explained this in paragraph 1 :)

Opera is aliasing certain features, not so everyone can start using the webkit prefixes, but so that websites will work and hopefully eventually, those webkit prefixes will disappear and they can remove this hack.

I wholly agree that in principle they're not doing this so that people will -start- using the -webkit- prefixes. I even believe that if they had the power to stop people from using them, they would.
But the reality of the matter is that people already are using them and aren't about to listen to Opera or Mozilla's pleas to either stop doing so (and make their sites less shiny in webkit browsers, which dominate the mobile market, own the Apple market, and is strong on others via Chrome and derivatives) or add their own vendor-specific prefixes just to deal with their tiny market.
The reality is that Opera doesn't want their users to go "the sites I visit look way better in Chrome/Safari/whatever, so I'll use that instead of Opera" - and thus started accepting the -webkit- prefixes for themselves.
And thus the reality is that people who were using -webkit- will continue to do so, knowing that now Opera, Mozilla and even IE (to an extent) will accept them), and others will be encouraged to do so (because the non-prefixed versions get ignored and they do want the shiny).

The decision to accept -webkit- prefixes effects the complete opposite result of what is being aimed for.
( Not that they have a choice. )

Browsers should ship with prefix support disabled

[Anonymous Coward]

Browsers should have an option to enable support for their experimental features and ship with the option turned off. If the masses have feature-enabled browsers, these features will be used in production websites. The only way to prevent fragmentation is to keep fragmenting features out of the installed base.

Here's another proposal:

[orthancstone]

Get the standard done. Browser vendors are not going to wait 20 years for you to make up your mind. The digital world moves too fast for policy to take too long. Proposed ideas are going through vigorous testing in the real world long before a finalized plan for that idea is set.

Re:Here's another proposal:

[Anonymous Coward]

The online world is not moving fast at all. Two years ago, a browser from the turn of the century combined with a proprietary plugin was the definition of the usable feature set, because the availability of anything beyond that could not be relied upon. At least until the end of life of Windows XP, the role of holding everybody back falls to IE8. HTML5? No show. The other browser makers can slow the fuck down and concentrate on building secure browsers that don't need to be updated twice in a full moon. Instead we get browser war style feature fragmentation and "best viewed with" (or worse, silent failure) drives people nuts.

Re:Here's another proposal:

[Skuto]

...and some vendors (mostly Apple, a little bit Google) have an interest in that not happening. So good luck waiting.

Re:Here's another proposal:

[WankersRevenge]

At least until the end of life of Windows XP, the role of holding everybody back falls to IE8. HTML5? No show.

Funny ... I've been writing HTML5 for awhile now and it works fine in ie6 and up. Granted it requires conditionals and some clever use of css, but it renders fine in older browsers and modern browsers get to experience some of the latest features. And no - there is no "best viewed" anywhere in my sites. Everything just works with or without JavaScript all written in standard markup.

It takes work, but so does anything worth doing.

Re:Bias Reporting

[NemoinSpace]

If you can't handle the concept of editorial bias and persuasion, I suggest you pick up an encyclopedia. If everyone agreed on facts, there would not be much point in regurgitating them in a discussion, unless your at a pep rally.
Oh.

Good proposal

[gstrickler]

It would be a step in the right direction. Henri Sivonen's response also addresses several valid points, some of which can be addressed with minor mods to the proposal, some of which can be addressed (but not solved) by issuing guidance to vendors and authors. Having developed data communications standards and software in another industry, I'm well aware of the issues caused by non-compliance, insufficiently (and overly) specific standards, and that vendors and authors do not always follow the guidance (mostly because the developers rarely read it).

Most importanly, this proposal gives a clear, standard method for both authors and browser vendors. When it comes to getting compliance and compatibility with a standard, the simpler it is, the better for everyone.

CSS is annoying

[Lord Lode]

CSS is supposed to separate content from layout. However so many layout things cannot be done with CSS in straightforward and portable ways.

Something as basic as vertically centering text is impossible.

Putting things left, right, in a horizontal row or in a vertical row is a nightmare that usually involves creating more HTML elements anyway instead of being able to use pure CSS.

You can't make adaptive colors in CSS, like a shadow color automatically calculated from another color.

On top of that, you can't inherit from CSS classes so have to duplicate the same thing multiple times if you don't want to give each element multiple classes.

How about a new standard, replacing CSS, that truly allows separation of content and style in modern web apps?

Re:CSS is annoying

[Lord Lode]

If you have a div with a certain width and height, you should perfectly be able to center text horizontally and vertically. And UI designers of a web app can and will put the text of every thing centered.

It's such a basic, simple, logical, thing to do that it is really annoying of CSS to not have such a fundamental concept.

Re:CSS is annoying

[Tom]

You can't make adaptive colors in CSS, like a shadow color automatically calculated from another color.

On real browsers (i.e. anything except IE, at least up to 8, not sure about 9) you can come very close by using rgba colours for the shadow.

On top of that, you can't inherit from CSS classes so have to duplicate the same thing multiple times if you don't want to give each element multiple classes.

But giving elements multiple classes is kind of the whole idea. I regularily have one class that sets the layout stuff and one that sets colours, etc.

How about a new standard, replacing CSS, that truly allows separation of content and style in modern web apps?

Why? Just because it isn't perfect you want to replace it with something that for many years will be lagging behind?

Constants

[phantomfive]

Can we have constants now? That is the number 2 limitation of HTML/CSS right now. Cascading is great, but if you want to change your style, you STILL have to change the color value all over the place. What exactly are they worried about? Unreadable web pages? Have they looked at the web lately?

Re:Constants

[jbov]

you STILL have to change the color value all over the place

You're doing it wrong. There are 146 color names already provided to you. These should provide sufficient color selection for any site. In addition, each color has a very easy to remember, concise name, such as LightGoldenRodYellow.

It is best to use these standard names instead of trying to decide on your own variable names. Committees of highly intelligent architects have already decided on the best names for you. For example, see the distinction between Lime and Lime Green. My personal favorite: Brown, which is a carefully chosen contenders Sienna or SaddleBrown to be the champion of the Browns.

To make things easy, the substrings "grey" and "gray" are interchangeable in any color name.

Please stop trying to reinvent the wheel.

Re:Opera is pushing this...

[Skuto]

They're proposing this because the other "solution" they announced obviously totally sucks (but they have no choice).

To pretend this is only Opera's problem is silly. It's an everybody-who-is-not-Webkit problem. Which is why Mozilla said they will do the same, and if Microsoft ever gets any mobile devices out, they'll have the same problem.

Re:Browsers should ship with prefix support disabl

[Anonymous Coward]

If microsoft didn't push out their ActiveXObject("Microsoft.XMLHTTP") in IE 5.5 - and people wouldn't exploit it like mad, we still wouldn't use ajax today.

Re:CSS pre-processors.

[phantomfive]

Can we agree that using a CSS pre-processor is a horrible hack, and that it shouldn't be necessary?

Re:CSS pre-processors.

[phantomfive]

No, that's the problem. They DO make it so much easier. You shouldn't need to add that crap to CSS.

Wrong solution to the wrong problem

[Archibald Buttle]

IMHO the use of vendor prefixes was the right thing to do, and remains exactly the right thing to do.

The problem instead is that the standardisation process is taking far too long.

2D transforms, 3D transforms, transitions and animations still aren't officially standardised. They've existed for years, and are now supported in all major browsers (if one includes IE10), and are all essentially compatible. There's mostly only been minor tweaks to them all since they first appeared. Yet these CSS3 features are all at "working draft" stage. Indeed, the 3D transforms spec is a working draft, dated March 2009, over 3 years ago. It's absurd.

The real solution should be instead to expedite the standardisation process. That way the vendor prefixes can vanish much faster.