Thursday, April 15, 2010

On Semantic Meaning, and Other Muddled Concepts

So, Smashing Magazine has a very articulate writeup on how developers can paint themselves into a corner with DIV based designs, nearly as well as when they were abusing TABLE tags to do layout.

The anti-pattern of using semantic markup for layout keeps reappearing due to a lack of an analytical mindset among designers, whose main strengths are in visual synthesis and communication.

Not to nitpick, but in describing the situation, the Smashing author says:

When developers do not understand the semantic meaning of other block-level elements, they often add more div tags than are needed.
While I agree with the sentiment, such a quote does make one wonder if the author understands the meaning of "semantic". It reads as a bit redundant.

I've made the same mistake myself. It isn't the semantic meaning of block-level elements we need to worry about, it is the semantics -- the meaning -- which we infer by means of the markup, with which we should be concerned.

In other words, we worry too much about precision in terms of tag names, and not enough about whether we the constraints we've put on the vocabulary will allow us to express the distinctions we need to make with necessary and sufficient accuracy. (OK, that is probably a less clear explanation than the previous sentence, but I'm leaving it. The reader will have to work for it here.)

HTML does too many functions with too few tags. The layout features in particular should be marginalized into the realm of backwards-compatibility features. Distinctions like "block-level" and "in-line" are the semantics of a formatting process, not of content.

No comments: