Problem with descriptive lists in CSS

[Joseph Haig]

I am trying to use descriptive lists, <DL>, as shown in
<http://www.maths.man.a c.uk/~jhaig/tmp/test.html> with a style sheet
at <http://www.maths.man.a c.uk/~jhaig/tmp/default-2.css>. With
Mozilla and Opera they appear correctly, with a border round both the
<DT> and <DD> parts but in Internet Explorer the borders are messed
up. Can anyone please tell me where the mistake is?

As an aside, the <div id="main"> section should have the right border
20px from the right hand side of the window. How can I get this to
display properly?

Thanks.

[Jukka K. Korpela]

di*****@codesmi ths.com (Andy Dingley) wrote:

What's vague about topology ?
I thought I roughly knew what topology is when I wrote my Master's Thesis
on a topological subject. After that, I have wondered how many different
(and often mutually incompatible) meanings people can assign to that
word. The most common meanings seem to refer to placement of physical
objects, which is fairly natural (after all, "topos" means 'place,
position').
The DTD gives it:

<!ELEMENT DL - - (DT|DD)+ -- definition list -->
That's the syntax. What about the meaning? The comment is not normative,
but it corresponds to the normative prose in the specification.

And it looks rather redundant, since it is just a special case of a
table - an m by n table where n = 2.

This is not the case. <dl> is a list of two child element types,
which can occur in any order.

But if you consider the general possibilities, how do you define which
<dt> corresponds to which <dd>? It's _not_ in the specification.

Besides, the general case can also be presented as a table, using
colspan and rowspan attributes.
The difference between <dl> and <blockquote> is that <dl> changes the
permitted content model of a document inside the element,
<blockquote> does not.
Huh? That's still just syntax, not semantics, and not even true - the
<blockquote> element has a content model of its own.

<dl> is defined as a definion list, consisting of definition terms
and definition data.

This isn't an especially restrictive definition.

Maybe, but it's _the_ definition.
A few lines further
in the same section we read, "Another application of DL, for
example, is for marking up dialogues".
We've gone through this, haven't we? The specification is self-
contradictory here. It suggests use that is contrary to its normative
prose. It's a bit similar to some statements there that imply that
<blockquote> _has_ been used for mere indentation (but shouldn't be -
though it just "deprecates " such usage instead of forbidding it).

If you have used <blockquote> according to the specification, you
would find no fundamental objection against a browser saying (or
displaying) "Quotation: " and "End of quotation."

My objection is that such a browser is reading too much into the HTML
spec.

Paying attention to semantics, you mean? Is it also incorrect that a
speech browser says "start of form one" when it encounters the start of a
<form> element? After all, if we should not read "too much" into the HTML
spec, i.e. not take semantics seriously, a browser should not assume that
<form> actually means 'form'.
ur-HTML was intended to discuss particle physices, but "the
Web" didn't arise until it was realised that generalism was a _good_
thing, even if it brought vaguness with it.

Oh really? In fact, HTML has been, and still is, extremely clumsy and
primitive for any presentation of physics matters even at high school
level, not to mention the equations of particle physics. It was
specifically designed as _general_, with concepts like 'list',
'paragraph', 'emphasis' and 'block quotation', rather than application-
oriented concepts. (It has a few constructs specifically for referring to
computer stuff, but really nothing for physics.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Brian]

Andy Dingley wrote:

<blockquote> is a semantic label to a section of a document, and
it's a peg on which to hang presentation styling.
*Any* element is a peg on which to hang presentation styling, so that
doesn't add much to the discussion.
It's a member of the block entity, and its own content model is
also %block; (OK, I'd forgotten about script). The context for the
insides of <blockquote> are unchanged from the context outside.
It's this behaviour that permits <blockquote> to be nested,
semantically bogus as that may be.

Why is that semantically bogus? Nested <blockquote> elements seem
quite useful on message forums. See Mozillazine forums for its use.

Even if it was semantically bogus, your argument doesn't bare the
weight, since you're trying to judge semantics by the validity of the
markup. And that's what's really bogus.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Andy Dingley]

"Jukka K. Korpela" <jk******@cs.tu t.fi> wrote in message news:<Xn******* *************** *******@193.229 .0.31>...

The most common meanings [of topology] seem to refer to placement of physical
objects,
Then those are obviously wrong (if I understand your phrasing
correctly). Topology is about position/placement, as ordering and
connectivity, but definitely not about position/placement as physical
location.

And that's why <dl> is topologically different to <ul> or <table>.
<ul> only has a single type of child, <table> has implicit ordering in
its columns. <dl> is somewhere inbetween.

Yes, <dl> doesn't bind a particular <dt> to a <dd> (although it's
widely assumed they're in pairs). I don't know why this is; it would
have easily been expressed in the DTD, it's consistent with the notion
of "descriptio n list" and it's consistent with the widespread
(mis-)understanding of the element.

The DTD gives it:

<!ELEMENT DL - - (DT|DD)+ -- definition list -->

That's the syntax. What about the meaning? The comment is not normative,
but it corresponds to the normative prose in the specification.

I copied that comment because I didn't want to edit the DTD fragment I
re-posted. I imply nothing by doing so - my only purpose was to show
the twofold nature of <dl> children and their lack of pairing.

But if you consider the general possibilities, how do you define which
<dt> corresponds to which <dd>? It's _not_ in the specification.
You can't by HTML alone - you'd have to head off into ID & IDREF
territory.

The difference between <dl> and <blockquote> is that <dl> changes the
permitted content model of a document inside the element,
<blockquote> does not.

Huh? That's still just syntax, not semantics,

So what's the difference ? This whole thread is about taking a
syntactic definition of HTML and arguing over how far it is valid to
extrapolate this into an assumed semantics. A very reasonable response
to that is to throw the towel in and say simply that "HTML has no
semantics". I wouldn't go that far myself, but I'm not too far from
it. Certainly I'm always wary of reading too much into HTML's implied
semantics, because I think they're only of the most rudimentary and
trivial form. They're enough to suggest a "sensible" default
stylesheet, they're not enough for a browser that prefixed every <dt>
with "Term: " to be sensible.

and not even true - the
<blockquote> element has a content model of its own.
It's close enough for jazz (as I said, I'd forgotten about the
inclusion of <script>). My point is that nesting <dl> would be a gross
non-validity, nesting <blockquote> is just semantically dubious.

