Opera confirms support for WebKit vendor prefixes(netmagazine.com) |
Opera confirms support for WebKit vendor prefixes(netmagazine.com) |
There is a varying degree of a WebKit monoculture on mobile. Without great site compatibility, users will never successfully switch to a non-webkit browser, but currently much of the great mobile content out there assumes webkit prefixes and userAgent. So Opera, Mozilla, and MS basically need to adopt some of the mobile webkit properties in order to get compatibility, in order to get users. It's either that or advocacy wherein we try to get every site ever to not publish with just WebKit prefixes. But in reality, this advocacy effort has been underway already for over two years and we're still in this bad situation.
Look at the chart linked to from http://paulirish.com/2012/vendor-prefixes-are-not-developer-... When IE10 comes out (or it's complementary mobile browser), less than 25% of all sites that use CSS transitions will have them working in IE10.
Vendor prefixes are bad for us as developers and they're bad for browsers because it leads to situations like these. We'd be in a better situation without them.
BTW, one detail that wasn't really covered: I believe this change is localized to Opera's mobile browsers. Their desktop story is, I think, unchanged.
(All the above is a personal opinion and not that of my employer, yadda yadda)
My attitude is that if you don't want to test on anything other than Safari Mobile and Android Browser then fine, don't test, but let the site degrade gracefully or not on other browsers.
In practice, graceful degradation requires testing.
We've done this before and handled it fine. In JavaScript you can test the features, in CSS you end up duplicating a few lines of CSS-- see the gradients example: http://paulirish.com/2012/vendor-prefixes-are-not-developer-...
I've probably missed some killer feature of a multi-engine standards-based ecosystem, but really -- is that the pace at which we want to move the web forward?
(http://www.quirksmode.org/blog/archives/2012/02/the_vendor_p...)
If you all remember back in the IE6 dominated days, Opera was built to the web standards but in order to make it a viable browser for pages that were only tested in IE6, they had to try to emulate IE6 behavior in Quirks mode, and I'm sure Mozilla had to do the same thing.
Hopefully this is a short-term thing unless standards are more finalized and browser implementations become more consistent.
Standards are standards - period. I see ton of wrong with this approach, or... mabye we should just ignore the w3C CSS Working group.
Vendor prefixes are fine - as long they are used as temporary solution, and no one expects them to be the "default" way of doing things.
There is something inherently wrong with vendor prefixes as they are used currently. But in the same time they are good if some browser wants to implement a new alpha feature or something.. but they should really not be supported for so much time as they are now.
After a prefixed extension gains market adoption, it serves to indicate which implementation is authoritative. -webkit means you better do it the way webkit does it.
Any browser that won't make use of the author's intent, when that intent is unambiguous and easy to determine, is just shooting itself in the foot.
I've written a bit more about these "WODs" at http://www.iandevlin.com/blog/2012/04/css/on-vendor-prefixes...
So now when I create something that requires a browser that actually has good hardware acceleration, it will be a dastardly turd of a performer in Opera.
This is what happened with Microsoft and IE6. IE6 launched in 2001. Microsoft didn't care updating it for the next 6 years. This lead to a rise of Flash in websites, which at the time seemed like a good solution to fill the lack of support of CSS. But then it also lead to a lack of innovation in Flash, and Adobe never cared about its plugin optimization or security.
Adobe never cared about its plugin optimization or security
I don't think that's fair. Adobe released frequent updates for security, and less-frequent but still consistent updates for optimizations/new features.But why should we blame monopoly? MS had no competitor in the desktop space (even now, OS X has like 10% and Linux around 1%), and still they improved Windows continuously from 3.1 to 8. Same for Office. After the demise of WordPerfect, it never had any serious competitor --even today the vast majority of people choose it over the free OpenOffice, whereas Google Docs have insignificant user share (from what I've read). Still, MS continuously added things to do. Same for Photoshop, Illustrator, etc. They did not have any competitor, especially with Macromedia acquired (Corel's software is not used by the majority of graphic designers, and almost nobody uses Gimp outside of Linux), and yet, Photoshop just received it's most substantial update to date.
So, monopoly != necessary stagnation.
So all of 0.1% of web designers who use Opera can change them?
Same is true now of IndexedDB.
So, some of those are not bugs, are differences in features.
XHTML shows what happens when you try to agree on everything upfront. You mention agreeing on a basic syntax. The browser developers generally do discuss ideas for new features in basic terms before they release them, and hopefully there's some vague sense of agreement between at least two browsers before a feature goes alpha. But agreeing on anything more than that, instead of just hammering out a working implementation, means developers end up with APIs that are hard to use and don't address their users' needs.
Like I said before, they are getting better at agreeing on basic syntax at least. I would say don't make it available until the basics have been decided on. If they are still arguing over details that require a prefix then it isn't ready for release.
IndexedDB - Chrome Mobile has it (outdated version), Android and iPhone do not.
Chrome will have Dart support at a later date, no other WebKit vendor is going to implement it.
There are literally dozens, just go to caniuse.com and play around for a bit.