What I took from this article was that an appropriate choice of style can reflect and enhance the content. However, that introduces a (one-way) dependency:

while content does not depend upon design, design does depend upon content.

I see this argument as having some impact here. The data in the table is (sic) independent of the stylesheet. However, the choice of presentation depends on the nature of the data in the table. I’m trying to work out how to include the right meta-data in the table that avoids making the dependency go the other way…. I think.

Thanks for the correction re: whitespace.

Thanks also for the recommendation regarding granularity.

You’ve given three good examples of data-types I might need. I’ve been trying to think ahead of all the others I might need in the future. It occurs to me that I don’t have special needs here. My types are likely to be the same as the next person. Has anyone produced a good master list to copy? I haven’t found any.

Anyway; back to the subject at hand. The thing to realise is:

Class names convey no semantics.

The goal of choosing class names is to group together styling options in such a way that when you want to make a change to the presentation of your documents, you will not need to edit the markup, only the stylesheet. You should not have to edit markup to change which classes are applied to which elements in order to be able to achieve whatever it is you are trying to do.

Avoiding presentational class names is therefore not an end in itself. It is only a good rule of thumb, so that you won’t do things like style="bold red size-5", which would require you to change the markup in order to change the presentation.

For tables, then, the granularity of names should be roughly between the examples you gave: numeric (right-aligned), symbol (centered), multiparagraph (justified, smaller, some padding), etc. Think “data types.”