As others have pointed out, nesting <blockquote>s _is_ valid and
meaningful, however (outside bulletin boards) this generally isn't the
meaning that the nested <blockquote>s that we encounter so often were
intended to have. Nesting them is valid if it means repeated quoting,
not valid if it only means quoted once with extra typographic
indenting.

The specification is self-contradictory here.
_Can_ a spec be self-contradictory ? Now a draft spec certainly can,
and good authors will remove such contradictions. But when the spec is
released, do these contradictions remain as errors, or do they become
gospel ? Is it our role to criticise the HTML spec, or should we
simply accept its literal truth on all matters - even the bit where it
says "Blessed are the cheesemakers"?
It suggests use that is contrary to its normative prose.
I don't have a problem with that. My mahayana view of the spec is that
it is a broad church and these contradictions are part of it. We
should be slow to describe things as "contrary to its normative prose"
and thus incorrect - if they're still in the spec, then they have some
purpose.
It's a bit similar to some statements there that imply that
<blockquote> _has_ been used for mere indentation (but shouldn't be -
though it just "deprecates " such usage instead of forbidding it).
<blockquote> alone has not been used for indentation - the
_combination_ of HTML and presentation styling (CSS or pre-CSS) is
used for indentation. There's nothing in the HTML spec, or at the
level of a purely HTML spec, that indicates any connection with
indentation. The default <blockquote> rendering could just have easily
have been chosen to be some non-indented font change.

