Break Free From CSS Prefix Hell

Break Free From CSS Prefix Hell(coding.smashingmagazine.com)

37 points by joeyj01 14 years ago | 12 comments

bretthopper 14 years ago |

What I like: it detects your browser and only sets the needed prefixes.

What I don't like: it depends on JS.

Using LESS or SASS avoids most of the problem this article talks about it, although the generated CSS will contain every vendor prefix. I'm not sure the difference in CSS filesize is worth using this solution.

Does anyone know of a server-side solution like this? Wouldn't be hard to vary the CSS output based on user-agent. Although you'd lose some caching benefits.

eam 14 years ago | |

I use Compass(http://compass-style.org) but that pretty much runs on SASS.

yogsototh 14 years ago | | |

I went here to make the same remark.

Using compass you just have to type:

  +linear-gradient(color-stops(#c7def4,#d7eef4))
  +box-shadow(rgba($ycolor9,.6) 0 0 4px inset)
  +border-radius()

And it works really fine.

samgro 14 years ago | |

SASS @extend solves most of the code bloat - if you have lots of elements styled with border-radius: 5px, using @extend, the vendor prefixed code will only appear once in the compiled CSS.

http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#ex...

jewel 14 years ago | |

I imagine that if the generated CSS is gzipped the vendor prefixes compress well, since they are quite repetitive.

jacobr 14 years ago | |

Perhaps it could be done as a SASS extension. You could use different mixins depending on the user agent.

mathias 14 years ago |

When did we stop caring about FOUC and client-side performance?

leaverou 14 years ago | |

FOUC? It's only some CSS3 that won't display until DOM load, not the whole styling. As for the performance, I'm pretty sure you're just guessing, and haven't done any testing.

mathias 14 years ago | | |

> As for the performance, I'm pretty sure you're just guessing, and haven't done any testing.

Have you?

Are you saying it’s not necessarily slower to use JS to generate CSS on the client-side, compared to just serving up the CSS with all prefixes included in the first place? Do we really need a test case for that? I’m not even talking about your code or anything; just the general idea.

In general, it’s a bad idea to rely on client-side JavaScript for something that can be done without. PrefixFree is no exception.

I can see how PrefixFree can be useful for quick demos or during presentations (the way you use it is awesome!) but when you’re gonna post an article like this on a site like Smashing Magazine _people are gonna use it_ in production as well.

I love your work Lea, you know I do; I just don’t agree with the philosophy behind this particular project.

ck2 14 years ago | |

Exactly - this makes about as much sense as the javascript based "busy" indicator (instead of gif).

Stylesheets are cached and a one-time hit for new visitors - this method has to reiterate on every single page load.

evlapix 14 years ago | |

I understand your concerns, but in this case I think extent of usage and progressive enhancement are the real considerations.

simonhamp 14 years ago |

Fundamentally the wrong wy to deal with this. If it had appeared a few years ago (i.e. before LESS and SASS) it might have been viable for about 5 minutes...

Use LESS and precompile your CSS... it will change your life.