Slashdot Mirror
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.
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?
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.
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.
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.
Can you please just state the fact in an article and not attempt to persuade an opinion? Personal commentary really kills it for us.
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.
make imaginary.friends COUNT=100 VISIBLE=false
First of all, this "proposal" is coming from the fine folks over at Opera. And the "problem" is that people are using prefixes, just not their prefix (-o-). So they want to do away with them. Just last week they announced they were going to copy webkit's prefix, so I really don'y know why they are proposing this.
The real Sig captains the Northwestern. This one captains
Amen. It's rather tiring to explain customers over and over again why not to use the shiny bling they saw on some other site recently. Experimental tags are useful but should not be used in production web sites. The problem is however that it takes forever until some new and useful features are finally part of the standard.
My solution would be twofold first speeding up the decision process and second mark experimental features "experimental" and drop them when they have been integrated into the standard or have been ditched. That might break a website or two but with the feature labeled experimental the persons involved have only themselves to blame.
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?
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?
"First they came for the slanderers and i said nothing."
The centering bits are a problem, but for the others -- use a CSS pre-processor. (Sass, LESS, Scaffold, Compass, Stylus,etc.)
There are ones that are more Ruby-ish, or Python-ish, etc. Some can calculate colors (darken, lighten, blend, etc.), but almost all let you set things to variables so they can be set in one place and used multiple times.
(and none of this is really new -- I know folks that were using ColdFusion, PHP or even Perl to generate their CSS a good decade or so ago ... it's a page of text, and pretty much anything that can generate an HTML page can generate CSS too)
Build it, and they will come^Hplain.
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.
The possibility for AJAX lingered so long before it saw widespread use that I have to question if a more standards oriented approach might have been better, i.e. propose a method for Javascript to get and push documents, then make that feature available as an experimental (default OFF) feature, let developers play with it, standardize it and enable it everywhere. AJAX has its problems, which might have been avoided if Microsoft had not set them in stone by making the first implementation the reference for all others.
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.
I have write a lot of open source software. I am OSS supported as the next guy, and for OSS standards are very important.
But standards are not more important than progress. With the current system, browser creators can invent any fun stuff and add it on the next update this week. And it don't break anything. And theres nothing bad in that.
About webmaster using it, what is wrong is the level. Wen a JQuery extension or a CSS library (think... reset.css) use a extension, is Ok, because it abstract a problem, so the normal webmaster don't have to know or use all these -moz- -webkit- etc things. These things HELPS, helps so much that we can fix broken things on the web using then, like... making all browsers act the same way. And to do that, sometimes we need a library author, or a JQuery plugin author to put his hands on these extensions. Another similar thing is how you don't have localStorage of HTML5 support everywhere, but you can use it everywhere trought a library that uses something else in browsers that don't support it ( IE has something similar to localStorage from IE5, that is superugly but can be forced to provide the feature).
These extensions are GOOD, but should be reserved to be used by the library authors, not the general webmaster public.
This proposition is WRONG because sometimes you may want to support "opacity", but your programmers can't support exactly as speced, is better to have a --ie-opacity than have a opacity that work different than the standard. The browser extensions allow browsers to support things in a dirty/not complete mode, withouth breaking standards. This proposition is wrong.
-Woof woof woof!
The real solution to the problem is to make the experimental features more obviously experimental.
It should be mandatory that a pre-standardised feature be disabled by default in the browser, and enabled via a preference setting for developers to try them out.
Most non-developer users would not bother to fiddle with these prefs, and thus the features would remain truly experimental until they were standardised.
Yes, this would mean that developers would get frustrated by stuff they want to do which is tantalisingly out of reach in terms of being able to use it for mainstream development. But on the flip side, I believe it would also act as an encouragement to all parties involved to get the features through the standardisation process at a decent speed (this has been a large part of the underlying cause of the problem, not the prefix policy itself).
(Spudley Strikes Again!)
The trick is to write the CSS as a PHP file, but make sure it is only parsed rarely, and cached. On the server, create "style.php" (linked from thje main HTML just as if it were a normal style.css file). Then fix the caching and mime-type. Result: easy to write, still efficient.
//Respond with 304 (not-modified) unless the file is changed. This means the PHP file is only evaluated once per client per session.
$last_modified_time = filemtime(__FILE__);
$etag = md5_file(__FILE__);
header("Last-Modified: ".gmdate("D, d M Y H:i:s", $last_modified_time)." GMT");
header("Etag: $etag");
if (@strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE']) == $last_modified_time ||
trim($_SERVER['HTTP_IF_NONE_MATCH']) == $etag) {
header("HTTP/1.1 304 Not Modified");
exit;
}
$max_age=600; //10 minutes.
header("Cache-Control: max-age=$max_age"); // HTTP/1.1 (Client won't even try to reload more than every 10 mins).
header("Content-type: text/css"); //Set the mime-type to CSS (so the browser will cope with it.)
//Now write out the CSS, using PHP to help make it more terse.
It's the same old argument - do you want the standard to be a rubber stamping of an ad hoc development with all its quirks and flaws, but available to play with early on in all browsers? Or do you want it to be a polished document produced by a committee of several dozen people deliberating over the fine details of syntax for 2 years, but available very late (and in the meantime, incomplete/fragmented implementations between browsers)?
TFA argues for the first model. If it works, let it stick, even despite minor flaws. If it doesn't work, it'll just go away, and no-one will care if it was prefixed or not.
That's a fine trick, and it is clearly beneficial since you are willing to go to such an effort to do it, but this only demonstrates how truly constants are needed in CSS, because everyone is making their own hacky workaround.
"First they came for the slanderers and i said nothing."