<dl> is different though - there are features of the formal HTML spec
(normative, informative and DTD) that describe its structure.
Paying attention to semantics, you mean? Is it also incorrect that a
speech browser says "start of form one" when it encounters the start of a
<form> element?
No.
a browser should not assume that <form> actually means 'form'.
A browser should assume that a <form> is a "user interaction
component", because that's a functional part of HTML. In the absence
of a clearer term, describing this as a "form" is reasonable, even
though I accept your point that not all <form>s are 'forms'.

Oh really? In fact, HTML has been, and still is, extremely clumsy and
primitive for any presentation of physics matters even at high school
level,
High school physics is hard to typeset. Hard stuff is much easier. A
picture may be worth a thousand words, but only if they're short and
simple words. I look down my bookshelves and my school physics
textbooks are full of pictures, my son's have coloured pictures and
little else, and the university tomes are heavy text with barely a
graph.
It was
specifically designed as _general_, with concepts like 'list',
'paragraph', 'emphasis' and 'block quotation', rather than application-
oriented concepts.

This is definitely a good thing, especially when you contrast it with
DocBook. It still has (or had) more notions for moderately formal
journal publications than you might have expected had M$oft invented
HTML though.

And with that ghastly thought, I shall leave you.

[Jukka K. Korpela]

di*****@codesmi ths.com (Andy Dingley) wrote:

Topology is about position/placement, as ordering and
connectivity, but definitely not about position/placement as physical
location.
In someone's terminology. You seem to identify "topology" with nesting of
elements, more or less.

But if you consider the general possibilities, how do you define
which <dt> corresponds to which <dd>? It's _not_ in the
specification.

You can't by HTML alone - you'd have to head off into ID & IDREF
territory.

It could have been defined in HTML specifications in prose, but
unfortunately wasn't.

Huh? That's still just syntax, not semantics,

So what's the difference ?

I think you know it better than your messages suggest.
This whole thread is about taking a
syntactic definition of HTML and arguing over how far it is valid to
extrapolate this into an assumed semantics.
No, not at all. It's about the _semantic_ definition, presented in prose.
The syntax is given in the DTD, and we have no argument on it.
A very reasonable
response to that is to throw the towel in and say simply that "HTML
has no semantics".
That would be pointless, since all HTML specifications contain semantic
statements, or (in the case of XHTML) normatively refer to specifications
containing them. You can argue that the semantics is poor or wrong, but
it would be foolish to say that it does not exist.
It's close enough for jazz (as I said, I'd forgotten about the
inclusion of <script>). My point is that nesting <dl> would be a
gross non-validity, nesting <blockquote> is just semantically
dubious.
Pardon? <dl> elements can be nested, validly though perhaps not
semantically meaningfully. Nesting <blockquote> is not dubious at all; or
let's say that it is no more dubios than each <blockquote> element in a
nest per se is - if it's not a block quotation, it's semantically
incorrect, whether it's nested or not.
_Can_ a spec be self-contradictory ?
Of course. A specification can say "the <blockquote> element means a
block quotation from an external source" in one place and
"the <blockquote> element means whatever you want it to mean".
It's logically self-contradictory, irrespective of our opinions on which
statement is better. HTML specs don't do that to <blockquote>. They don't
formally do it to <dl> either, but come very close to doing that.
Is it our role to criticise the HTML spec, or should
we simply accept its literal truth on all matters - even the bit
where it says "Blessed are the cheesemakers"?
The problem is with the combination of "Blessed are the cheesemakers" and
"Cursed are the cheesemakers".
My mahayana view of the spec is
that it is a broad church and these contradictions are part of it.
So you, too, think that a specification can be self-contradictory? I'm
not quite with you in the quasi-zen idea of making that a virtue.
<blockquote> alone has not been used for indentation - the
_combination_ of HTML and presentation styling (CSS or pre-CSS) is
used for indentation.
Not correct. Several tutorials describe <blockquote> itself as meaning
'indent', it actually has an indenting effect on most browsers (counted
by frequency of usage), and is commonly used just for that effect. You
will probably find many more pages that use <blockquote>, typically with
no styling for it, for mere indentation than pages using it to denote
block quotations.
<dl> is different though - there are features of the formal HTML spec
(normative, informative and DTD) that describe its structure.
Exactly which features, apart from the formal syntax, which we both know
and which is just the formal syntax that allows any combination of <dd>
and <dt> elements inside? What other structure there is, and exactly
where it is described normatively and how does it imply a particular
rendering, as you (rather strangely) seem to imply?
A browser should assume that a <form> is a "user interaction
component", because that's a functional part of HTML.

