Problem with descriptive lists in CSS

[Claire Tucker]

Re: Problem with descriptive lists in CSS

On Fri, 09 Jul 2004 08:54:58 -0400, Brian
<usenet3@juliet remblay.com.inv alid> wrote:
[color=blue]
>Andy Dingley wrote:
>[color=green]
>> Brian wrote...
>>
>> So what's a "second level heading" ? Is <h1 ... /><h3 ... />
>> still valid ? There's some debate over the ordering of these header
>> elements and whether they need to maintain a strict sequence.
>>
>> Personally I think this is bogus.[/color]
>
>FWIW, I don't. I would no sooner skip <h2> in a document then I would
>make an outline that skipped a level. Really, skipping a level in an
>outline makes no sense. So why do it in HTML?
>[/color]

....and this, of course, is why we should have had nested sections
rather than explicit headings:

<section>
<heading>Blah blah blah</heading>

.....

<section>
<heading>Blah blah blah</heading>

....
</section>

</section>


I seem to remember this was planned for XHTML 2.0 many moons ago. Too
bad it's too late now. I've lost count of the number of times I've had
to reconcile the heading order of documents included in other
documents. Doing it manually is bad enough, but when doing it in an
automated system to documents written by others (such as in CMS or
perhaps weblog software) this is one headache I wish had never
happened.

So the legacy of HTML continues to haunt us.....

-Claire

[Jukka K. Korpela]

Re: Problem with descriptive lists in CSS

dingbat@codesmi ths.com (Andy Dingley) wrote:
[color=blue][color=green]
>> I'd say <h2> is pretty clear: a second level heading, a sub-heading.[/color]
>
> So what's a "second level heading" ?[/color]

A heading for a part of a document at the outermost level of division
into sections.
[color=blue]
> Is <h1 ... /><h3 ... /> still valid ?[/color]

Of course, and you knew it. Validity is a formal concept, not about
semantics.
[color=blue]
> There's some debate over the ordering of these header elements and
> whether they need to maintain a strict sequence.[/color]

Yes, but this does not make the semantics of <h2> vague.
[color=blue]
> The semantics are only clear if you read the spec ![/color]

Indeed. The semantics is defined in the normative prose in a
specification, not by guesswork or suggestive names, though naturally
names _should_ reflect the semantics (but HTML became rather obscure, in
its poor compromise between conciseness and informativeness in element
and attribute names - who would have guessed the meaning of <a> from its
name?).
[color=blue][color=green]
>> Surely if <dl> "means" whatever you think it looks like,
>> <blockquote> "means" > indent and <h6> "means" small font, right?[/color]
>
> Topology vs. typography.[/color]

"Topology" is a particularly vague word, and "typography " isn't much
better - the coarse formatting that we can do using some presentational
HTML is really very far from what typographers regard as typography.
[color=blue]
> <dl> means "two part structure to the list elements", which is a
> topological distinction, no matter how you render it.[/color]

How would that be topological? But anyway, you just made up your own
definition of <dl>, a definition that the HTML spec does _not_ give.
And it looks rather redundant, since it is just a special case of a table
- an m by n table where n = 2.
[color=blue]
> <blockquote> is merely fonts and margins.[/color]

No, <blockquote> is merely 'block quotation', as you know. And it does
not affect the font in any browser used nowadays. But since most browsers
indent blockquote elements in rendering, it would be quite natural to say
that blockquote stands for 'indent', _if_ you take the same approach as
in a look at <dl> as creating paired expressions in a particular layout.
[color=blue][color=green]
>> If you take markup seriously, you ask yourself: if some browser
>> starts actually supporting <dl> as defined, perhaps visually
>> highlighting <dt> elements strongly, perhaps entering them into a
>> database of terms, perhaps uttering "term" before speaking the
>> content of <dt> and "definition " before speaking <dd>, will you be
>> delighted or feel dirty?[/color]
>
> That would be a broken browser. <dl> isn't defined to anything like
> that level of detail, and it's _wrong_ to start assuming it is
> (which isn't to say that some browser doesn't already).[/color]

<dl> is defined as a definion list, consisting of definition terms and
definition data. Which of the possible renderings I mention would fail to
correspond to that? They would all correspond to it better than most of
the default renderings in current browsers.

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." (or "quote" and "unquote") before
and after the content of the element. It might not be stylistically
optimal in a particular situation, but if you call a browser broken
because of that, then it's your markup that is broken.

It is left as an exercise to consider the completely analogous case of
presenting <dd>...</dd> as "Definition : .... End of definition." and
<dt>...</dt> as "Term: ... End of term" or, more reasonably, just
"Term: ..." (since terms are short, typically a single word or
abbreviation).

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

[Andy Dingley]

Re: Problem with descriptive lists in CSS

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message news:<Xns9521D2 142960Djkorpela cstutfi@193.229 .0.31>...[color=blue]
> dingbat@codesmi ths.com (Andy Dingley) wrote:[/color]
[color=blue][color=green]
> > Is <h1 ... /><h3 ... /> still valid ?[/color]
>
> Of course, and you knew it. Validity is a formal concept, not about
> semantics.[/color]

Of course I did - but only in the HTML context.

There are documents where only the strict "outline view" is valid.
There is a view (which I don't myself hold, but I see the validity of
it) that this should be applied to web pages too - Claire seems to
take this view. Now this has to be applied at a meta-level above HTML
validation, because the only definite thing we know that we have here
is a HTML DTD where <h1.../><h3.../> _is_ formally valid.

I don't like the "strict outline view", because it's hard to generate,
particularly automatically. If a document is large, or has many pages,
then the decision has to be made to reconcile variations onside the
dsocument in one of the following ways:

- Apply sequentially nested headers, even if some sibling items in
different branches of the tree appear to have "an equal level of
difference", yet they find themselves labelled as <h2> in one place
and <h4> in the other. This is formally accurate according to our
outlining notion, but it's misleading and confusing to a human reader.
We're used to seeing headings in one style meaning that there's a
consistent level of difference between siblings.

- Apply sequentially numbered headers, and manually insert "filler"
headings to level out the distinctions to the same level (i.e. our
distinguishable sibling examples all end us as sets of <h4>). This is
hard to do automatically, and the fillers can look contrived and
arbitrary.

- Abandon the use of <h1> and go for a pure tree-structure of
<heading> and <subsection>. This is logically neat, but it's just not
the human readable way for typographically labelled headings.

To make an analogy with biological taxonomy, the first approach is
that of classical Linnaean taxonomy and the last is that of modern
cladistics. The middle approach is that of empirical Linnaean
systematics, where creature distinctions were shoe-horned into an
arbitrary framework, however poorly they were thus represented.

[Andy Dingley]

Re: Problem with descriptive lists in CSS

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message news:<Xns9521D2 142960Djkorpela cstutfi@193.229 .0.31>...[color=blue]
> dingbat@codesmi ths.com (Andy Dingley) wrote:[/color]
[color=blue][color=green][color=darkred]
> >> Surely if <dl> "means" whatever you think it looks like,
> >> <blockquote> "means" > indent and <h6> "means" small font, right?[/color]
> >
> > Topology vs. typography.[/color]
>
> "Topology" is a particularly vague word, and "typography " isn't much
> better[/color]

What's vague about topology ?

[color=blue][color=green]
> > <dl> means "two part structure to the list elements", which is a
> > topological distinction, no matter how you render it.[/color]
>
> How would that be topological? But anyway, you just made up your own
> definition of <dl>, a definition that the HTML spec does _not_ give.[/color]

The DTD gives it:

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

This is distinct from OL or UL, as they can only contain a single type
of child element. Although these can be sub-classed by the class
attribute, only <dl> allows two distinct types at the element-naming
level.

[color=blue]
> And it looks rather redundant, since it is just a special case of a table
> - an m by n table where n = 2.[/color]

This is not the case. <dl> is a list of two child element types,
which can occur in any order. The <table> (n=2) case is itself a
restricted special case of this where the children have an implied
pairing and order within the pair. Although this is how <dl> is
described and used, it's not a limit enforced by the DTD (and it could
easily have been so). Allowing the table to omit elements in each
pair would bring it closer to <dl>, but that really is stretching
Occam's razor.

Topologically, the distinctions are _very_ clear. Think of them as
knotted string if you have to.

[color=blue][color=green]
> > <blockquote> is merely fonts and margins.[/color]
>
> No, <blockquote> is merely 'block quotation', as you know.[/color]

