Opera Confirms WebKit Prefix Usage
farukat.es
farukat.es
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.
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.
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.
At this point there are enough prefixes to make manually adding each more than a bit pointless.
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.
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.
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.
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.