A <form> element is defined along such semantic lines. So why wouldn't
semantic definitions be relevant for <dl>?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Andy Dingley]

On Tue, 13 Jul 2004 16:30:13 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tu t.fi> wrote:

You seem to identify "topology" with nesting of
elements, more or less.
In this context, that's about it (and their permitted ordering too)

Consider the tree structure that represents a HTML document, and the
tree fragment that represents a <dl> and its valid children. Now
consider a <ul> and children, or a <table> and children. A
topological view of these (preserving only those features that are
topologically significant, such as permitted children and any order
constraints upon them) makes the three sets of all possible valid
combinations clearly distinct for all but the most trivial of cases.

<ul><li /></ul> is no different from <dl><dt /></dl> or from
<table><tr><t d /></tr></table>, but they're pretty much the most
complex instances where you can still claim that.

But if you consider the general possibilities, how do you define
which <dt> corresponds to which <dd>? It's _not_ in the
specification.

[...]
It could have been defined in HTML specifications in prose, but
unfortunatel y wasn't.
Agreed. It could also have been strongly implied by a small (and
obvious) change to the DTD.

No, not at all. It's about the _semantic_ definition, presented in prose.
OK then, it's about the question of whether the prose normative
description component of the HTML spec is adequate to express any
useful level of semantics.
Pardon? <dl> elements can be nested,
No, only indirectly (via <dd>)

<blockquote><bl ockquote> is valid, <dl><dl> isn't.

<blockquote> alone has not been used for indentation - the
_combination_ of HTML and presentation styling (CSS or pre-CSS) is
used for indentation.

Not correct. Several tutorials describe <blockquote> itself as meaning
'indent', it actually has an indenting effect on most browsers

Several tutorials decribe "the alt tag", but that doesn't make it
right.

<blockquote> alone has no rendering. HTML alone has no rendering. Only
when we combine HTML with either some actual observed behaviour, or
some suggestion of an intended behaviour (such as CSS), can we start
to make statements like "<blockquot e> has been observed to cause
indenting". It's not in the language itself.

<dl> is different though - there are features of the formal HTML spec
(normative, informative and DTD) that describe its structure.

Exactly which features, apart from the formal syntax, which we both know
and which is just the formal syntax that allows any combination of <dd>
and <dt> elements inside?

Almost every reference to <dl>. They don't describe _much_ of its
structure, and largely they're repeating the DTD, but they describe
enough to make it obviously distinct from <ul>, <blockquote> or
<table>
how does it imply a particular rendering, as you (rather strangely) seem to imply?
I don't believe I've ever implied such a thing - only that <dl>'s
children are of two types. I haven't even implied that these two types
would be rendered at all differently (obvious assumption though that
is)
So why wouldn't semantic definitions be relevant for <dl>?

Of course they are (although I'd prefer "semantic implications" to
"definition s"). But that's a long way from assuming that _only_one_
semantic interpretation is correct, which is what you appear to be
arguing in favour of, and is the behaviour expressed by the
hypothetical browser that prefixes every <dt> with "Term:"

--
Smert' spamionam

[Jukka K. Korpela]

Andy Dingley <di*****@codesm iths.com> wrote:

On Tue, 13 Jul 2004 16:30:13 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tu t.fi> wrote:

