13 ms·

It's debatable whether WebKit did or didn't do anything wrong. If vendor prefixes appeared only in developer version of the browser, instead of stable releases,

by azakai 15y ago

It's debatable whether WebKit did or didn't do anything wrong. If vendor prefixes appeared only in developer version of the browser, instead of stable releases, we wouldn't be in this situation - and developers would still get preview access to new browser features for testing, to prepare for when they become standardized. Instead, the major WebKit browsers include vendor prefixed stuff in stable releases. Since WebKit won in mobile (and is on the way to winning overall), it isn't surprising we got to where we are now, with all other browsers planning to implement WebKit prefixed features.

kalleboo 15y ago
If WebKit didn't include vendor prefixes in stable releases, we'd still be here 6 years after they first implemented it putting PNG files in the corners of all our divs. The problems are the standards aren't there. The standards organization is just way too slow.
- TeeWEE 15y ago
  I totally agree. W3C is slow. But standards are like politics. You cannot blame W3C for 1 of the 10 parties not agreeing with the spec. And once we got it we are bound to it. This is the reason native is always better then web. Once the technology is available one party will provide an api and it will be available in the next version of the OS. Native is a free market approach, may the best man win. But propietary. Web is like socialism. Everybody gets the same but the whole system doesnt drive innovation.
masklinn 15y ago
One of the problems is, vendor prefixes have both "beta" and "proprietary" meanings. And there's no way to disambiguate from the property's name. And browser vendors will ship proprietary extensions, whether you like it or not.
magicalist 15y ago
Mobile Firefox includes vendor prefixes, and has from the beginning. All the new Web API stuff will be prefixed where appropriate. That's exactly what standard operating procedure calls for (whether right or wrong) and what mobile WebKit has mostly done (and we're really talking Apple here, at least for the first year or two and a bunch of major CSS spec drafts). In other words, you didn't actually say what actions may or may not have been wrong.
- azakai 15y ago
  Including vendor prefixes in a release build, I said, is arguably wrong. I'm not arguing that it is - I honestly don't know which is better, as not including them has downsides too. And, as you said, other browsers do this too (but less recently), it isn't a WebKit-specific thing. The only difference is that WebKit won on mobile and has become the dominant web rendering engine there, between Android and iOS (and Blackberry, WebOS, etc. etc., pretty much everyone uses WebKit on mobile). The only solution to this would be to not have a single implementation dominate the market. But that has already happened on mobile, the question is now how to live with that. (And there is risk on desktop too.)

by azakai 15y ago

kalleboo 15y ago

If WebKit didn't include vendor prefixes in stable releases, we'd still be here 6 years after they first implemented it putting PNG files in the corners of all our divs. The problems are the standards aren't there. The standards organization is just way too slow.

TeeWEE 15y ago
I totally agree. W3C is slow. But standards are like politics. You cannot blame W3C for 1 of the 10 parties not agreeing with the spec. And once we got it we are bound to it. This is the reason native is always better then web. Once the technology is available one party will provide an api and it will be available in the next version of the OS. Native is a free market approach, may the best man win. But propietary. Web is like socialism. Everybody gets the same but the whole system doesnt drive innovation.

masklinn 15y ago

One of the problems is, vendor prefixes have both "beta" and "proprietary" meanings. And there's no way to disambiguate from the property's name. And browser vendors will ship proprietary extensions, whether you like it or not.

magicalist 15y ago

Mobile Firefox includes vendor prefixes, and has from the beginning. All the new Web API stuff will be prefixed where appropriate. That's exactly what standard operating procedure calls for (whether right or wrong) and what mobile WebKit has mostly done (and we're really talking Apple here, at least for the first year or two and a bunch of major CSS spec drafts). In other words, you didn't actually say what actions may or may not have been wrong.

azakai 15y ago
Including vendor prefixes in a release build, I said, is arguably wrong. I'm not arguing that it is - I honestly don't know which is better, as not including them has downsides too. And, as you said, other browsers do this too (but less recently), it isn't a WebKit-specific thing. The only difference is that WebKit won on mobile and has become the dominant web rendering engine there, between Android and iOS (and Blackberry, WebOS, etc. etc., pretty much everyone uses WebKit on mobile). The only solution to this would be to not have a single implementation dominate the market. But that has already happened on mobile, the question is now how to live with that. (And there is risk on desktop too.)