9 ms·

Opera confirms support for WebKit vendor prefixes

47 points by intranation 14y ago

ergo14 14y ago
What an idiotic move - So now they want to make webkit the next IE of internet? 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.
- robertnn 14y ago
  Lots of people implicitly expects them to be working in the long run. Lots of people will read a tutorial on how to get the cool animation X and the tutorial will only include the -webkit-property, and the reader won't even bother that he is excluding a big part of the users, because he uses only a webkit browser, so he won't notice. 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.
- eli 14y ago
  Historically, the standards that have been most successful have been the ones that describe what people are already doing
  - ergo14 14y ago
    Eli, but notice what the article says - some developers use vendor prefixes to do something that already IS in standards. There is a very good reason W3C is out there. I don't know how old are some of the people commenting here, but we were in this situation in past.
- cpeterso 14y ago
  Opera is not making WebKit the new IE; web developers who only use -webkit CSS prefixes have done that.
  - ergo14 14y ago
    By this move they are essentially legitimizing it. The only way to oppose stupidity is to not agree to it.
    - politician 14y ago
      Exactly, couldn't Opera instead release an advisory tool which examines stylesheets and points out how to convert -webkit- prefixes to a) standards or b) -o- prefixes?
    - batista 14y ago
      >Exactly, couldn't Opera instead release an advisory tool which examines stylesheets and points out how to convert -webkit- prefixes to a) standards or b) -o- prefixes? So all of 0.1% of web designers who use Opera can change them?
paulirish 14y ago
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 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-friendly/ 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)
- MatthewPhillips 14y ago
  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.
  - politician 14y ago
    > don't test, but let the site degrade gracefully In practice, graceful degradation requires testing.
    - MatthewPhillips 14y ago
Osiris 14y ago
In some ways, I understand the need the vendor prefixes, but they do seem to be causing some fragmentation. I'm getting to the point on some CSS properties that I just use the real CSS name (like border-radius) and don't use the vendor prefixes at all since all the major browers that support radius use the non-prefixed name. 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.
zalew 14y ago
next move: spoof user-agent to appear as chrome. hello mozilla compatible internet explorer
mmahemoff 14y ago
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_pref.html http://www.quirksmode.org/blog/archives/2012/02/the_vendor_p...)
- talmand 14y ago
  If all the browsers use the same prefix then why use one at all?
  - wmf 14y ago
    Because the behavior of the beta feature may be different from the behavior of the final version.
    - talmand 14y ago
      I would prefer an experimental feature not be implemented until at least the syntax has been decided on. Prefixes were implemented so that browsers could have experimental features in place and look where we are now. Adding in a prefix, even a single one, doesn't change the fact that if present then people will use it. If the syntax changes during the -beta prefix phase then lots of stuff will be broken anyway. Can the browser companies at least get their crap together to decide on a basic syntax and then expand on it if needed? Lately they seem to be able to do that with some of the newer properties but we still have prefixes.
      - mmahemoff 14y ago
        Vendor prefixes have turned out to be unsuccessful, but letting browsers move ahead before standards is the best thing that could have happened for the web. And the web apps we see today are evidence of it. 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.
macco 14y ago
Smart move.
Tomis02 14y ago
Unfortunately it can't be helped, adhering strictly to the standards loses market share. Yesterday Internet Explorer, today webkit.
numair 14y ago
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?
- mcpoulet 14y ago
  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.
  - batista 14y ago
    >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. 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.
kogir 14y ago
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.
amadeus 14y ago
Wonderful [sarcasm]. 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.
- ernesth 14y ago
  No, it will continue to be fast on opera and firefox and to be a "dastardly turd" on chrome and safari: only some selected -webkit- properties will be translated by opera.
iandevlin 14y ago
I think this is a bad idea as it's supporting bad, lazy developers who can't be bothered to learn their craft correctly. I've written a bit more about these "WODs" at http://www.iandevlin.com/blog/2012/04/css/on-vendor-prefixes-and-wods http://www.iandevlin.com/blog/2012/04/css/on-vendor-prefixes...