You seem to identify "topology" with nesting of elements, more or
less.
In this context, that's about it (and their permitted ordering too)

That's what I thought - so "topology" means syntax. It is useful to
understand that markup systems like SGML, XML, and official HTML (as
opposite to tag soup HTML) syntax is really a tree structure, with
ordered leaves - represented in linearized notation. But I don't think
it's useful to call this "topology".

Pardon? <dl> elements can be nested,

No, only indirectly (via <dd>)

Of course. Just as normal lists (<ol> and <ul>) can be nested only
indirectly, but it is still common to refer to "nesting lists". The word
"nested" is not a formal concept, it's just a way to refer to syntactic
structures in a practical way.

<blockquote> alone has not been used for indentation - the
_combination_ of HTML and presentation styling (CSS or pre-CSS) is
used for indentation.

Not correct. Several tutorials describe <blockquote> itself as
meaning 'indent', it actually has an indenting effect on most
browsers

Several tutorials decribe "the alt tag", but that doesn't make it
right.

The alt attribute is not defined to mean a tooltip, but it is often
described as a tooltip and actually _used_ to create a tooltip effect.
This doesn't make it right, but it's a reality - just as it is a reality
that <blockquote> alone has been used for indentation.
<blockquote> alone has no rendering.

In the same sense, <dl alone has no rendering. But you are in fact using
it for the rendering you assume (due to observations on what browsers
actually do).

Here's a quick semanticity test: if you are using an HTML element <foo>
according to its defined semantics, as defined in normative prose in HTML
specifications (in statements like "the <foo> element means a foothing"
or "the <foo> element indicates a foothing" or "the <foo> element is a
foothing"), then you should regard it as acceptable in principle, though
perhaps very clumsy in practice, to have the element
<foo>xxx</foof>
rendered as the (written or spoken) text
Start of a foothing. xxx. End of a foothing.
(It wouldn't always ne as clumsy as it sounds. Think about speech
browsers or browsers working on very small display, trying to render
elements that are difficult to render that way. Like blockquote or dl.)

I think you cannot accept this test, since it would take you into some
trouble - after all, <dl> is defined as meaning a definition list, <dt> a
definition term, etc. :-)

<dl> is different though - there are features of the formal HTML
spec (normative, informative and DTD) that describe its structure.

Exactly which features, apart from the formal syntax, which we both
know and which is just the formal syntax that allows any combination
of <dd> and <dt> elements inside?

Almost every reference to <dl>. They don't describe _much_ of its
structure, and largely they're repeating the DTD, but they describe
enough to make it obviously distinct from <ul>, <blockquote> or
<table>

Obviously distinct in what ways? By defining it as a definition list,
with terms and definitions, as opposite to <ul>, which is just an
unordered (or unnumbered) list.

So why wouldn't semantic definitions be relevant for <dl>?

Of course they are (although I'd prefer "semantic implications" to
"definition s"). But that's a long way from assuming that _only_one_
semantic interpretation is correct, which is what you appear to be
arguing in favour of, and is the behaviour expressed by the
hypothetical browser that prefixes every <dt> with "Term:"

When I say "<foo> means a foothing", I'm giving a semantic definition,
if there is such a thing as semantic definition. The meaning is
explicitly expressed, not implied. The definition itself might be open to
different interpretations - what does "foothing" really mean? - but this
is a matter of interpreting an explicit statement, not making up
some "semantic implications". Besides, is there _really_ much to be
interpreted about "definition term", for example? If there is, then
"Term:" can be interpreted in different ways, too, so there should be no
fundamental objection against it, right? (Except maybe that it should be
more exactly "Definition term:" :-))

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Tim]

On Mon, 12 Jul 2004 15:18:01 +0000 (UTC),
"Jukka K. Korpela" <jk******@cs.tu t.fi> posted:

But if you consider the general possibilities, how do you define which
<dt> corresponds to which <dd>? It's _not_ in the specification.

There's only one logical way to do that sort of thing:

