Forum .LRN Q&A: Re: .LRN Gardens

I think a good set of classes and id's in a master CSS is a good start, but I don't think it covers all the cases. There are far too many different layouts that you might want to do on any given page that can't be covered by a single big CSS file unless you start creating module- and page-specific classes in that large file.

I suggest trying to use the "Cascading" part of "Cascading Style Sheets" and have a master.css, modulename.css and pagename.css. I'll also comment on an override.css below.

master.css would hold font declarations, site-wide colour declarations, some classes for "normal" forms/tables/lists, etc. Elements that are likely to be used in a consistent way by every page and every module.

modulename.css would handle classes/ids specific to that module. For instance, calendar has some specific needs that aren't reflected elsewhere in the site. It doesn't take too much imagination to consider uses for module-specific CSS declarations — colour coding for bug statuses in the bug tracker; graphics and colours for new messages/postings in the forums; etc.

pagename.css would handle page-specific layout. div id 'b' floats to the right of id 'a' and 'c' appears underneath with a border around it. These things could be specified in a module CSS but they really don't belong in a site-wide CSS, especially when you consider the myriad possible namespace collisions.

Finally, override.css is where the real power of the "cascading" of CSS can be experienced. I haven't thought much about how this might be implemented, but the basic idea is that a course teacher could use this file to set CSS display attributes for her particular course. She can declare all the classes she wants the way she wants because the highest specificity CSS declaration wins. Control is restored to the site administrators who don't want her fooling around with the institution's logo by declaring the logo !important.

Similarly, an individual user could use override.css because he doesn't like that the owner of the bug tracker gave the "overdue assigned-to-me bugs" the "blink" attribute. Fixing that is just an override away.

It's still too early to suggest exactly how the classes and ids get laid out. My suggestion for finding the right approach would be this:

Using the "Eric Meyer on CSS" book as a guide on "good" XHTML/CSS coding a few module owners should start converting their modules to true XHTML/CSS. That means no <br> tags (this is a hard restriction to live with!), avoiding tables for layout, using id's over classes where possible, etc. When they're done and they have a bunch of CSS files, they start comparing notes on what they discovered. Each of them will have put together a "master.css" of declarations that they think belongs in the master. Whatever set of id's/classes they agree on should become the definitive master. Where possible they should align class and ID names. Through this process they'll end up with the start of a "Best Practices OpenACS/CSS" document. They'll all have to adjust their code and CSS declarations to match the Best Practices, but that will be a quick job because all of their pages will be valid XHTML and will require no further markup except adding additional IDs and classes.

In terms of specifics, it might be a good idea for a few people to work on converting a module to XHTML/CSS. Bruce and I briefly discussed doing this on some module when we're in Copenhagen at the end of the month. This work would get submitted back to the community for peer review to solicit comments. Perhaps some other module owners could try their hand at it as well. The next step could happen in Heidelberg where a couple other modules are attempted and a "Best Practices" document is written. Perhaps we could finish a first version of master.css as well.

What do you think of this approach?