47 points by intranation 14y ago

What an idiotic move - So now they want to make webkit the next IE of internet? 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.

robertnn 14y ago
Lots of people implicitly expects them to be working in the long run. Lots of people will read a tutorial on how to get the cool animation X and the tutorial will only include the -webkit-property, and the reader won't even bother that he is excluding a big part of the users, because he uses only a webkit browser, so he won't notice. 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.
eli 14y ago
Historically, the standards that have been most successful have been the ones that describe what people are already doing
- ergo14 14y ago
  Eli, but notice what the article says - some developers use vendor prefixes to do something that already IS in standards. There is a very good reason W3C is out there. I don't know how old are some of the people commenting here, but we were in this situation in past.
cpeterso 14y ago
Opera is not making WebKit the new IE; web developers who only use -webkit CSS prefixes have done that.
- ergo14 14y ago
  By this move they are essentially legitimizing it. The only way to oppose stupidity is to not agree to it.
  - politician 14y ago
    Exactly, couldn't Opera instead release an advisory tool which examines stylesheets and points out how to convert -webkit- prefixes to a) standards or b) -o- prefixes?
  - batista 14y ago
    >Exactly, couldn't Opera instead release an advisory tool which examines stylesheets and points out how to convert -webkit- prefixes to a) standards or b) -o- prefixes? So all of 0.1% of web designers who use Opera can change them?

paulirish 14y ago

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 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-friendly/ 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)

MatthewPhillips 14y ago
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.
- politician 14y ago
  > don't test, but let the site degrade gracefully In practice, graceful degradation requires testing.
  - MatthewPhillips 14y ago

Osiris 14y ago

In some ways, I understand the need the vendor prefixes, but they do seem to be causing some fragmentation. I'm getting to the point on some CSS properties that I just use the real CSS name (like border-radius) and don't use the vendor prefixes at all since all the major browers that support radius use the non-prefixed name. 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.

zalew 14y ago

next move: spoof user-agent to appear as chrome. hello mozilla compatible internet explorer

mmahemoff 14y ago

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_pref.html http://www.quirksmode.org/blog/archives/2012/02/the_vendor_p...)

talmand 14y ago
If all the browsers use the same prefix then why use one at all?
- wmf 14y ago
  Because the behavior of the beta feature may be different from the behavior of the final version.
  - talmand 14y ago
    I would prefer an experimental feature not be implemented until at least the syntax has been decided on. Prefixes were implemented so that browsers could have experimental features in place and look where we are now. Adding in a prefix, even a single one, doesn't change the fact that if present then people will use it. If the syntax changes during the -beta prefix phase then lots of stuff will be broken anyway. Can the browser companies at least get their crap together to decide on a basic syntax and then expand on it if needed? Lately they seem to be able to do that with some of the newer properties but we still have prefixes.
    - mmahemoff 14y ago
      Vendor prefixes have turned out to be unsuccessful, but letting browsers move ahead before standards is the best thing that could have happened for the web. And the web apps we see today are evidence of it. 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.

macco 14y ago

Smart move.

Tomis02 14y ago

Unfortunately it can't be helped, adhering strictly to the standards loses market share. Yesterday Internet Explorer, today webkit.

numair 14y ago

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?

mcpoulet 14y ago
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.
- batista 14y ago
  >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. 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.

kogir 14y ago

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.

amadeus 14y ago

Wonderful [sarcasm]. 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.

ernesth 14y ago
No, it will continue to be fast on opera and firefox and to be a "dastardly turd" on chrome and safari: only some selected -webkit- properties will be translated by opera.

iandevlin 14y ago

I think this is a bad idea as it's supporting bad, lazy developers who can't be bothered to learn their craft correctly. I've written a bit more about these "WODs" at http://www.iandevlin.com/blog/2012/04/css/on-vendor-prefixes-and-wods http://www.iandevlin.com/blog/2012/04/css/on-vendor-prefixes...