Jukka K. Korpela wrote:
OK, I'll bite. I've never heard you condemn a class name before, and to
start with "center" has me a bit amazed. Can you elaborate on why
"center" has no meaning? On the surface it would seem to be self
explanatory.
It's an interesting question, deserving a good answer.
Firstly, I'm surprised you haven't heard Jukka rag on this one before.
It's a regular tripwire around here.
Thirdly, it's obviously "self explanatory". That's not the problems.
Mostly though it's about the second part of your question, 'Can you
elaborate on why "center" has no meaning?' Of course it has
"meaning", the problem is _what_ domain that meaning is applied to.
Jukka favours classnames that reflect "markup", i.e. their meaning
should be objective and based around the content of the document, not
how it's to be presented. So a classname of "legal-postscript" is OK,
but "centred" is bad. Even "legal-footer" is dubious (who's to say
that it should always be presented as a "footer"?)
Some people, myself included but not AIUI Jukka, believe that semantic
HTML can be extended by the rigorous use of classnames which have
implied binding to schema or ontology documents, as a way of extending
the public semantics of HTML. This is already easy to do (and widely
done), but not in a way that's publishable outside narrow projects
(the public web can't automatically infer the meaning of the
classnames).
An alternative approach, as described here, is to use classnames that
reflect "presentation" aspects, not content markup at all. Classnames
like "center", "red", "bold10px" are obvious indications of this.
However you should remember that the names of "presentational"
classnames are no more inferrable than "structural" classnames.
"bold10px" is no more likely to still translate to the "obvious" CSS
in an old project than "left-menu" is likely to still be on the left
rather than re-designed to the right. This lack of stability over time
and maintenance is perhaps the biggest problem with overtly
presentational classnames.
It's an article of faith hereabouts that structural class names are
good and presentational class names are always bad, hence Jukka's
reaction.
I take a rather softer line. Structural classes are good, but
presentational class names _may_ also be a good thing, under certain
constraints.
The key to this is to remember that elements can have a list of
classes applied to them, they aren't made members of a single
exclusive class at a time. This changes the relationship between
element and class. Rather than being an ordinal defining relation
(this element _is_ a "legal-postscript") it's a multi-valued
attributional relation (this element has the "legal-postscript"
behaviour and also the "center" behaviour). In this interpretation,
it's no problem to make sense of the set of classes attached to
elements. Where these presentational themse are complex (e.g. the
"corporate branding guide theme green" behaviour is to be applied),
then this can be a useful technique.
The downside is of course that we've merged content and presentaion
into a single file, by applying purely presentational behaviours (the
application of presentational class names) to the HTML directly. This
is against one of the claimed principles of HTML 4 + CSS, the supposed
separation of content and presentation.
However even this principle isn't simple:
CSS doesn't work this way entirely. HTML _does_ still convey some
presentational information, because CSS' design was simplified to
depend on it continuing to do so. If CSS was as sophisticated as
DSSSL (and as hard to use), then we wouldn't need as many <div>,
<span>, <hr> or <br> as CSS sometimes requires HTML to contain, to
permit a particular presentation.
This principle isn't that useful in practice. It's great for "Zen
Garden" or for some idealised CMS contexts, where "designers" make CSS
and content authors make pure-content HTML. For many of tus though,
the HTML + CSS process to achieve an exact design requirement is an
iterative process involving related work on both parts at once. if
this is already the case, a new need to express some presentational
aspects in the HTML file isn't losing much, but it may simplify the
required CSS considerably.