That's my point - it doesn't change the topology of HTML.
<blockquote> is a semantic label to a section of a document, and it's
a peg on which to hang presentation styling.

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.

<!ENTITY % block
"P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS">

<!ELEMENT BLOCKQUOTE - - (%block;|SCRIPT )+ -- long quotation -->

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>.


[color=blue][color=green][color=darkred]
> >> If you take markup seriously,[/color][/color][/color]

I don't take HTML markup that seriously. It just doesn't have the
scope for that level of detail.
[color=blue]
> <dl> is defined as a definion list, consisting of definition terms and
> definition data.[/color]

This isn't an especially restrictive definition. A few lines further
in the same section we read, "Another application of DL, for example,
is for marking up dialogues". This not only _states_ another
non-definitional application for it, but the phrasing implies that
this is one of potentially many.

[color=blue]
> 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."[/color]

My objection is that such a browser is reading too much into the HTML
spec. This spec is _not_ detailed to that level, nor is it intended to
be. 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.

[Alan J. Flavell]

Re: Problem with descriptive lists in CSS

On Mon, 12 Jul 2004, Andy Dingley wrote:
[color=blue]
> <blockquote> is a semantic label to a section of a document, and it's
> a peg on which to hang presentation styling.[/color]
[..][color=blue]
> 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.[/color]

It happens all the time on usenet: your own f'up contained examples
of it!

[Jukka K. Korpela]

Re: Problem with descriptive lists in CSS

dingbat@codesmi ths.com (Andy Dingley) wrote:
[color=blue]
> What's vague about topology ?[/color]

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').
[color=blue]
> The DTD gives it:
>
> <!ELEMENT DL - - (DT|DD)+ -- definition list -->[/color]

That's the syntax. What about the meaning? The comment is not normative,
but it corresponds to the normative prose in the specification.
[color=blue][color=green]
>> And it looks rather redundant, since it is just a special case of a
>> table - an m by n table where n = 2.[/color]
>
> This is not the case. <dl> is a list of two child element types,
> which can occur in any order.[/color]

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.
[color=blue]
> The difference between <dl> and <blockquote> is that <dl> changes the
> permitted content model of a document inside the element,
> <blockquote> does not.[/color]

Huh? That's still just syntax, not semantics, and not even true - the
<blockquote> element has a content model of its own.
[color=blue][color=green]
>> <dl> is defined as a definion list, consisting of definition terms
>> and definition data.[/color]
>
> This isn't an especially restrictive definition.[/color]

Maybe, but it's _the_ definition.
[color=blue]
> A few lines further
> in the same section we read, "Another application of DL, for
> example, is for marking up dialogues".[/color]

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).
[color=blue][color=green]
>> 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."[/color]
>
> My objection is that such a browser is reading too much into the HTML
> spec.[/color]

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'.
[color=blue]
> 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.[/color]

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]

Re: Problem with descriptive lists in CSS

Andy Dingley wrote:
[color=blue]
> <blockquote> is a semantic label to a section of a document, and
> it's a peg on which to hang presentation styling.[/color]

*Any* element is a peg on which to hang presentation styling, so that
doesn't add much to the discussion.
[color=blue]
> 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.[/color]

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]

Re: Problem with descriptive lists in CSS

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message news:<Xns9524B9 4C8424Djkorpela cstutfi@193.229 .0.31>...
[color=blue]
> The most common meanings [of topology] seem to refer to placement of physical
> objects,[/color]

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.
[color=blue][color=green]
> > The DTD gives it:
> >
> > <!ELEMENT DL - - (DT|DD)+ -- definition list -->[/color]
>
> That's the syntax. What about the meaning? The comment is not normative,
> but it corresponds to the normative prose in the specification.[/color]

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.

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

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

[color=blue][color=green]
> > The difference between <dl> and <blockquote> is that <dl> changes the
> > permitted content model of a document inside the element,
> > <blockquote> does not.[/color]
>
> Huh? That's still just syntax, not semantics,[/color]

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.

[color=blue]
> and not even true - the
> <blockquote> element has a content model of its own.[/color]

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.

[color=blue]
> The specification is self-contradictory here.[/color]

_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"?
[color=blue]
> It suggests use that is contrary to its normative prose.[/color]

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.
[color=blue]
> 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).[/color]

