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..

[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..

[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]

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..

[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?

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.

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: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.