Hacker News Reader

Comment by bentruyman | Hacker News Reader

I guess PPK gets an auto-post on anything he writes.

No prefix leaves us in a situation where we have to assume each vendor implemented the draft spec properly. In the case that one of them doesn't, we're left either omitting it completely or writing conditional stylesheets for each browser.

An "experimental prefix", e.g. -x-border-radius, doesn't work either because we're left in the same situation as the above case. As on of the commenters on quirksmode.org pointed out, the gradient implementation in Webkit is significantly different than the one proposed by Mozilla. Using a unified prefix wouldn't help anything.

I guess one could say that we shouldn't be using draft specs in production code but that also seems counterproductive as it doesn't give us the chance to field test new functionality.

View on HN

But what about having -x-border-radius (for those who don't care about the differences) and -webkit-border-radius (for those who do) as halo suggested? I don't see the drawbacks.

I don't see the advantages. Setting up that much formal convention just to prevent having -moz-border-radius and -webkit-border-radius both in the stylesheet next to each other? What do you win beyond the savings about 20 characters?

Personally, I can think of a few advantages.

Duplicating 2 or 3 lines may seem like a minor problem, but having to change those 2 or 3 lines every time you make a change quickly becomes a maintainence burden, especially when they're littered throughout your CSS. The extra burden such prefixes brings is greater than the amount of extra characters they add.

Not having to alter your code every time a new browser comes along that is identical to existing implementation is useful, especially since most of the time browsers copy each other's features or implement standards unchanged. This is especially useful since most sites using bleeding-edge features are either tech demos or test-cases.

A non-universal prefix also favours large players and has the potential to squeeze out less popular browsers even if they support the same feature. Even if Opera supports the same standards as Firefox, you can can bet that more people will use the -moz prefix than -o.

The "risk" is that your code will break in unpredictable ways, but the upside is that risk is known (since it's part of the "contract" from the prefix), manageable, greppable, and can be worked-around.

> having to change those 2 or 3 lines every time you make a change quickly becomes a maintainence burden, especially when they're littered throughout your CSS.

You make a good argument for generating CSS via some kind of more programmable system.

> Not having to alter your code every time a new browser comes along that is identical to existing implementation is useful

And what about those times when the new browser isn’t identical? I'd hazard that that’s more usual with this kind of experimental new features.

> Duplicating 2 or 3 lines may seem like a minor problem, but having to change those 2 or 3 lines every time you make a change quickly becomes a maintainence burden, especially when they're littered throughout your CSS. The extra burden such prefixes brings is greater than the amount of extra characters they add.

http://github.com/chriseppstein/compass/tree/master/framewor...

Still, I'm not swayed. I would rather have the current mechanism, which allows me to deal with the syntactic and semantic differences on a browser by browser basis.

The current situation is an escape valve for the inevitable flux & lag between the standards process and implementation compliance.

If you invent a universal prefix you no longer have as much of an escape valve...you just have a namespace where you accept random non-compliance. And if you're ok with one such namespace, then why not one for each rendering engine, so that they're at least compartmentalized a bit?

actually you could end up having 5:

-o-superstyle

-webkit-superstyle

-moz-superstyle

-ms-superstyle

superstyle /* for new versions released after standard becomes stable */

And only if no more new browsers appear.

I would say no, because when 2-3 browsers implement the functionality and there is common agreement on the syntax, then the vendor prefix can be dropped.

My opinion is that the only problem is that the vendor prefix for border-radius was dropped too late.

I think that makes it even messier. Now we'll have 3 stages of prefixes: vendor specific, vendor agnostic, no prefix. And using something like a generic prefix also assumes all browser vendors are on the same page and agree that the spec has been baked long enough to call it final.

Reply on news.ycombinator.com