4 ms·

WebKit. Killing the open web since 1998.

by Tomis02 14y ago

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.
  - mddw 14y ago
    I agree. 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...
- 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?

WebKit. Killing the open web since 1998.

by Tomis02 14y ago

WebKit. Killing the open web since 1998.

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.
- mddw 14y ago
  I agree. 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...
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?