I've always thought that this didn't seems so bad idea. We use vendor prefixes so specific vendor errors and omissions doesn't become a property of the released standard.
An alternative to vendor prefix could have been draft prefixes instead. So for example, Firefox could say that we have partial implemented `shadow-box` draft 1, so we call it `-d1-shadow-box`. If Firefox had a number of omissions they could instead call it `-ff1-shadow-box`. If an later browser supported shadow-box exactly as Firefox did with the same omisisons, they could simply adopt `-ff1-shadow-box`, which then most likely would later become the standard.
Obviously I was talking about browsers based on WebKit. I could have been more specific but that would have ruined the humorous effect. Oh wait, I forgot - no sense of humour on HN (it tends to happen when you are too self-important).
But this is no more the fault of the Safari, Chrome, etc teams than it is the fault of the Webkit team.
They include "experimental" features just like other browser vendors do. It's hardly their fault that lazy developers only use the -webkit prefixed property.
The root cause of this issue is that prefixed properties are prefixed for too long as the standardization speed doesn't match the reality of how fast the web evolves and wants to evolve.
Fast releases and automated updates only make it worse, as two minutes after a prefixed property is thought up, a seriously large number of users will have support for it, developers will play with it and then the css code gets stuck on the internet.
By now most developers are in the mindset that it's okay to let a page differ in some browsers as long as the difference is only minor/aesthetic and not a functional handicap. And matching this vendors are perfectly happy with letting developers use prefixed properties as if they were stable.
Since these vendors make up the whatwg and w3c, they need to get their shit together and standardize faster and in the meantime developers need incentives to only use prefixed properties on test sites, which could be as simple as a console message that it should be removed (like how they did with the event.layerx deprecation) or having the user enable test mode in their browser configuration.
So you want to hold the development of the web back, by giving developers incentives (really making them look like fools) to slow the progress of the web.
The only thing the prefix system threatens is a few unimportant browsers that arguably shouldn't even be around anymore and the pride of the w3c.
And you want to save them, by throwing the future of the web under a bus?
No, don't get me wrong. I don't want to hold the development back. Websites, design wants to evolve fast, faster than anything ever before. I think vendors get this on some level, that's why they let us use these properties, but they need to do a better job as a collective: the working groups that draft the standards. If they standardize faster, there won't be any change in your ability to use brand new technology at the current rate.
For example: webkit devs think of a new property. They build it, they like it, they make it publicly available. Chrome guys enable using this in the dev and beta channel. In a couple weeks they have feedback on performance and stuff. Whatwg convenes, they finalize the details, webkit guys make a few adjustments (and it's fine because there's only 2 webpages on the entire internet that's been using it for a month tops) and then soon it hits the stable channel. This is what we need. Fast updating browsers could rape the benefits of such a system very nicely, fast updating is what we need to let the web evolve fast enough anyway. Slow updating browsers can go die in a fire, they are just as slow with supporting everything else.
Also, not to nitpick, but opera on the mobile front isn't unimportant. It's the only alternative to webkit, it's nearly ubiquitous and not a bad experience on mobile.
There're some prefixed properties which work on all major browser since forever (on a web scale)... but there're still a draft. Reading the minutes of the CSS group is enlightening : everything is really really slow.
Moreover, lots of non-defined prefixed properties don't break pages at all. Rounded corners per exemple are nice, but not displaying them is not a deal breaker. Same thing for transitions : site using them often provide a javascript fallback for non webkit browser.
If Opera wants to support webkit properties, they have to spoof their UA : lots of mobile website are designed for iPhone and Androïd (yes, that's not ideal, but it's a fact). It's the 00's mess again...
> By now most developers are in the mindset that it's okay to let a page differ in some browsers as long as the difference is only minor/aesthetic and not a functional handicap.
Well, if they're writing standards compliant code it's fine if the page is different in different browsers, but I take your point that developers are happy to write non-standards compliant code to provide extra functionality for a few users.
> in the meantime developers need incentives to only use prefixed properties on test sites,
Maybe search engines need to provide boosts for standards-compliance and drops for standards-ignorance.
I would place blame on W3C. Standardization simple take way too long.
Apple: We'd like some 3D transform properties for making cool websites for phones!
W3C: We'll have a draft ready by 2020.
Apple: Yea, we'll do our own thing.
If standardization was faster, we'd have much less problems with this.
> How exactly is this the fault of the webkit team?
This mostly isn't their fault. The main problem is that if any single implementation becomes dominant, we get these problems. And WebKit is dominant on mobile. For the browser market to be healthy again in mobile, we just need more diversity.
But there is also some blame on the WebKit browsers. If, seeing they were about to become dominant in mobile, they had stopped including experimental prefixed functionality in stable release versions, we would not have this problem. Prefixed stuff is not so bad in release versions if there is diversity in the market, but when the market is dominated, it becomes a mess.
Prefixes do not make sense on 2012 since any browser updates itself every few months.
Therefore it makes zero sense to not support every css property whose meaning you understand in the next three months (the lifecycle), and in the next version you can correct it if it deviates.
I'm sorry, but I fail to understand your grief about Opera. They've been nothing if not standard compliant since before most people had internet access. Not to mention the huge amount of not-PC-hardware they have provided a browser for (Opera Mini for feature phones, Opera for TV's with internet, Opera for Nintendo DS, DSi, 3DS)
I may be biased as long-time users often are, but they're definitely not comparable to the plague that is IE.
If laziness got browsers into the vendor prefix mess, laziness could get them out; the way to do that is to build good developer tools.
For example, a tool could scan CSS files and compare usage of vendor prefixes against the current state of cross-browser support for "better" alternatives. Perhaps you see warnings like "property 'webkit-xyz' can be replaced by 'xyz', which has been supported by the top 4 browsers since 2006".
Better in what sense? I don't like Safari and Chrome has turned into a buggy mess for me, whereas Opera is always stable. I've given up on the huge bloat of Firefox. IE is terrible. What's left?
I disagree with your concept of Chrome being buggy. It is not more buggy than the rest and has decent support for the new advanced features (with the exception of the calc css feature).
If you can't think of your users, think of your code then.
There's probably lots of CSS that has old -webkit/-moz/whatever tags because it "still works" and there hasn't been time to maintain it properly. A tool like this would make the code smaller, clearer and more future-proof without affecting any of your favorite users. It would just so happen to help fringe-browser users as well. I'd say that's a win-win, especially if you value attracting new customers and making money.
Right now, if I reach a web site that browser-sniffs or doesn't "support" me I go away and never come back. Generally not a useful way to treat visitors.
I can't remove that code until webkit and mozilla have updated their code to use the official standard. That won't happen for a while, so I see no advantage in adding -opera prefixes as well.
In a world that has both Chrome and Firefox, there is no reason to use another browser. They are both open source and available on all PC platforms.
Opera needs to stop accusing us of being lazy, and to die. They had their attempt and they blew it. Their existens only hinders the progress of the web.
Should there only be two car manufacturers? Competition is important. We should always push for open standards so they can be implemented by anyone. Maybe someday Google will decide that building a better browser is no longer in their best interest.
A car needs a road to run on, that is all the infrastructure that has to be common between cars (your car might need gasoline, but that does not mean that your neighbors car can't run on diesel or be an electric car).
So you driving an old car does not mean I can't drive a new much more fuel-efficient car.
A web browser on the other hand has a gigantic interface between it and the users and as such it is extremely arrogant to assume that the web should be held back due to your choice of browser.
If you don't like the look of it, or whatever you can totally apply skins or plugins to make it obey voice commands (I would love to read a blog post about how you did that) since those things don't interfere with the progress of the web.
In a world that has platforms other than the PC, there is no reason to assume browsers available on PC platforms are the only ones that matter.
Opera Mini works very well on mobile phones for example.
You're also on a web site with a lot of people working at startups: pretty much the epitome of not accepting the status quo and creating new things. If we all said "screw it" when big projects took over, the world would be a lot less interesting.
"In a world that has both Chrome and Firefox, there is no reason to use another browser."
Firefox doesn't support the webkit-prefixed CSS properties. They are also considering going down the same road as Opera and implementing these non-standard CSS extensions.
Here's a better idea, developers: stop using vendor prefixes. Use the W3C-defined property only. If it isn't standardized yet (i.e. doesn't work), then don't use it.
I agree, but then we hit the problem that the W3C stuff moves so slowly. We can end up with a situation where all modern browsers (WebKit-based, Firefox and Opera, maybe even IE) implement the same property, but the W3C standard hasn't caught up and might not for months.
The W3C working group includes these browser vendors. So much of these webkit enhancements are waiting for Apple to submit their proposals to the group. Last time I looked Apple were stalling in submitting them to the group.
The problem also lies with the vendors themselves. By operating in a fashion that's too open, we as developers are made aware of features before they're properly implemented.
Yes, it's wonderful that pages can be translated in a three-dimensional fashion now. I'd prefer to wait until six different declarations aren't required to know about it, though.
The web is an open platform that should remain device agnostic. Coding for a subset of available browsers is the kind of idiotic behavior that caused so many issues when IE was popular.
Not using vendor prefixes isn't a better idea. The reason for vendor prefixes is to allow developers to experiment with these features and feedback bugs, issues, improvements and future feature suggestions. It's a testing ground, and the web is a great environment to collect information about that testing. So not supporting vendors efforts doesn't encourage them to innovate. Perhaps these vendor prefixes should be limited to alpha/beta versions of browsers instead?
A better idea is for developers not to rely solely on vendor prefixes. Use them, but don't rely on them.
One of the use-cases that led Opera to support webkit prefixes were sites that styled a button using a webkit gradient. Without the webkit gradient, the user received white text on a white background. So in this case, only webkit browser users saw a button, other browsers saw nothing.
Opera, Firefox, and Microsoft were all receiving bug reports of this nature, in quantity. So it's not really practical to reply to users with a "site developer's fault" - it's a losing proposition, because - much like tomjen3's attitude in this thread - the site developer doesn't care. It's a brick wall in terms of evangelism.
Opera have taken 13 webkit prefixes and aliased them as opera prefixed - when the corresponding opera prefix isn't present. That is a practical user-centric solution that works until vendor-prefixes are crushed under the weight of technical debt.
(London Web Standards hosted State of the Browser today - http://browser.londonwebstandards.org/ , including a panel session with representatives from Opera, Firefox, Internet Explorer and Chrome panelists - no Safari representative, Apple declined the invitation. Hope they upload the video, it's worth watching, particularly for Opera's Bruce Lawson's comments about webkit aliasing)
> A better idea is for developers not to rely solely on vendor prefixes. Use them, but don't rely on them.
Sure. However, many of us know how "temporary" code can mold into permanent code.
> One of the use-cases that led Opera to support webkit prefixes were sites that styled a button using a webkit gradient. Without the webkit gradient, the user received white text on a white background. So in this case, only webkit browser users saw a button, other browsers saw nothing.
So we're back to UA sniffing circa 1999. Opera took a similar action
by fudging the browser's UA version to "9.80".
> Opera, Firefox, and Microsoft were all receiving bug reports of this nature, in quantity. So it's not really practical to reply to users with a "site developer's fault" - it's a losing proposition, because - much like tomjen3's attitude in this thread - the site developer doesn't care. It's a brick wall in terms of evangelism.
This is reminding me of the ordered enumeration of keys in JavaScript debate. The specification was very clear that order was not to be expected, yet developers complained anyways (including John Resig, oddly enough.) Soon enough, every major browser implemented ordered key enumeration.
I suppose this is why Opera's "browser.js" file exists: to hide the ugly, broken parts of the web. I'd just like it if more time was spent on educating developers, rather than correcting them.
"Sure. However, many of us know how "temporary" code can mold into permanent code."
Oh yes. Even before Opera aliased these thirteen webkit vendor prefixes its pretty clear webkit cannot change how these specific prefixes work any more without breaking those developers who are working in a webkit-only state.
It's past time for these specific vendor prefixes to be formally standardised, and in the interim, every non-webkit browser should now follow Opera's aliasing approach.
There is one issue to be careful of, because these webkit prefixes are not formally part of a W3C specification process there could be issues around intellectual property and patents. That in particular worries me.
52 comments
[ 4.3 ms ] story [ 94.6 ms ] threadAn alternative to vendor prefix could have been draft prefixes instead. So for example, Firefox could say that we have partial implemented `shadow-box` draft 1, so we call it `-d1-shadow-box`. If Firefox had a number of omissions they could instead call it `-ff1-shadow-box`. If an later browser supported shadow-box exactly as Firefox did with the same omisisons, they could simply adopt `-ff1-shadow-box`, which then most likely would later become the standard.
They include "experimental" features just like other browser vendors do. It's hardly their fault that lazy developers only use the -webkit prefixed property.
Fast releases and automated updates only make it worse, as two minutes after a prefixed property is thought up, a seriously large number of users will have support for it, developers will play with it and then the css code gets stuck on the internet.
By now most developers are in the mindset that it's okay to let a page differ in some browsers as long as the difference is only minor/aesthetic and not a functional handicap. And matching this vendors are perfectly happy with letting developers use prefixed properties as if they were stable.
Since these vendors make up the whatwg and w3c, they need to get their shit together and standardize faster and in the meantime developers need incentives to only use prefixed properties on test sites, which could be as simple as a console message that it should be removed (like how they did with the event.layerx deprecation) or having the user enable test mode in their browser configuration.
The only thing the prefix system threatens is a few unimportant browsers that arguably shouldn't even be around anymore and the pride of the w3c.
And you want to save them, by throwing the future of the web under a bus?
For example: webkit devs think of a new property. They build it, they like it, they make it publicly available. Chrome guys enable using this in the dev and beta channel. In a couple weeks they have feedback on performance and stuff. Whatwg convenes, they finalize the details, webkit guys make a few adjustments (and it's fine because there's only 2 webpages on the entire internet that's been using it for a month tops) and then soon it hits the stable channel. This is what we need. Fast updating browsers could rape the benefits of such a system very nicely, fast updating is what we need to let the web evolve fast enough anyway. Slow updating browsers can go die in a fire, they are just as slow with supporting everything else.
Also, not to nitpick, but opera on the mobile front isn't unimportant. It's the only alternative to webkit, it's nearly ubiquitous and not a bad experience on mobile.
There're some prefixed properties which work on all major browser since forever (on a web scale)... but there're still a draft. Reading the minutes of the CSS group is enlightening : everything is really really slow.
Moreover, lots of non-defined prefixed properties don't break pages at all. Rounded corners per exemple are nice, but not displaying them is not a deal breaker. Same thing for transitions : site using them often provide a javascript fallback for non webkit browser.
If Opera wants to support webkit properties, they have to spoof their UA : lots of mobile website are designed for iPhone and Androïd (yes, that's not ideal, but it's a fact). It's the 00's mess again...
Well, if they're writing standards compliant code it's fine if the page is different in different browsers, but I take your point that developers are happy to write non-standards compliant code to provide extra functionality for a few users.
> in the meantime developers need incentives to only use prefixed properties on test sites,
Maybe search engines need to provide boosts for standards-compliance and drops for standards-ignorance.
Users choice of broken browsers should not, repeat not, be allowed to destroy or hold back the web. The web is too important.
This mostly isn't their fault. The main problem is that if any single implementation becomes dominant, we get these problems. And WebKit is dominant on mobile. For the browser market to be healthy again in mobile, we just need more diversity.
But there is also some blame on the WebKit browsers. If, seeing they were about to become dominant in mobile, they had stopped including experimental prefixed functionality in stable release versions, we would not have this problem. Prefixed stuff is not so bad in release versions if there is diversity in the market, but when the market is dominated, it becomes a mess.
Based on this theory, MSIE should not have added new features to IE when it was dominant. This means no AJAX.
Lazy developers caused this problem, and Mozilla/Opera are only going to make it worse by supporting the -webkit- prefixed properties.
Therefore it makes zero sense to not support every css property whose meaning you understand in the next three months (the lifecycle), and in the next version you can correct it if it deviates.
The problem is basically that IE and Opera hasn't been run of the market yet.
I may be biased as long-time users often are, but they're definitely not comparable to the plague that is IE.
In addition I don't recall them being open source.
If they had taken on IE back in the day, it would have been something else but I just can't see why I should care today.
Like blind users are just a few percent? Or people with motor-control disabilities are just a few percent?
250 million users, across both desktop and mobile.
Major websites' patchy support for Opera helps local players ;)
For example, a tool could scan CSS files and compare usage of vendor prefixes against the current state of cross-browser support for "better" alternatives. Perhaps you see warnings like "property 'webkit-xyz' can be replaced by 'xyz', which has been supported by the top 4 browsers since 2006".
I want the web broken for users of broken browsers. I want those who use IE to suffer, so that they will upgrade to better browsers.
I want those who use Opera to stop and to start using a better browser.
I am tired of the progress of the web being hindered by this absurd notion that we should support every browser in existence. We shouldn't.
There's probably lots of CSS that has old -webkit/-moz/whatever tags because it "still works" and there hasn't been time to maintain it properly. A tool like this would make the code smaller, clearer and more future-proof without affecting any of your favorite users. It would just so happen to help fringe-browser users as well. I'd say that's a win-win, especially if you value attracting new customers and making money.
Right now, if I reach a web site that browser-sniffs or doesn't "support" me I go away and never come back. Generally not a useful way to treat visitors.
Opera needs to stop accusing us of being lazy, and to die. They had their attempt and they blew it. Their existens only hinders the progress of the web.
So you driving an old car does not mean I can't drive a new much more fuel-efficient car.
A web browser on the other hand has a gigantic interface between it and the users and as such it is extremely arrogant to assume that the web should be held back due to your choice of browser.
If you don't like the look of it, or whatever you can totally apply skins or plugins to make it obey voice commands (I would love to read a blog post about how you did that) since those things don't interfere with the progress of the web.
http://html5test.com/results/desktop.html
Yes, I agree being held back by one browser is a problem. However, that browser is IE8.
Google and Mozilla may have bigger teams, but the most innovation is still coming out of Norway.
Opera Mini works very well on mobile phones for example.
You're also on a web site with a lot of people working at startups: pretty much the epitome of not accepting the status quo and creating new things. If we all said "screw it" when big projects took over, the world would be a lot less interesting.
Firefox doesn't support the webkit-prefixed CSS properties. They are also considering going down the same road as Opera and implementing these non-standard CSS extensions.
Stop opening your Christmas presents at Easter.
(sorry; typed from a mobile device)
Yes, it's wonderful that pages can be translated in a three-dimensional fashion now. I'd prefer to wait until six different declarations aren't required to know about it, though.
Users, stop using broken browser. You are only holding the rest of us back.
The salient point is for the developer to use discretion before toying with bleeding-edge features.
A better idea is for developers not to rely solely on vendor prefixes. Use them, but don't rely on them.
One of the use-cases that led Opera to support webkit prefixes were sites that styled a button using a webkit gradient. Without the webkit gradient, the user received white text on a white background. So in this case, only webkit browser users saw a button, other browsers saw nothing.
Opera, Firefox, and Microsoft were all receiving bug reports of this nature, in quantity. So it's not really practical to reply to users with a "site developer's fault" - it's a losing proposition, because - much like tomjen3's attitude in this thread - the site developer doesn't care. It's a brick wall in terms of evangelism.
Opera have taken 13 webkit prefixes and aliased them as opera prefixed - when the corresponding opera prefix isn't present. That is a practical user-centric solution that works until vendor-prefixes are crushed under the weight of technical debt.
(London Web Standards hosted State of the Browser today - http://browser.londonwebstandards.org/ , including a panel session with representatives from Opera, Firefox, Internet Explorer and Chrome panelists - no Safari representative, Apple declined the invitation. Hope they upload the video, it's worth watching, particularly for Opera's Bruce Lawson's comments about webkit aliasing)
Sure. However, many of us know how "temporary" code can mold into permanent code.
> One of the use-cases that led Opera to support webkit prefixes were sites that styled a button using a webkit gradient. Without the webkit gradient, the user received white text on a white background. So in this case, only webkit browser users saw a button, other browsers saw nothing.
So we're back to UA sniffing circa 1999. Opera took a similar action by fudging the browser's UA version to "9.80".
> Opera, Firefox, and Microsoft were all receiving bug reports of this nature, in quantity. So it's not really practical to reply to users with a "site developer's fault" - it's a losing proposition, because - much like tomjen3's attitude in this thread - the site developer doesn't care. It's a brick wall in terms of evangelism.
This is reminding me of the ordered enumeration of keys in JavaScript debate. The specification was very clear that order was not to be expected, yet developers complained anyways (including John Resig, oddly enough.) Soon enough, every major browser implemented ordered key enumeration.
I suppose this is why Opera's "browser.js" file exists: to hide the ugly, broken parts of the web. I'd just like it if more time was spent on educating developers, rather than correcting them.
Oh yes. Even before Opera aliased these thirteen webkit vendor prefixes its pretty clear webkit cannot change how these specific prefixes work any more without breaking those developers who are working in a webkit-only state.
It's past time for these specific vendor prefixes to be formally standardised, and in the interim, every non-webkit browser should now follow Opera's aliasing approach.
There is one issue to be careful of, because these webkit prefixes are not formally part of a W3C specification process there could be issues around intellectual property and patents. That in particular worries me.
EDIT: someone in this topic linked to prefixfree, which is what I asked for, except it's not browser-native.
At this point there are enough prefixes to make manually adding each more than a bit pointless.