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

> [Original Message]
> From: Jukka K. Korpela <jkorpela@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.

Then you are too late to save <dl> as using <dl> for things other
than "definition lists" has been sanctioned since HTML4 when it
explicitly mentioned marking up dialog as one use of <dl>  in the
recommendation.

<snip>

> > "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 probably #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.

Why do you think that the extension of href to most elements will
cause the problems you fear?  It isn't difficult now to create documents
that have massive links. I certainly haven't encountered many pages
that try to do either:
<p><a href=...><!-- lots of text --></a></p>
or:
<table onclick=...>...</div>.

The mechanisms already exist to do what you fear in HTML.
They aren't difficult to write, and what you fear is not happening now.
I'll grant  that eliminating the need to use a scripting language
to get "links" on block elements will make it slightly easier to make
the massive links you fear but the ease of use they create
by allowing constructs such as <li><a href=..>...</a></li>
to be replaced by <li href=...>...</li> seems worth it to me.
This ease of use is not just for the author, it also extends to the
user agent by eliminating a level from the document tree.

Received on Sunday, 7 December 2003 21:03:20 UTC