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

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

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

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

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.

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?

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