W3C home > Mailing lists > Public > public-html@w3.org > January to March 2007


From: Murray Maloney <murray@muzmo.com>
Date: Tue, 27 Mar 2007 20:09:58 -0500
Message-Id: <>
To: public-html@w3.org

The Design Principle:

MostlySemanticMarkup: In general, markup that express semantics, is 
preferred to presentational markup. However, semantic markup is a means to 
an end such as MediaIndependence. Profound and detailed semantic encoding 
is not necessary if the end can be sufficiently reached otherwise, for 
example by defining reasonable default presentation for different media. It 
is preferrable to keep a balance between semantic expressiveness and 
practical usefulness. To some extent, semantics may include behavior. Names 
of elements and attributes in the markup may be pragmatic (for brevity, 
history, simplicity) rather than completely accurate.

I am an old SGML guy. I have heard about "Separation of information from 
since the mid 1980's. Back then, information was buried inside WordStar 
files and such.
Your data was held hostage by the word processor that you used.

Since then, a lot of people, SGML, HTML, XML and otherwise, have taken up 
this idea
as if it were a religious tenet. It's time to get over yourselves. 
Sometimes you just want to
say that "this text" should be emphasized, preferably as bold or italic or 
red or blue.
Sure, we could define an <emphasis> element and let people go wild with CLASS
attribute values, whose actual semantic is buried in a style sheet, but 
that seems to
be against PriorityOfConstituencies, DontReinventTheWheel, and PaveTheCowpaths.

If you really want semantic markup, use XML or SGML. Write a DTD or a schema
and document it well. Preferably, provide link ends for your namespace so that
the meaning of your elements can be discovered by following your nose.

The recent and voluminous discussion of ABBR and ACRONYM has been interesting.
Many have suggested that because they don't understand the distinction, 
there should
be none, and therefore only one should exist. The distinction is obvious to 
me, perhaps
because I was one of the people who argued in favor of the distinction 
early on.
I want to markup an abbreviation so that I can do things like build an 
index of
abbreviations, and so that I can ensure that my index terms connect an 
like "Dr." with the more expansive "Doctor."  I also want to markup 
acronyms and
initialisms for indexing and the like, but also because as an editor and 
I know that I want them to appear in small caps rather than full caps. 
That's not to say
that I want every string of capital letters to use small caps, but for 
acronyms I do.

We really do want to have <b> <i> <small> and a few other tags that can be 
to simply designate that a specific typographic effect is desired.

Yes, it's true that HTML tables are abused by designers. It's a rotten 
shame. But there it is.
I had to recode an entire web site recently because it was thrown together 
by someone
who didn't understand how to use <div class="sidebar"> and some CSS. It should
be noted that we almost didn't have <span> to complement <div> because some 
of the HTML WG thought that it was unnecessary to have both and there was 
no useful
distinction between them. As I recall, the CSS camp thought that it would 
be better to
codify the distinction on the CLASS attribute. I think that it has now 
become common
practice to use <span> in running text and <div> to markup blocks. A useful 
even if more detailed semantics are often indirected through a style sheet 
or profile.


Received on Wednesday, 28 March 2007 00:25:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 28 March 2007 00:25:34 GMT