<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.
[color=blue]
> 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?[/color]

No.
[color=blue]
> a browser should not assume that <form> actually means 'form'.[/color]

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'.

[color=blue]
> 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,[/color]

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.
[color=blue]
> It was
> specifically designed as _general_, with concepts like 'list',
> 'paragraph', 'emphasis' and 'block quotation', rather than application-
> oriented concepts.[/color]

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]

Re: Problem with descriptive lists in CSS

dingbat@codesmi ths.com (Andy Dingley) wrote:
[color=blue]
> Topology is about position/placement, as ordering and
> connectivity, but definitely not about position/placement as physical
> location.[/color]

In someone's terminology. You seem to identify "topology" with nesting of
elements, more or less.
[color=blue][color=green]
>> But if you consider the general possibilities, how do you define
>> which <dt> corresponds to which <dd>? It's _not_ in the
>> specification.[/color]
>
> You can't by HTML alone - you'd have to head off into ID & IDREF
> territory.[/color]

It could have been defined in HTML specifications in prose, but
unfortunately wasn't.
[color=blue][color=green]
>> Huh? That's still just syntax, not semantics,[/color]
>
> So what's the difference ?[/color]

I think you know it better than your messages suggest.
[color=blue]
> 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.[/color]

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.
[color=blue]
> A very reasonable
> response to that is to throw the towel in and say simply that "HTML
> has no semantics".[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> _Can_ a spec be self-contradictory ?[/color]

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.
[color=blue]
> 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"?[/color]

The problem is with the combination of "Blessed are the cheesemakers" and
"Cursed are the cheesemakers".
[color=blue]
> My mahayana view of the spec is
> that it is a broad church and these contradictions are part of it.[/color]

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.
[color=blue]
> <blockquote> alone has not been used for indentation - the
> _combination_ of HTML and presentation styling (CSS or pre-CSS) is
> used for indentation.[/color]

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.
[color=blue]
> <dl> is different though - there are features of the formal HTML spec
> (normative, informative and DTD) that describe its structure.[/color]

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?
[color=blue]
> A browser should assume that a <form> is a "user interaction
> component", because that's a functional part of HTML.[/color]

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]

Re: Problem with descriptive lists in CSS

On Tue, 13 Jul 2004 16:30:13 +0000 (UTC), "Jukka K. Korpela"
<jkorpela@cs.tu t.fi> wrote:
[color=blue]
>You seem to identify "topology" with nesting of
>elements, more or less.[/color]

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.

[color=blue][color=green][color=darkred]
>>> But if you consider the general possibilities, how do you define
>>> which <dt> corresponds to which <dd>? It's _not_ in the
>>> specification.[/color][/color][/color]

[...]
[color=blue]
>It could have been defined in HTML specifications in prose, but
>unfortunatel y wasn't.[/color]

Agreed. It could also have been strongly implied by a small (and
obvious) change to the DTD.

[color=blue]
>No, not at all. It's about the _semantic_ definition, presented in prose.[/color]

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.
[color=blue]
>Pardon? <dl> elements can be nested,[/color]

No, only indirectly (via <dd>)

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

[color=blue][color=green]
>> <blockquote> alone has not been used for indentation - the
>> _combination_ of HTML and presentation styling (CSS or pre-CSS) is
>> used for indentation.[/color]
>
>Not correct. Several tutorials describe <blockquote> itself as meaning
>'indent', it actually has an indenting effect on most browsers[/color]

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.

[color=blue][color=green]
>> <dl> is different though - there are features of the formal HTML spec
>> (normative, informative and DTD) that describe its structure.[/color]
>
>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?[/color]

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>
[color=blue]
>how does it imply a particular rendering, as you (rather strangely) seem to imply?[/color]

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)
[color=blue]
>So why wouldn't semantic definitions be relevant for <dl>?[/color]

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]

Re: Problem with descriptive lists in CSS

