Hacker News Reader

Comment by mkmcdonald | Hacker News Reader

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)

View on HN

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

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

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

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.

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.

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.

Why don't browsers accept prefix-less properties and render them as if they were prefixed, until those properties make it to a standard?

EDIT: someone in this topic linked to prefixfree, which is what I asked for, except it's not browser-native.

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.

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

The web is an open platform that should remain device agnostic. Coding for a subset of available browsers is the kind of idiotic behavior that caused so many issues when IE was popular.

Reply on news.ycombinator.com