8 ms·

Opera Confirms WebKit Prefix Usage

33 points by brodd 14y ago

driax 14y ago
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.
- justincormack 14y ago
  They are generally unlikely to have good enough test cases to make sure they implement these the same, as they are experimental.
Tomis02 14y ago
WebKit. Killing the open web since 1998.
- stephenr 14y ago
  How exactly is this the fault of the webkit team? Lazy developers caused this, combined with a stupid response from the browser makers.
  - Tomis02 14y ago
    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).
    - deleted 14y ago
      [deleted]
    - deleted 14y ago
      [deleted]
    - stephenr 14y ago
      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.
  - csulok 14y ago
    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.
    - tomjen3 14y ago
      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?
      - csulok 14y ago
        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.
  - zxoq 14y ago
    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.
  - tomjen3 14y ago
    LAZY? Users choice of broken browsers should not, repeat not, be allowed to destroy or hold back the web. The web is too important.
  - azakai 14y ago
    > 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.
    - stephenr 14y ago
      Sure, we should let the actions of lazy developers dictate the direction of web technologies. 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.
- iso8859-1 14y ago
  You can't blame it on KHTML. Are you seriously saying that you think Konqueror with a market share of like 0.1% was killing the open web back then?
guard-of-terra 14y ago
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.
- tomjen3 14y ago
  Actually all browsers, except IE, should update themselves per default. The problem is basically that IE and Opera hasn't been run of the market yet.
  - luminarious 14y ago
    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.
    - tomjen3 14y ago
      They have just a few percent of the market and they expect us to write special CSS codes just for them. 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.
      - DanBC 14y ago
        > They have just a few percent of the market Like blind users are just a few percent? Or people with motor-control disabilities are just a few percent?
        tomjen3 14y ago
makecheck 14y ago
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".
- tomjen3 14y ago
  Why would I want to run such a tool? 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.
  - hnhg 14y ago
    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?
    - tomjen3 14y ago
      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).
  - makecheck 14y ago
    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.
tomjen3 14y ago
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.
- melling 14y ago
  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.
  - tomjen3 14y ago
    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.
    - melling 14y ago
      Are you still talking about Opera? They are aggressively trying to be compatible? They are even implementing WebGL. http://html5test.com/results/desktop.html http://html5test.com/results/desktop.html Yes, I agree being held back by one browser is a problem. However, that browser is IE8.
- mkmcdonald 14y ago
  Opera has long been the most innovative and standards-compliant browser available. Google and Mozilla may have bigger teams, but the most innovation is still coming out of Norway.
mkmcdonald 14y ago
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. Stop opening your Christmas presents at Easter. (sorry; typed from a mobile device)
- rmccue 14y ago
  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.
  - Isofarro 14y ago
    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.
  - mkmcdonald 14y ago
    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.
- tomjen3 14y ago
  So because people continue to build bad browsers, it is somehow my fault that their users can't enjoy what the rest of the world gets to see? Users, stop using broken browser. You are only holding the rest of us back.
  - mkmcdonald 14y ago
    "bad" is quite relative here. Have you taken a glance at Chrome, Firefox or Opera recently? They're very innovative programs. The salient point is for the developer to use discretion before toying with bleeding-edge features.
luminarious 14y ago
I wonder how this will affect those who have started using javascript aids like http://leaverou.github.com/prefixfree/ http://leaverou.github.com/prefixfree/ At this point there are enough prefixes to make manually adding each more than a bit pointless.

33 points by brodd 14y ago

driax 14y ago

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.

justincormack 14y ago
They are generally unlikely to have good enough test cases to make sure they implement these the same, as they are experimental.

Tomis02 14y ago

WebKit. Killing the open web since 1998.

stephenr 14y ago
How exactly is this the fault of the webkit team? Lazy developers caused this, combined with a stupid response from the browser makers.
- Tomis02 14y ago
  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).
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - stephenr 14y ago
    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.
- csulok 14y ago
  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.
  - tomjen3 14y ago
    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?
    - csulok 14y ago
      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.
- zxoq 14y ago
  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.
- tomjen3 14y ago
  LAZY? Users choice of broken browsers should not, repeat not, be allowed to destroy or hold back the web. The web is too important.
- azakai 14y ago
  > 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.
  - stephenr 14y ago
    Sure, we should let the actions of lazy developers dictate the direction of web technologies. 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.
iso8859-1 14y ago
You can't blame it on KHTML. Are you seriously saying that you think Konqueror with a market share of like 0.1% was killing the open web back then?

guard-of-terra 14y ago

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.

tomjen3 14y ago
Actually all browsers, except IE, should update themselves per default. The problem is basically that IE and Opera hasn't been run of the market yet.
- luminarious 14y ago
  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.
  - tomjen3 14y ago
    They have just a few percent of the market and they expect us to write special CSS codes just for them. 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.
    - DanBC 14y ago
      > They have just a few percent of the market Like blind users are just a few percent? Or people with motor-control disabilities are just a few percent?
      - tomjen3 14y ago

makecheck 14y ago

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

tomjen3 14y ago
Why would I want to run such a tool? 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.
- hnhg 14y ago
  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?
  - tomjen3 14y ago
    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).
- makecheck 14y ago
  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.

tomjen3 14y ago

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.

melling 14y ago
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.
- tomjen3 14y ago
  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.
  - melling 14y ago
    Are you still talking about Opera? They are aggressively trying to be compatible? They are even implementing WebGL. http://html5test.com/results/desktop.html http://html5test.com/results/desktop.html Yes, I agree being held back by one browser is a problem. However, that browser is IE8.
mkmcdonald 14y ago
Opera has long been the most innovative and standards-compliant browser available. Google and Mozilla may have bigger teams, but the most innovation is still coming out of Norway.

mkmcdonald 14y ago

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. Stop opening your Christmas presents at Easter. (sorry; typed from a mobile device)

rmccue 14y ago
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.
- Isofarro 14y ago
  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.
- mkmcdonald 14y ago
  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.
tomjen3 14y ago
So because people continue to build bad browsers, it is somehow my fault that their users can't enjoy what the rest of the world gets to see? Users, stop using broken browser. You are only holding the rest of us back.
- mkmcdonald 14y ago
  "bad" is quite relative here. Have you taken a glance at Chrome, Firefox or Opera recently? They're very innovative programs. The salient point is for the developer to use discretion before toying with bleeding-edge features.

luminarious 14y ago

I wonder how this will affect those who have started using javascript aids like http://leaverou.github.com/prefixfree/ http://leaverou.github.com/prefixfree/ At this point there are enough prefixes to make manually adding each more than a bit pointless.