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.
http://www.webstandards.org/2012/02/09/call-for-action-on-vendor-prefixes/
Without web developers including all prefixes plus a non-prefixed version of every experimental CSS rule, the state we were in with the IE monopoly of pseudo-standards becomes a -webkit- prefix monopoly of pseudo-standards.
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.
I'm surprised noone has mentioned prefixfree.js (http://leaverou.github.com/prefixfree/) or cssfx (http://imsky.github.com/cssFx/). Both are polyfills that will automatically apply any missing vendor prefixes at runtime, allowing you to author the CSS without worrying about prefixes.
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.
Browser vendors need to wait to ship new CSS features until they work. People use these for compatibility hacks where things render differently.
Let's look at the good old days. When CSS first started appearing in user agents, we had crazy stuff like Opera interpreting z-index BACKWARDS. It was fixed in the next major release, but it was a real problem. I had been pushing many of our users to Opera (web designer + tech at ISP) and had to stop recommending it after that. At the time, I could have used something like moz-z-index: 10; o-z-index: -10 or something to work around the broken Opera folks implementation. This was somewhere between opera 3 and 4 and around the time they hired one of the co-authors of the CSS standard.
Not to just pick on opera, remember IE3's very limited CSS which basically let you do link color and hover. In fact, what we really need is a clear CSS1, CSS2, CSS3 definition that browsers provide when they have FULL support for the standard as well as a way to detect user agent and version within a style sheet. It's terrible it's come to this, but if I could just wrap IE is broken crap in a ua:ie { } type thing it would make people happy. Let's face it, object detection was a great idea but it's still a fail. Things don't work right in IE or Opera. Firefox or Chrome can be picky about certain things and lose features in newer versions. Security on iframes and cookies keeps tightening up. Having the object doesn't mean it behaves like it did 3 versions back. We need a whole new model for defining capabilities that isn't broken on the web.
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!
Really web monkeys? Is that the best you can do? Mod me down because you don't like what I have to say?
People are probably modding you down because you're referring to people them as "monkeys." If you were interested in frank discussion, you don't start with disparaging comparisons to other mammals. That's trolling no matter how well founded your arguments might be.
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!)
check the batteries in your sarcasm filter
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.
I used to do this but have since changed to SASS. Worth a shot if you haven't tried it out!
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.
I'm not saying the implementation can't be first. I'm saying, don't enable it by default in the installed base before it's a standard (formal or informal). That way the people who want to play with it can, without being tempted to use it in production sites, where it'll break sooner or later if the standard isn't just a rubberstamping of exactly the first implementation. By making the feature available default-off, the implementers can still see if the specification is clear and unambiguous, and the users can still see if the feature is useful as it is.
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."