<dl><dt>Term to be defined</dt>
<dd>A definition of that term</dd>
<dd>Another definition of that term</dd></dl>

<dl><dt>A different term to be defined</dt>
<dd>A definition for this term</dd>
<dd>Another definition of this term</dd></dl>

But this sort of thing, as exampled in the HTML 4 specs, is illogical:

<dl>
<dt>Term to be defined</dt>
<dd>A definition of that term</dd>

<dt>A different term to be defined</dt>
<dd>A definition for this term</dd>
</dl>

It may well be a list of definitions, but it's lacking coherent
associations and distinctions between individual items.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

[Brian]

Jukka K. Korpela wrote:

Andy Dingley <di*****@codesm iths.com> wrote:

"Jukka K. Korpela" <jk******@cs.tu t.fi> wrote:

Several tutorials describe <blockquote> itself as meaning
'indent', it actually has an indenting effect on most browsers

<blockquote> alone has no rendering.

In the same sense, <dl alone has no rendering. But you are in fact
using it for the rendering you assume (due to observations on what
browsers actually do).

Although I don't agree with A. Dingley's broad point, I do think
there's a difference between these cases. <blockquote> used as
indentation is an attempt to achieve a layout based on the default
layout of a particular element. Using <dl> as a way to connect two
different items (<dt> and <dd>) in a list is not really abusing the
element for its rendering.

I don't disagree that the semantic meaning of <dl> is clearly for
marking up definition lists (obviously). Thus, using it to connect
dialogue with characters may not be correct, but the goal here isn't
to achieve a layout, it's to connect a line of dialogue with a
character. Indeed, it's possible to use that markup and then
completely change the layout with css.

markup:

<DL>
<DT>Caligula</DT>
<DD>C'etait difficile a trouver</DD>[1]
<DT>Helicon</DT>
<DD>Quoi donc ?</DD>
<DT>Caligula</DT>
<DD>Ce que je voulais.</DD>
<DT>Helicon</DT>
<DD>Et que voulais-tu ?</DD>
<DT>Caligula</DT>
<DD>La lune.</DD>
</DL>

default layout:

Caligula
C'etait difficile a trouver
Helicon
Quoi donc ?
Caligula
Ce que je voulais.
Helicon
Et que voulais-tu ?
Caligula
La lune.
Not necessarily ideal, as you've pointed out elsewhere. One might prefer:

Caligula: C'etait difficile a trouver
Helicon: Quoi donc ?
Caligula: Ce que je voulais.
Helicon: Et que voulais-tu ?
Caligula: La lune.
The markup is being used in a semantic way -- to connect one item with
another in a list -- but the <dl> was created with a more specific
meaning, to connect only terms with definitions in a list. For my
part, I'd prefer that HTML had a more general complex list for such
needs. It could then have been used for definition lists, or for other
lists as well.
[1] I left off accents in the dialogue; I don't know what sort of
effect such characters might have on your newsreaders.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/

[Andy Dingley]

"Jukka K. Korpela" <jk******@cs.tu t.fi> wrote in message news:<Xn******* *************** *******@193.229 .0.31>...

That's what I thought - so "topology" means syntax.
To paraphrase both Bill Clinton and Humpty Dumpty, ‘that all depends
on what "means", means'.

Syntax here is implying constraints on topology. I have no intention
of stating more than this; neither that syntax is the same thing as
topology, nor that topology "means" syntax. There's a causal
relationship – syntax is implying a set of permitted topologies here,
topology does not imply syntax. Nor do I claim they're equivalent,
just because one manifests the constraints expressed by another.
It is useful to
understand that markup systems like SGML, XML, and official HTML (as
opposite to tag soup HTML) syntax is really a tree structure, with
ordered leaves - represented in linearized notation.
HTML is _not_ a generalised tree structure.

SGML and XML are.

