HN2new | past | comments | ask | show | jobs | submitlogin

If you read the article referenced, web-kit isn't being picked on especially. The concept of using vendor prefixes is being questioned.

There's a valid rationale to not using vendor-prefixes, because it could potentially add confusion and erode standards.

From my understanding, in effort to display web-pages at their best, some browser manufacturers are starting to honour the browser prefixes used by other vendors. I can see how this could create problems.



It's a little hard for me to avoid the impression that W3C partisans hate vendor extensions because they make it easier for websites to handle cross-platform support for extensions. -moz-border-radius and -webkit-border-radius is ugly but nothing more; conflicting definitions of "border-radius" is a showstopper.

Which, if you're cynical, is how the W3C probably wants it.


The alternative isn't to stop using the properties - it's to stop using the vendor prefixes. That's all that's being suggested.

I think your aggressive anti-W3C stance is really misguided. They're not the bad guys.

If you actually read the article referenced in the dcurt.is article, you'd see how vendor extensions are actually becoming something more than just ugly. Which is the whole point of the suggestion.


The argument in that article is adequately summed up by Dustin Curtis. The problem with vendor extensions is that when one browser ends up dominant, the others eventually end up having to implement that browser's extensions.

What I don't get is how this makes that browser a "monopoly". The only thing Webkit won was the string "-webkit" in the CSS property. It's the monopoly that gives the monopoly to Webkit. Not CSS vendor prefixes. Webkit has a virtual monopoly among mobile browsers.


The problem isn't that one browser is dominant. The problem is when Apple develops a feature entirely in secret and then doesn't bring it to a standards body, forcing other browser vendors to reverse-engineer that feature. Apple is shipping those features, and evangelizing them to developers, before the other browser vendors can even get started reverse-engineering them (which they shouldn't even have to do in the first place).

Now, you could argue that that's in Apple's interest, and you could argue that "it's their browser and they can do what they want with it". But you can't dispute the fact that they're not helping web standardization in the mobile space. Which is a problem for anyone who wants a more standardized web.


WebKit has an advantage with WebKit prefixes when the prefixes in question have no spec. As DarkShikari said when criticizing the VP8 spec, code is not a spec.


Let's see if we can't tell the difference between -webkit-transform-style, a fiddly CSS property that to be useful has to be documented enough for web developers to employ it, and the interpolation filter embedded in the guts of a black box video codec.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: