Re: Structure vs Semantics

On Tue, 9 Dec 2003, Ernest Cline wrote:

> Well for one thing emphasis is only useful in MODERATION,
> not when applied to large amounts of stuff.

Emphasis is only meaningful in contrast with something else
("normal" content), but this does not restrict its useful to
inline content.

On the contrary, one of the most annoying deficiencies in
current HTML, considered as a general-purpose markup for
all kinds of documents, is lack of paragraph-level emphasis.
We cannot indicate, in HTML markup, paragraphs (or sequences of
paragraphs) as more important than normal paragraphs.
Such markup would be essential for abstracts, summaries,
conclusions, crucial warnings, and generally for paragraphs
that are meant to carry more logical weight than copy text.

<p><em>...</em></p> is not satisfactory markup for several reasons.

_How_ emphasis should be marked up is a different issue. Specifying just
<em> or <strong> or both, allowing arbitrary content (including what we
now regard as blocks) is probably not an optimal solution. We need an
analysis of what emphasis really means in different cases. There's surely
some logical difference, too, not just a difference in suitable rendering,
between e.g. emphasizing a single word (e.g. as in "I did <em>not</em>
say so") and emphasizing a paragraph because it contains the main
conclusions of a document.

> IF YOU GIVE AUTHORS THE ABILITY TO EASILY EMPHASIZE LARGE BLOCKS OF
> CONTENT, THEN THEY WILL DO SO, EVEN WHEN IT IS CLEARLY NOT APPROPRIATE.

Some authors will do so, just as one can SHOUT in plain text. Should
capital letters be abandoned for that reason?

> Another reason that the Inline/Block distinction should remain
> part of the set of (X)HTML elements is that without it how
> is a user agent supposed to tell in the absence of styling information
> that an element that could be used for either block or inline is
> supposed to be one or the other when the content of the element
> could fit either model.

Sorry, I don't understand the question. Surely paragraphs would remain
paragraphs, lists would remain lists, etc. A browser would have a bit more
interesting job to do when it encounters, say,
<p>some text <ul> some list </ul> some text</p>
but surely this can be handled. It could render the list in the normal
list style, just without top and bottom margins. Or it could present it
inline, inside the paragraph, with e.g. bullets preceding the items.
Even displaying it as current tag soup processors do would be acceptable,
though of poor quality.

> If the block-inline distinction that has been central to (X)HTML
> since at least HTML 2.0 is dropped, then change that might
> to should for what remains will be, despite being a hypertext
> markup language, so changed from the source that it will
> have no right to call itself XHTML

The distinction between block and inline is probably partly a consequence
of the original design where <p> was definitely a paragraph separator
(with no end tag allowed) and later decision to make the p element a
container but allow </p> tag omission - which more or less implied that
they needed to specify which tags implicitly close an open p element -
and "block" was born.

> or to use the application/xhtml+xml MIME type.

Well, that type itself is a result and symptom of trickery and kludgery,
so I wouldn't miss it much. If you ask me (but you won't), it should
be text/xhtml;version=2.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

Received on Wednesday, 10 December 2003 09:42:38 UTC