# CSS normalization **URL:** \ **Category:** Rails\ **Created:** [June 4, 2008, 6:17pm UTC](https://www.ruby-forum.com/t/css-normalization/139524 "2008-06-04T18:17:08Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Phlip](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/ed8c4c/32.png) [@Phlip](https://www.ruby-forum.com/u/Phlip)\ **Post date:** [June 4, 2008, 6:17pm UTC](https://www.ruby-forum.com/t/css-normalization/139524/1 "2008-06-04T18:17:08Z")
Railsters: Our ambitious artists, and their tools, tend to deliver CSS in this format: - screen.css - everything in here - ie6.css - copy of everything, with a few tiny tweaks - ie7.css - copy of everything, with a few tiny tweaks - safari.css - copy of everything with a few tiny tweaks That’s not very DRY. The last-minute tweaks to make all those browsers look the same are slowing us down. Ultimately, this is a text cleanup problem. Something should delete every element of the submissive CSSs that don’t change the same element in the dominant CSS. Has anyone used the css\_parser gem to do this? – Phlip ---
**Author:** ![Phlip](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/ed8c4c/32.png) [@Phlip](https://www.ruby-forum.com/u/Phlip)\ **Post date:** [June 4, 2008, 11:30pm UTC](https://www.ruby-forum.com/t/css-normalization/139524/2 "2008-06-04T23:30:52Z")
Phlip wrote: > - screen.css - everything in here > - ie6.css - copy of everything, with a few tiny tweaks > - ie7.css - copy of everything, with a few tiny tweaks > - safari.css - copy of everything with a few tiny tweaks > > That’s not very DRY. The last-minute tweaks to make all those browsers look the > same are slowing us down. Have they ever used the @import CSS directive? [http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#x5](http://www.w3.org/TR/1998/REC-CSS2-19980512/cascade.html#x5) It’s essentially an Include command that will suck in any CSS file accessible by URL, local or remote. That at least allows you to maintain a base.css and special\_x.css, special\_y.css, etc. - Aaron ---
**Author:** ![Phlip](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/ed8c4c/32.png) [@Phlip](https://www.ruby-forum.com/u/Phlip)\ **Post date:** [June 5, 2008, 2:31am UTC](https://www.ruby-forum.com/t/css-normalization/139524/3 "2008-06-05T02:31:21Z")
> Have they ever used the @import CSS directive? Apologies for letting y’all answer the wrong question: The CSS already has the problem - we can’t go back in time and unwrite 1600 lines of CSS per file. (We also need to clean up the situation were identical panels with identical properties have irrelevantly different selectors!) We already import both the dominant.css and the browser-specific CSS into the same page - using the \ … notation. The artists were at fault for cloning entire dominant.css files just to then tweak them, when they didn’t need to. I will see about posting the code we used in our solution. Phase one: run dominant.css and ie6.css thru csstidy –sort\_selectors=true –sort\_properties=true --merge\_selectors=0. Phase two: Write a simple Ruby script, with CssParser, that parses both CSSs, then emits one line, such as .title { color: green; }, for each property value in ie6.css that disagrees with or does not appear in dominant.css. Phase three: use csstidy --sort\_selectors=true --sort\_properties=true –merge\_selectors=2 to turn the ugly redundant output into a new ie6.css ---
**Author:** ![Phlip](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/ed8c4c/32.png) [@Phlip](https://www.ruby-forum.com/u/Phlip)\ **Post date:** [June 4, 2008, 10:59pm UTC](https://www.ruby-forum.com/t/css-normalization/139524/4 "2008-06-04T22:59:01Z")
Phlip wrote: > Railsters: > > Our ambitious artists, and their tools, tend to deliver CSS in this > format: > > - screen.css - everything in here > - ie6.css - copy of everything, with a few tiny tweaks > - ie7.css - copy of everything, with a few tiny tweaks > - safari.css - copy of everything with a few tiny tweaks > > That’s not very DRY. The last-minute tweaks to make all those browsers > look the > same are slowing us down. > > Ultimately, this is a text cleanup problem. Something should delete > every > element of the submissive CSSs that don’t change the same element in the > dominant CSS. > > Has anyone used the css\_parser gem to do this? > > – > Phlip Hi Phlip, This doesn’t answer your question about css\_parser, but I thought I’d take a moment to share how I handle CSS. I have start with Eric Meyer’s reset.css to get everything to a known state. It can be found here [Reset Reloaded – Eric’s Archived Thoughts](http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/) Then I have a base.css (or screen.css or whatever you want to call it…I used to call it common.css) that I use when developing the application. When I get to the point of tweaking the layout for different browsers, I use a combination of files for each browser. In each file I put only the overrides or additional tweaks that are necessary. None of this copying everything stuff. So for IE, I’d have ie\_base.css ie\_6.css ie\_7.css ie\_8.css and for safari, I’d have safari\_base.css safari\_win.css safari\_mac.css and likewise for firefox: firefox\_base.css firefox\_win.css firefox\_mac.css [With Safari and Firefox, I have not yet ventured into supporting multiple versions. It’s always whatever I happen to be using at the time, which tends to be the latest official release (3.1.1 and 2.0.0.14).] Then I do the unthinkable and interrogate the user agent ( gasp! ) to figure out what browser is being used. [I, personally, don’t care about impersonation. If the user is purposefully changing his/her user agent string, s/he gets whatever happens.] For every user I load base.css, then I load the appropriate “fix css files”. Now, some will say that there are just too many files to manage, but I like the fine-grained control it gives me [I’m a recovering perfectionist :)]. Take, for instance, the fact that I use safari\_base and safari\_win/safari\_mac. One would like to believe that there aren’t any differences in the rendering engine between platforms, but there are. In both Safari and Firefox, I’ve encountered situations where a setting that worked correctly on one platform didn’t work correctly on the other. Besides, it’s very organized to have the appropriate CSS rules for a particular browser in a separate file. If they ever need to be tweaked, you know right where to go and you don’t have to worry about fudging up something else in the process. And when it comes time to drop support for that particular browser (or version), you’ve got one file to get rid of. I’m sure my approach could be tweaked, but it works for me. And the point is that I get work done and it looks right. Peace, Phillip