Break Free From CSS Prefix Hell(coding.smashingmagazine.com)
coding.smashingmagazine.com
Break Free From CSS Prefix Hell
http://coding.smashingmagazine.com/2011/10/12/prefixfree-break-free-from-css-prefix-hell/
3 comments
I use Compass(http://compass-style.org) but that pretty much runs on SASS.
I went here to make the same remark.
Using compass you just have to type:
Using compass you just have to type:
+linear-gradient(color-stops(#c7def4,#d7eef4))
+box-shadow(rgba($ycolor9,.6) 0 0 4px inset)
+border-radius()
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...
http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#ex...
I imagine that if the generated CSS is gzipped the vendor prefixes compress well, since they are quite repetitive.
Perhaps it could be done as a SASS extension. You could use different mixins depending on the user agent.
When did we stop caring about FOUC and client-side performance?
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.
> 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.
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.
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.
Stylesheets are cached and a one-time hit for new visitors - this method has to reiterate on every single page load.
I understand your concerns, but in this case I think extent of usage and progressive enhancement are the real considerations.
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.
Use LESS and precompile your CSS... it will change your life.
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.