I think this is true for SGML, although I'm more of an XML guy. It's
also arguable, especially for XML / XHTML, that it's not the
_document_ that may have this tree structure, but the document's
Infoset. Now this is a contentious term, and I know many SGML people
hate the whole concept, so can we please agree to ignore our
disagreements for the moment and treat the two views of it equally.

HTML (and XHTML) are mappable to a tree structure and may be fully
represented by a tree structure, but their own constraints from the
DTD mean that their content model is a subset of everything that would
be permitted as a general "tree structure".

As a trivial example, show me some valid HTML where the first branch
is more than a few elements deep. Although you can stack <body> and
<div> as deep as you like, you can't do that to <head>. So can we
please agree here that although HTML does have a tree-like structure,
it only allows a subset of all the possible trees.

This is the matter under discussion – the subsetting of tree
structures, according to the extra constraints of HTML.

My thesis (1st point)
In a restricted context of opaque semantics and limited to the level
where elements are only distinguishable by their element name, there
is still a difference between <dl> and <ul>. <dl> allows children of
two types, <ul> of only one.
But I don't think it's useful to call this "topology".
So what else do we call it ? We're discussing it, it's a useful thing
to discuss, and we have a need for a term about it.

Lets call it foo-ology if it makes you happier. It's pointless to get
wrapped up in a question of what the term means, when we already (I
think) have reasonable agreement on what we're actually using it to
represent.

Pardon? <dl> elements can be nested,

No, only indirectly (via <dd>)

Of course. Just as normal lists (<ol> and <ul>) can be nested only
indirectly, but it is still common to refer to "nesting lists".

Indeed – and a "list" can be nested, but an "element" can't (for
<dl>). If I'd meant "list structure composed of multiple element
types", I'd have said so.

The difference between <dl> and <blockquote> is that <dl> changes the
permitted content model of a document inside the element, <blockquote>
does not. Also <dl> does this differently to <ul> or <table>.

The alt attribute is not defined to mean a tooltip, but it is often
described as a tooltip and actually _used_ to create a tooltip effect.
This doesn't make it right, but it's a reality - just as it is a reality
that <blockquote> alone has been used for indentation.
You still don't understand my point. Alt attributes alone don't cause
tooltips, alt attributes in "helpful" browsers cause tooltips. The
HTML document alone doesn't do it (It doesn't do much at all really,
unless you can read filesystem bytes directly)

My thesis (2nd point)
There's _nothing_ in the ur-nature of HTML that says <blockquote>
leads to indentation, or that alt leads to a tooltip. There is however
something that says <dl> has children of two types. You _cannot_have_
(valid) HTML that does not say this (for all the versions of HTML I
have to hand)

<blockquote> alone has no rendering.

In the same sense, <dl alone has no rendering. But you are in fact using
it for the rendering you assume (due to observations on what browsers
actually do).

