Live data from Hacker News

Opera confirms support for WebKit vendor prefixes

netmagazine.com

11–20 of 50 posts

Re: Opera confirms support for WebKit vendor prefixes

#11

This is a good thing, and there is basically no way around it. 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 c…

Is vendor prefixing really worse than UA sniffing Paul? Your employer is one of the worst offenders of the latter (not blaming you). Maps, for example, falls back to a very primitive version in Firefox Mobile despite it being perfectly capable of rendering the more advanced site.

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.

Re: Opera confirms support for WebKit vendor prefixes

#12

This is a good thing, and there is basically no way around it. 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 c…

What would happen in the situation that a browser has developed a non-prefixed property, which later becomes a standard, but with different functionality?

Re: Opera confirms support for WebKit vendor prefixes

#13

This is a good thing, and there is basically no way around it. 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 c…

What would happen in the situation that a browser has developed a non-prefixed property, which later becomes a standard, but with different functionality?

Prior art of vendor features that were introduced sans prefix: innerHTML, XMLHttpRequest, , querySelectorAll, innerText...

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-...

Re: Opera confirms support for WebKit vendor prefixes

#14
I know everyone talks about fragmentation concerns, and WebKit as the new IE6, but does this argument really make any sense? Internet Explorer was a poorly updated, closed source product that only worked on a single platform; WebKit is open source, maintained by two separate companies (that are basically locked in a cold war), and is available on all major platforms. If anything, why isn't the notion of a single rendering engine to which we can all write a GOOD thing? I know there's lots of idealism around standards, etc, but let's get real here -- most people building a webpage simply want it to render properly and universally, and would like to take advantage of cutting-edge technologies. Agreeing on a single rendering engine seems to be the easiest way of accomplishing this goal.

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?

Re: Opera confirms support for WebKit vendor prefixes

#15

This is hopefully the moment where things have become so absurd (not a criticism of Opera) that it's time for browsers and standards to tackle the problem e.g. look at the proposed -beta flag. ( http://www.quirksmode.org/blog/archives/2012/02/the_vendor_p... )

If all the browsers use the same prefix then why use one at all?

Re: Opera confirms support for WebKit vendor prefixes

#16
post #14

I know everyone talks about fragmentation concerns, and WebKit as the new IE6, but does this argument really make any sense? Internet Explorer was a poorly updated, closed source product that only worked on a single platform; WebKit is open source, maintained by two separate companies (that are basically locked in a cold war), and is available on all major platforms. If anything, why isn't the notion of a single rend…

A monopoly leads to a lack of innovation. A lack of innovation leads to proprietary solutions. Proprietary solutions lead to a lack of innovation.

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.

Re: Opera confirms support for WebKit vendor prefixes

#17
post #14

I know everyone talks about fragmentation concerns, and WebKit as the new IE6, but does this argument really make any sense? Internet Explorer was a poorly updated, closed source product that only worked on a single platform; WebKit is open source, maintained by two separate companies (that are basically locked in a cold war), and is available on all major platforms. If anything, why isn't the notion of a single rend…

WebKit is not controlled by 2 companies and WebKit is not a single rendering engine. WebKit is a single upstream project, the downstream browsers differ from each other just as much as they differ from gecko or presto based browsers.

Re: Opera confirms support for WebKit vendor prefixes

#18

Earlier quoted context omitted.

What would happen in the situation that a browser has developed a non-prefixed property, which later becomes a standard, but with different functionality?

Prior art of vendor features that were introduced sans prefix: innerHTML, XMLHttpRequest, , querySelectorAll, innerText... 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-...

Dropping vendor prefixes entirely is a bad idea. The syntax for gradients has been revised a couple of times. Without vendor prefixes you'd have to pick which version to support, back when different browsers had different implementations.

Same is true now of IndexedDB.

Re: Opera confirms support for WebKit vendor prefixes

#19
I've been telling the IE team to do this since IE 9. In reality, the purpose of vendor prefixes is to keep two vendors from using the same name for two distinctly different behaviors. The current prefix model does that.

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.

Re: Opera confirms support for WebKit vendor prefixes

#20
post #15

This is hopefully the moment where things have become so absurd (not a criticism of Opera) that it's time for browsers and standards to tackle the problem e.g. look at the proposed -beta flag. ( http://www.quirksmode.org/blog/archives/2012/02/the_vendor_p... )

If all the browsers use the same prefix then why use one at all?

Because the behavior of the beta feature may be different from the behavior of the final version.
Post reply on HN