Andy Dingley <dingbat@codesm iths.com> wrote:
[color=blue]
> On Tue, 13 Jul 2004 16:30:13 +0000 (UTC), "Jukka K. Korpela"
> <jkorpela@cs.tu t.fi> wrote:
>[color=green]
>>You seem to identify "topology" with nesting of elements, more or
>>less.[/color]
>
> In this context, that's about it (and their permitted ordering too)[/color]

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".
[color=blue][color=green]
>>Pardon? <dl> elements can be nested,[/color]
>
> No, only indirectly (via <dd>)[/color]

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.
[color=blue][color=green][color=darkred]
>>> <blockquote> alone has not been used for indentation - the
>>> _combination_ of HTML and presentation styling (CSS or pre-CSS) is
>>> used for indentation.[/color]
>>
>>Not correct. Several tutorials describe <blockquote> itself as
>>meaning 'indent', it actually has an indenting effect on most
>>browsers[/color]
>
> Several tutorials decribe "the alt tag", but that doesn't make it
> right.[/color]

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.
[color=blue]
> <blockquote> alone has no rendering.[/color]

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. :-)
[color=blue][color=green][color=darkred]
>>> <dl> is different though - there are features of the formal HTML
>>> spec (normative, informative and DTD) that describe its structure.[/color]
>>
>>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?[/color]
>
> 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>[/color]

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.
[color=blue][color=green]
>>So why wouldn't semantic definitions be relevant for <dl>?[/color]
>
> 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:"[/color]

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]

Re: Problem with descriptive lists in CSS

On Mon, 12 Jul 2004 15:18:01 +0000 (UTC),
"Jukka K. Korpela" <jkorpela@cs.tu t.fi> posted:
[color=blue]
> But if you consider the general possibilities, how do you define which
> <dt> corresponds to which <dd>? It's _not_ in the specification.[/color]

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]

Re: Problem with descriptive lists in CSS

Jukka K. Korpela wrote:
[color=blue]
> Andy Dingley <dingbat@codesm iths.com> wrote:
>[color=green]
>> "Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote:
>>[color=darkred]
>>> Several tutorials describe <blockquote> itself as meaning
>>> 'indent', it actually has an indenting effect on most browsers[/color][/color]
>[color=green]
>> <blockquote> alone has no rendering.[/color]
>
> 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).[/color]

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]

Re: Problem with descriptive lists in CSS

"Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message news:<Xns952664 72FFEF5jkorpela cstutfi@193.229 .0.31>...
[color=blue]
> That's what I thought - so "topology" means syntax.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
>But I don't think it's useful to call this "topology".[/color]

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.


[color=blue][color=green][color=darkred]
> >>Pardon? <dl> elements can be nested,[/color]
> >
> > No, only indirectly (via <dd>)[/color]
>
> Of course. Just as normal lists (<ol> and <ul>) can be nested only
> indirectly, but it is still common to refer to "nesting lists".[/color]

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.
[color=blue][color=green]
> > 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>.[/color][/color]


[color=blue]
> 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.[/color]

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)

[color=blue][color=green]
> > <blockquote> alone has no rendering.[/color]
>
> 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).[/color]

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.

[color=blue]
> rendered as the (written or spoken) text
> Start of a foothing. xxx. End of a foothing.[/color]

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]

Re: Problem with descriptive lists in CSS

dingbat@codesmi ths.com (Andy Dingley) wrote:
[color=blue]
> "Jukka K. Korpela" <jkorpela@cs.tu t.fi> wrote in message
> news:<Xns952664 72FFEF5jkorpela cstutfi@193.229 .0.31>...[/color]
- -[color=blue][color=green]
>> 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.[/color]
>
> HTML is _not_ a generalised tree structure.[/color]

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.
[color=blue]
> 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.[/color]

You are still talking about syntax only. Calling it "opaque semantics" is
just confusing.
[color=blue]
> 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.[/color]

The <p> element has children of several types. Do you draw some drastic
conclusions on semantics from this, too?
[color=blue]
> I just don't believe that the normative prose of the HTML spec can
> "define semantics".[/color]

Unless you think they can, there is no meaning in anything in HTML.
It's just pure syntax - whether tag soup or element trees.
[color=blue]
> 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).[/color]

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.)
[color=blue]
> "Here is a foothing" is probably vague enough to never be
> demonstrably wrong (if annoyingly repetitive).[/color]

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?
[color=blue]
> Describing every
> instance of <address> as "The author of this document's postal
> address" is over-stepping the bounds though.[/color]

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.
[color=blue]
> "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.[/color]

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