[drupal-devel] CSS bloat
mcsparkerton at yahoo.co.uk
Sun Mar 13 08:53:00 UTC 2005
While I appreciate some of the comments posted here, I don't think that
they are all entirely correct... and may even be a bit misleading.
Chris Messina wrote:
> For one thing, it is hard to know where certain styles or classes are
> going to show up. For example, that labels are used non-semantically
> on the profile page and that labels also wrap radio buttons means that
> I can't simply style labels generically but instead must add selectors
> to accommodate each case. That doubles the amount of code.
Actually, you know exactly what classes are going to show up because
its up to the theme developer to put that code spit out by drupal into
containers/block-level elements of their choice. A theme developer has
complete control over the names of classes and IDs for the purpose of
designing their own style sheet - because they have control over the
containers in which the code spit out by Drupal will sit.
> Second, Drupal needs to have a more uniform and semantically classed
> codebase. The classic example of this is how the old event and archive
> calendars were classed without regard to the other. If you look at
> Democratica's modules.css file, you'll see the monkey-love I had to
> make to get those calendars to look the same.
For the most part, I find the default element class names to be just
fine. Could they be better - I suppose - but I have yet to encounter a
class or ID name collision.
> Third, Drupal's XHTML might validate, but that doesn't mean that it's
> useful for styling or UI overlays. One of my jobs will be to offer
> improvements on the XHTML that Drupal spits out with documentation on
> how to leverage the code for easier and simpler styles.
I'd rather Drupal modules did as little thinking for me as far as naming
of classes and IDs goes. In a perfect world Drupal would produce plain
vanilla XHTML with as few named elements as possible. And I think it
has done a pretty good job of this thus far. I really don't have any
> Lastly, the themeable functions are a tremendously underused tool for
> themers, both on the theme side and in many modules. There is a lot of
> potential for reducing CSS bloat if themers could make more changes to
> the XHTML to better serve their purposes.
YES - absolutely 100% correct. The themer can reduce CSS bloat by not
having bloated XHTML in their template files (and thus having fewer
elements that require a selector in the CSS). They can further reduce
bloat by planning ahead and using classes and IDs in an efficient way -
(so they can get the most out of CSS inheritance and precedence and once
again reduce the number of selectors in their style sheet).
I'm not picking on you here - I think the site looks good and the CSS is
obviously functional. But, looking at the CSS file on civicspace right
now - virtually all the bloat reduction would come from reducing the
number and length of the CSS selectors that are in there now. I can
appreciate where the bloat might have come from (i.e. making sure that
you have all bases covered), but I *guarantee* that it can be reduced.
(I'd be willing to put my money where my mouth is. If you could tell me
what it would be worth to you to reduce the CSS file size by 20K I'd do
it for that amount. If I'd fail to reduce it by 20K you pay nothing
(but you'd still likely have a significantly reduced file size). If I
succeed its pay day ;-)
> Again, I do agree that the issue of CSS bloat needs to be addressed,
> but I also think that we need to realize that CSS is like the new
> image slicing technique for the web -- more CSS will eventually mean
> fewer images and eventually, less html too, reducing the *overall*
> weight of a site.
I just recently did another conversion of a traditional tables and
images based layout for a client and reduced the XHMTL (file size) by
20%. This is very typical. It takes a whole lot less code to design a
CSS layout. If all the other benefits of CSS weren't enough, this
should get site admins turned onto pure CSS design.
But, it should be noted that you may still end up with a lot of images
in your design. I'm sure if you asked Steven he could tell you exactly
how many images there are in BlueBeach. You might be surprised how
quickly the file count goes up when you have rounded corners on all your
different block level elements.
More information about the drupal-devel