W3C home > Mailing lists > Public > www-html@w3.org > December 2003

Re: XHTML 2.0: Suggestion for <addr/> and <blockaddr/> to replace <address/>

From: Jukka K. Korpela <jkorpela@cs.tut.fi>
Date: Sun, 7 Dec 2003 20:02:26 +0200 (EET)
To: www-html@w3.org
Message-ID: <Pine.GSO.4.58.0312071944531.12108@korppi.cs.tut.fi>

On Sun, 7 Dec 2003, Ernest Cline wrote:

> > Does that really define the meaning of the term "Snail Mail"? Maybe, in
> > some way, in a universe where a single Snail Mail address exists.
>
> It defines the single "snail mail" address for me

I don't think so. It just _tells_ your address. It surely does not define
the _term_ (dt = definition term) "Snail Mail". Au contraire, it
postulates that the reader already knows a definition for "Snail Mail",
i.e. knows what that jargon expression means.

> and the intent
> of the <dl> in my example was to define the ways in which I could
> be contacted.

If you prefer saying "define" instead of "describe", that's fine by me,
but it surely does not mean that you are defining the term "Snail Mail".

> In any case, the use of <dl> despite its name
> of "definition list" has been associated in HTML with any list
> containing binary relationships between a term and text
> associated with that term, not just definitions.

I though the purpose is to make things clearer, not to make existing
confusions, contradictions, and bad practices something official.
If you wish to specify that <dl> is something amorphous like that,
effectively just because it is supposed to create a particular visual
layout (honestly, isn't this what all that <dl> abuse is about?), then you
should at least decide that the legacy element <dl> be split into two
distinct elements:
- a definition list (that is, a list of definitions of terms - which is
  what <dl> has always been)
- a description or comment list (which is effectively a two-column
  table, structurally, and therefore an odd bird really).

> > Regarding the href, that's an interesting idea, but that's really external
> > to HTML, and I have yet to figure out what the possible uses could be.
> > After all, clients should not assume anything about it - any relationship
> > to the semantics of the HTML document, such as specifying someone's Snail
> > Mail address. And the content is just a sequence of lines.
>
> If one can't assume in this case, then the whole idea of a semantic web
> had best be dropped.

That's a very good idea, but let's not go into that now. If "semantic web"
means making guesses across protocol levels (URI syntax and (X)HTML), I
don't think that it would be a good counterargument to anything that it
defeats "semantic web".

> There is absolutely nothing that will prevent
> authors from, for example, continuing to use <blockquote>
> when what they have isn't a quote but they want the indenting effect
> commonly given to it.

That's correct, and for <blockquote>, the saying "abusus not tollit usum"
does not apply. It has been abused so widely that it makes little sense to
expect that it could have much useful use. Since so many people read
"blockquote" as "indent", it would be best to omit the element name, which
is after all somewhat odd. The element name "quote" hasn't been spoiled
yet, and it could well be used for all quotations, inline or block, with
or without quotation marks.

> "Are well-written, as they should?"  Sorry, but to expect that people
> will do as they should is the biggest mistake we could possibly make.

No assumptions are needed. It's a fact of life that well-written link
texts work and poorly written don't (or work badly). The definition of
link elements as having inline content only has _largely_ encouraged
authors into using short link texts, and that's really an achievement.
Many of those texts are "here" or "click here", but that's a different
dimension. At least they are not writing a hundred lines of text and
making it a link. If any element can be a link, authors _will_ make their
paragraphs, lists, and tables links, without thinking why

> All those blue underlines just won't
> look good to most people.

Authors already know how to get rid of them. It's proably #1
(ab)use of CSS, the thing that many authors "learn" first about CSS.
Besides, if anything can be a link, browsers will be more or less forced
to drop the tradition of underlining and link colors - causing much
confusion of course.

-- 
Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/
Received on Sunday, 7 December 2003 13:02:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:59 GMT