« Blogging about my father | Main | Social week »

CSS portability and common CSS


I've been thinking lately about the following problem:

Content in today's web appears in many contexts, and a lot of presentation information gets lost in that transition.

For example, my blog entries appear in my own blog, where I have a lot of control over how they look (though individuals may change the appearance in their own browsers), but they also appear in feed readers as RSS and Atom feeds, in LJ as syndicated entries, in Facebook as Notes, potentially in a screen reader as spoken words, and maybe other places too. And in most of those contexts, I have very little control over presentation.

As I noted in the abovelinked old entry, in some ways that's fine. I need to write with the understanding that different readers will see (and hear) what I'm writing in different contexts.

But there are some aspects of presentation that I want to be portable.

For example, the default presentation of HTML "definition lists" is (imo) hard to read. The terms and definitions have the same font weights, and there are no spaces between lines. Here's an example definition list (which will look different for those of you reading this on my site than for those of you reading it elsewhere):

term 1
This is the definition of term 1.
term 2
This is the definition of term 2.

Whenever I have control over the presentation, I add CSS to improve the look of that, making the terms boldface and adding some space between lines. Here's my current CSS for that, which could probably use a little polishing:

dt {
  margin-top: 1.2em;
  margin-bottom: 0.8em;
  font-weight: bold;

dd {
  margin-bottom: 0.8em;
  margin-left: 2em;

(Feel free to use that CSS if you like it. Especially if you are a browser maker and you want to spruce up the default look of definition lists in your browser, hint hint.)

So definition lists in entries on my own site look reasonably good, but the same entry on another site won't look as good.

The problem is even worse in the rare cases where CSS carries semantic meaning.

For example, in some contexts there's a semantic difference between a numbered list (such as a procedure of ordered steps to follow) and a lettered list (such as a set of options to choose among).

If you want to make an HTML numbered list use letters, you're no longer supposed to use HTML's deprecated <ol type="A">; instead, you're supposed to use CSS's list-style-type: upper-alpha.

But that's CSS, stored in a separate file from the content, so it doesn't stay with the content in other contexts. I can say <ol class="alpha">, but that doesn't mean anything in places that don't use my CSS. So if I refer to "option B" after a lettered list, it'll make sense to readers on my site, but not to readers elsewhere.

(Added later: Inline styles, using the style attribute, can help with portability, but they negate a lot of the advantages of using a CSS file: you can't reuse inline styles by name, and you can't change them sitewide by changing one CSS file.)

I've been vaguely thinking that it would be nice if CSS defined some meta-classes or class types or semantic kinds of classes. I'm not going to go into detail here about what I mean by that, though, because it would require changing CSS, which isn't likely to happen at my suggestion. Also because I get bogged down in trying to figure out how exactly it would work.

But a couple days ago, I realized that there's a much simpler (partial) solution, and one that I can implement on my own:

Create a standard minimal library of very common CSS classes. Give them good names (perhaps using a namespace prefix, perhaps not; haven't figured that out yet). This would not be a big comprehensive library, just a few small things that would allow people to standardize on the same set of CSS names for the same look for a few items.

Perhaps there could even be a couple of files: one for common improvements to looks (like the dl thing above), one for semantics (<ol class="alpha"> and the like), possibly even one for layout (though that gets into much bigger and fairly different issues).

(Added later: There have been attempts to create CSS layout libraries; see, for example, Yahoo's YUI Grids CSS. And the CSS for Google Code is now Apache-licensed, though there's no documentation on how to use it. But although layout is important, at the moment I'm less interested in the layout part of this issue than in the appearance and semantics pieces.)

And standardizing on this set of class and ID names would mean that anyone who wanted to could provide an alternate CSS file for their own site that would address the same styles in a different way.

I haven't gotten very far on implementing this; been busy. And I need to resolve some issues such as where to host it (if it were to become popular, it would eat up my personal account's bandwidth quota; maybe I'll try starting an open-source project at Google Code project hosting) and whether to use namespace prefixes and how many files there should be and so on. All in early stages here.

But I'm pretty excited about the idea, so wanted to post about it while it's still fresh in my head.

I'm also curious whether anyone else has done this before. It seems like one of those obvious-in-retrospect things, but a cursory web search hasn't turned anything up, and I haven't heard of anyone doing it.

Ideas, discussion, and pointers to existing implementations would be most welcome.


When I try to log in to comment with my LiveJournal ID (either LJ or OpenID), I get this error:

Movable Type

An error occurred
unclosed token

Anyway, what I came over here to suggest was that you use <ol type="A" class="alpha"> which, though deprecated, covers all the bases. Is there a good reason not to do this?

Thanks for letting me know about the LJ login issue; I'll try and look into that soon. It used to work, but I haven't tried it in a while. And I'm sorry about the angle-brackets preview issue; I'm guessing that there's a bug in MT's preview system that replaced the encoded angle brackets with real ones. (Ironically, I suspect that if you hadn't previewed, it would've worked.) I'll try and fix that, too. (And I've fixed the angle brackets in your comment, and removed your followup comment to avoid reader confusion.)

Your proposed code would work for now, but it relies on browsers supporting the type attribute, which (as you noted) has been deprecated since 1999. And if you're willing to use deprecated HTML (as I sometimes have been, for exactly this kind of thing), then there's no need to bother with the class="alpha" part; it becomes redundant. (In the case where a future browser doesn't support the type attribute, then you've got the same problem I was describing in this entry: people viewing the entry in a different context will lose the formatting.)

Another way to put that: if you're okay with using type="A", then you don't need CSS; in that case, this stops being a CSS issue, and is no longer part of the scope of what this entry is about.

Post a comment