Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS vendor prefixes considered harmful

quirksmode.org

Post reply on HN
Print view View original

21–30 of 33 posts

Re: CSS vendor prefixes considered harmful

#21

Post by jacobolus »

halo wrote: post #19
pohl wrote: post #13

Earlier quoted context omitted.

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 a…

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

Re: CSS vendor prefixes considered harmful

#23

Post by edd »

CWIZO wrote: post #2

I couldn't agree more. I can't imagine how many hours of clean-up it will take for all the webmasters to clean vendor prefixed properties out of their CSS files once browsers drop them.

You don't have to clean up. If they are no longer being obeyed they will just be ignored. You would only remove them if you are redesigning, in which case you remove them as you go. Just make sure if you are currently adding in vendor prefix stuff you add a general case for everyone else now. Future and backwards compatible.

Re: CSS vendor prefixes considered harmful

#24

Post by grayrest »

halo wrote: post #19
pohl wrote: post #13

Earlier quoted context omitted.

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 a…

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

Re: CSS vendor prefixes considered harmful

#25

Post by silvestrov »

kaitnieks wrote: post #16
pohl wrote: post #13

Earlier quoted context omitted.

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?

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.

Re: CSS vendor prefixes considered harmful

#26

Post by Kilimanjaro »

What if we had 10 browsers or more?

Nightmare!

I am against vendor prefixes, but if they are needed we should do the opposite we are doing today, let me explain:

use border-radius everywhere

browsers that don't support it just ignore it (like html5 tags)

browsers that do, just show them

browsers with special implementation of it, THEN use vendor prefixes

So we only write one border-radius and if we care about that rogue vendor, then we just add an extra -?-border-radius

Personally I wouldn't care about rogue vendors.

Believe me, I am sick of writing five times the same style, testing, changing it five times again, and some time in the future, my code will be polluting a already established standard, so I am going to have to come back to change it again.

I got sick of it, so what I do right now is to have a second stylesheet only for vendor specific styles, so all I will need to do is just remove that stylesheet when the dust settles.

Still retarded...

Re: CSS vendor prefixes considered harmful

#27

Post by pohl »

halo wrote: post #19
pohl wrote: post #13

Earlier quoted context omitted.

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 a…

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?

Re: CSS vendor prefixes considered harmful

#28

Post by tlb »

I include this kind of rewrite in my webserver, so my CSS files stay clean. For instance,

  data = data.replace(/^\s*border-radius:\s*(\w+);$/mg, 'border-radius: $1; -moz-border-radius: $1; -webkit-border-radius: $1;');
I just have to change it in the one place when some new CSS tweak comes along.

Re: CSS vendor prefixes considered harmful

#29

Post by bestes »

I love PPK's new writing style.

Most of the comments so far seem to be arguing a few specific details; I think that misses the point. PPK is arguing (in an over-the-top way, which makes it more fun to read) that convergence sooner rather than later is a good thing. For some of the more clearly defined properties (like border-radius), the time is NOW.

His characterization of the goals of browser developers seems to be right on as well. It will probably change again over time, as most competitions do, but today the top competitive advantages seem to be performance, stability and standards compliance. So, the mindset from the last generation of competition (differentiation) is no longer appropriate.

Re: CSS vendor prefixes considered harmful

#30

Post by cheald »

tlb wrote: post #28

I include this kind of rewrite in my webserver, so my CSS files stay clean. For instance, data = data.replace(/^\s*border-radius:\s*(\w+);$/mg, 'border-radius: $1; -moz-border-radius: $1; -webkit-border-radius: $1;'); I just have to change it in the one place when some new CSS tweak comes along.

I solve it with Sass, which lets me define "functions" (more like macros, really). http://pastie.org/881370 is what I use for corners - just tweaking the macro definition as needed provides what I need.

In regards to the article, other people have touched on why we can't drop vendor prefixes just yet. Not all vendors implement a feature consistently yet. In the case of something like border-radius, the shorthand forms mean completely different things in different browsers, and the longhand forms don't have consistent naming.

Vendor prefixes serve a very valid purpose - the ability to say "we've implemented an interpretation of the CSS3 draft standard, use at your own peril" is wonderful, because you don't need CSS hacks and horrible rewrites and all sorts of other voodoo to work around problems.

Post reply on HN