CSS normalization

Rails
1

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

2

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

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
3

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 <!–[if IE…] --!> … 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

4

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

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