I don't think I've discussed the rendering of <dl> (maybe I did, but
that's irrelevant). What I'm talking about is the _structure_ of <dl>
and its contents. That still exists, even without any browser
implementations , as soon as your world includes the HTML spec.

rendered as the (written or spoken) text
Start of a foothing. xxx. End of a foothing.

I just don't believe that the normative prose of the HTML spec can
"define semantics".

My thesis (3rd point)
I believe that it can _suggest_ them, but no stronger. It's a
difficult thing to define semantics – it needs all sorts of contextual
issues to be addressed, for one thing. In the world of HTML, for a
terse HTML spec (and it is pretty terse, for such a significant
standard), there just isn't the depth to do so.

DocBook might define semantics (or attempt to) for its elements. It's
a spec of much less scope, and it's considerably more verbose.

In your example, I can accept a browser that treats <foo> as being a
foothing, but it should be "lightweigh t" about how obvious it makes
this.

We're back to the issue of contradictions in the spec. I don't believe
in their existence – the spec is just _right_, because it's the spec
that defines what "right" is (an oddly Biblical view for me, but there
you go). I believe in the potential existence of contradictions, but
also that they're going to be both rare and non-obvious. If the spec
(as for <dl>) makes two clear implications about the semantics of
<dl>, then our understanding should be that _both_ are valid, not that
one can be ignored (and which one is selected at the reader's whim ?)

"Here is a foothing" is probably vague enough to never be demonstrably
wrong (if annoyingly repetitive). Describing every instance of
<address> as "The author of this document's postal address" is
over-stepping the bounds though. It's not always postal and it's
described in the prose as being applicable to sub-parts of a document
– let alone the common (if incorrect) "Yellow Pages" use of it.

My thesis (conclusion)
Building excessive assumptions into a user agent is wrong. Not just
because it degrades so badly with "typical" tag soup but also, as I've
said before, because it's simply a mistake to take the normative prose
on semantics as anything more than suggestions. Treating <dl> as
_always_ being a definition list is _wrong_, because the spec says so.

"Another application of DL, for example, is for marking up
dialogues,"

is not something you can choose to ignore, just because it breaks your
cutesy little hard-coded talking dictionary. If the spec says this as
well as the obvious definition list, then it means that both are
potential uses and there _is_no_ single semantic definition.

[Jukka K. Korpela]

di*****@codesmi ths.com (Andy Dingley) wrote:

"Jukka K. Korpela" <jk******@cs.tu t.fi> wrote in message
news:<Xn******* *************** *******@193.229 .0.31>... - -

It is useful to
understand that markup systems like SGML, XML, and official HTML (as
opposite to tag soup HTML) syntax is really a tree structure, with
ordered leaves - represented in linearized notation.

HTML is _not_ a generalised tree structure.

HTML, in the official version, is a tree structure. You cannot seriously
take any other position, since the official version defines HTML as an
application of SGML or XML. The word "generalise d" is yours.
In a restricted context of opaque semantics and limited to the level
where elements are only distinguishable by their element name, there
is still a difference between <dl> and <ul>. <dl> allows children of
two types, <ul> of only one.
You are still talking about syntax only. Calling it "opaque semantics" is
just confusing.
There's _nothing_ in the ur-nature of HTML that says <blockquote>
leads to indentation, or that alt leads to a tooltip. There is
however something that says <dl> has children of two types.
The <p> element has children of several types. Do you draw some drastic
conclusions on semantics from this, too?
I just don't believe that the normative prose of the HTML spec can
"define semantics".
Unless you think they can, there is no meaning in anything in HTML.
It's just pure syntax - whether tag soup or element trees.
We're back to the issue of contradictions in the spec. I don't
believe in their existence – the spec is just _right_, because it's
the spec that defines what "right" is (an oddly Biblical view for me,
but there you go).
Even when it says one thing at one point and an opposite thing at
another? (I'm afraid the theological analogy is alarmingly obvious: if
you decide a priori that contradictions are impossible, you might face a
gigantic task of "harmonizin g" things.)
"Here is a foothing" is probably vague enough to never be
demonstrably wrong (if annoyingly repetitive).
Really? If someone uses h6 in a very obvious attempt at making some text
at the bottom of a page, with no text after it, appear in a small font,
would you still say that the definition "h6 is a 6th level heading" is
too vague for a conclusion that the page's markup is semantically wrong?
Describing every
instance of <address> as "The author of this document's postal
address" is over-stepping the bounds though.
Of course, and no specification ever said <address> needs to contain a
_postal_ address. (An otherwise good old guide, the NCSA one, even
claimed that it _must not_ be used for postal addresses.) It's contact
information, which could be a postal address, an E-mail address, a
telephone number, or something else.
"Another application of DL, for example, is for marking up
dialogues,"

is not something you can choose to ignore, just because it breaks
your cutesy little hard-coded talking dictionary.

The HTML 4.01 specification also says, though more indirectly, that
another application of BLOCKQUOTE, for example, is for indenting text. It
says this indirectly by declaring such usage now as "deprecated ". Would
you say this is not something that you can choose to ignore, just because
etc. etc.?

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html