4 ms·

Not using vendor prefixes isn't a better idea. The reason for vendor prefixes is to allow developers to experiment with these features and feedback bugs, issues

Not using vendor prefixes isn't a better idea. The reason for vendor prefixes is to allow developers to experiment with these features and feedback bugs, issues, improvements and future feature suggestions. It's a testing ground, and the web is a great environment to collect information about that testing. So not supporting vendors efforts doesn't encourage them to innovate. Perhaps these vendor prefixes should be limited to alpha/beta versions of browsers instead? A better idea is for developers not to rely solely on vendor prefixes. Use them, but don't rely on them. One of the use-cases that led Opera to support webkit prefixes were sites that styled a button using a webkit gradient. Without the webkit gradient, the user received white text on a white background. So in this case, only webkit browser users saw a button, other browsers saw nothing. Opera, Firefox, and Microsoft were all receiving bug reports of this nature, in quantity. So it's not really practical to reply to users with a "site developer's fault" - it's a losing proposition, because - much like tomjen3's attitude in this thread - the site developer doesn't care. It's a brick wall in terms of evangelism. Opera have taken 13 webkit prefixes and aliased them as opera prefixed - when the corresponding opera prefix isn't present. That is a practical user-centric solution that works until vendor-prefixes are crushed under the weight of technical debt. (London Web Standards hosted State of the Browser today - http://browser.londonwebstandards.org/ http://browser.londonwebstandards.org/ , including a panel session with representatives from Opera, Firefox, Internet Explorer and Chrome panelists - no Safari representative, Apple declined the invitation. Hope they upload the video, it's worth watching, particularly for Opera's Bruce Lawson's comments about webkit aliasing)

mkmcdonald 14y ago
> A better idea is for developers not to rely solely on vendor prefixes. Use them, but don't rely on them. Sure. However, many of us know how "temporary" code can mold into permanent code. > One of the use-cases that led Opera to support webkit prefixes were sites that styled a button using a webkit gradient. Without the webkit gradient, the user received white text on a white background. So in this case, only webkit browser users saw a button, other browsers saw nothing. So we're back to UA sniffing circa 1999. Opera took a similar action by fudging the browser's UA version to "9.80". > Opera, Firefox, and Microsoft were all receiving bug reports of this nature, in quantity. So it's not really practical to reply to users with a "site developer's fault" - it's a losing proposition, because - much like tomjen3's attitude in this thread - the site developer doesn't care. It's a brick wall in terms of evangelism. This is reminding me of the ordered enumeration of keys in JavaScript debate. The specification was very clear that order was not to be expected, yet developers complained anyways (including John Resig, oddly enough.) Soon enough, every major browser implemented ordered key enumeration. I suppose this is why Opera's "browser.js" file exists: to hide the ugly, broken parts of the web. I'd just like it if more time was spent on educating developers, rather than correcting them.
- Isofarro 14y ago
  "Sure. However, many of us know how "temporary" code can mold into permanent code." Oh yes. Even before Opera aliased these thirteen webkit vendor prefixes its pretty clear webkit cannot change how these specific prefixes work any more without breaking those developers who are working in a webkit-only state. It's past time for these specific vendor prefixes to be formally standardised, and in the interim, every non-webkit browser should now follow Opera's aliasing approach. There is one issue to be careful of, because these webkit prefixes are not formally part of a W3C specification process there could be issues around intellectual property and patents. That in particular worries me.

mkmcdonald 14y ago

> A better idea is for developers not to rely solely on vendor prefixes. Use them, but don't rely on them. Sure. However, many of us know how "temporary" code can mold into permanent code. > One of the use-cases that led Opera to support webkit prefixes were sites that styled a button using a webkit gradient. Without the webkit gradient, the user received white text on a white background. So in this case, only webkit browser users saw a button, other browsers saw nothing. So we're back to UA sniffing circa 1999. Opera took a similar action by fudging the browser's UA version to "9.80". > Opera, Firefox, and Microsoft were all receiving bug reports of this nature, in quantity. So it's not really practical to reply to users with a "site developer's fault" - it's a losing proposition, because - much like tomjen3's attitude in this thread - the site developer doesn't care. It's a brick wall in terms of evangelism. This is reminding me of the ordered enumeration of keys in JavaScript debate. The specification was very clear that order was not to be expected, yet developers complained anyways (including John Resig, oddly enough.) Soon enough, every major browser implemented ordered key enumeration. I suppose this is why Opera's "browser.js" file exists: to hide the ugly, broken parts of the web. I'd just like it if more time was spent on educating developers, rather than correcting them.

Isofarro 14y ago
"Sure. However, many of us know how "temporary" code can mold into permanent code." Oh yes. Even before Opera aliased these thirteen webkit vendor prefixes its pretty clear webkit cannot change how these specific prefixes work any more without breaking those developers who are working in a webkit-only state. It's past time for these specific vendor prefixes to be formally standardised, and in the interim, every non-webkit browser should now follow Opera's aliasing approach. There is one issue to be careful of, because these webkit prefixes are not formally part of a W3C specification process there could be issues around intellectual property and patents. That in particular worries me.