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.

[Neal]

On Thu, 08 Jul 2004 10:42:18 -0400, Brian
<us*****@juliet remblay.com.inv alid> wrote:

Frankly, I don't know why the recommendations have general use stuff
like <p> and <table> on the one hand, and rediculously specific-use
markup like <dl>, <var>, and <samp> on the other.

And the pre element. That's entirely presentational!

[Jukka K. Korpela]

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

Who cares what the default semantics of <dl> are ?
I do, and its not a matter of "default semantics" but "semantics" .
There's such a thing as default rendering, but no such thing as default
semantics.

But this is mostly a matter of discussing a symptomatic example. The <dl>
element per se is not very interesting. What matters is that if we use an
element with _no_ idea of its _meaning_, and deceive ourselves thinking
that it has a "broad meaning" when it has none, then we'll take this
attitude to other matters and obfuscate our markup. Surely if <dl>
"means" whatever you think it looks like, <blockquote> "means" indent and
<h6> "means" small font, right?

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?
They're no clearer
or less clear than <h2> or <address>

Surely they are. There's no problem around the semantics of <h2>, and the
problem with <address> is more with its name than its meaning.

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

[Andy Dingley]

Brian <us*****@juliet remblay.com.inv alid> wrote in message news:<10******* ******@corp.sup ernews.com>...

Andy Dingley wrote:

Who cares what the default semantics of <dl> are ? They're no clearer
or less clear than <h2> or <address> (<address> is surely the most
confused, yet useful)
To answer both Brian and Jukka

I'd say <h2> is pretty clear: a second level heading, a sub-heading.
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. HTML makes no such constraint and
although there are _some_ interpretations of them where such a
constraint is valid, it's certainly not true for all of them (so keep
_your_ constraints out of _my_ contexts)

<address> is oddly named, but the semantics seem clear enough. "Who's
responsible for this page?"
The semantics are only clear if you read the spec ! How many times
have you seen <address> used in a context of "Contact details for one
entity, which may be a list of several and might not even be 'the
page'". Is it valid to use <address> on a Yellow Pages site ? Can it
ever be valid to have more than one on a single page ?

There's also the question of data type. Is a phone number an address ?
Clearly not, but the HTML spec does clarify that this is still an
acceptable use. As Jukka suggests, the intended meaning itself is
perhaps clearer (if anyone reads it) than the assumption most authors
would draw from the name.

Personally I think the spec is wrong here. Wording of "contact or
location details" would be just as well applicable for the authorship
case and it would extend it to addresses of generalised entities.
IMHO, this would be a useful feature.

Frankly, I don't know why the
recommendations have general use stuff like <p> and <table> on the one
hand, and rediculously specific-use markup like <dl>, <var>, and
<samp> on the other.
I can guess. I used to share cubespace with Dave Raggett, and whenever
you mentioned such things there was a look of horror that spread over
his face. I suspect that HTML 3.2 features have about the same
resonance for the HTML 4.0 team as the Orcish hordes over-running
Helm's Deep.

OTOH, I still use <menu>
Who cares what the default semantics of <dl> are ?

I do, and its not a matter of "default semantics" but "semantics" .
There's such a thing as default rendering, but no such thing as default
semantics.

I mean the semantics that are assumed in the absence of any further
qualifying mechanism. These are by necessity bland. They're either in
a context (such as vanilla HTML) where there's little scope to specify
them more tightly for any instance, or they're in a full-blown SemWeb
context where everything that matters is draped with dangling URIs
like Inca khipu (and so anything that isn't specified, ought to be
regarded as unworthy of being so).
But this is mostly a matter of discussing a symptomatic example.
Agreed. There just isn't enough depth in HTML to really allow this
argument to be taken to a worthwhile conclusion. Even with a good and
precise understanding of <dl>, we'd still only have one tiny island in
a vast empty sea.

Surely if <dl> "means" whatever you think it looks like, <blockquote> "means" > indent and <h6> "means" small font, right?
Topology vs. typography.

<dl> means "two part structure to the list elements", which is a
topological distinction, no matter how you render it. <blockquote> is
merely fonts and margins.

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?

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

[Lachlan Hunt]

Neal wrote:

And the pre element. That's entirely presentational!

No, it's not! <pre> stands for preformatted text, unlike the
white-space: pre; css value which stands for preserve white space.
Preformatted text is used when it's semantically important to preserve
the formatting. I realise that may be a very fine line between
presentation and semantics, but it's best explained with some examples.
eg. Marking up blocks of code, plain text such as emails (like in many
mailing list archives), ASCII art, etc.

--
Lachlan Hunt
http://www.lachy.id.au/
la**********@la chy.id.au.updat e.virus.scanners

Remove .update.virus.s canners to email me,
NO SPAM and NO VIRUSES!!!

[Brian]

Andy Dingley wrote:

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.
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?
HTML makes no such constraint
It seems to go out of its way to not impose such constraints.

<address> is oddly named, but the semantics seem clear enough.
"Who's responsible for this page?"

The semantics are only clear if you read the spec !

Hence, "oddly named," but still semantic.
How many times have you seen <address> used in a context of
"Contact details for one entity, which may be a list of several and
might not even be 'the page'".
Not as often as I've seen blockquote for indent, which is far worse.
Regardless, I don't base good practice on the www's worst examples of
HTML.
Is a phone number an address ?
Not in the English language sense, no.
the HTML spec does clarify that this is still an acceptable use.

Of course, since <address> is for contact info, and phone number is a
means of contact.

Frankly, I don't know why the recommendations have general use
stuff like <p> and <table> on the one hand, and rediculously
specific-use markup like <dl>, <var>, and <samp> on the other.

I can guess. I used to share cubespace with Dave Raggett, and
whenever you mentioned such things there was a look of horror that
spread over his face. I suspect that HTML 3.2 features have about
the same resonance for the HTML 4.0 team as the Orcish hordes
over-running Helm's Deep.

I'm not sure I follow. Did the elements I mentioned only enter the
spec at 3.2? Or 4.0?

Jukka Korpela wrote:

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>

That would be a broken browser. <dl> isn't defined to anything like
that level of detail,

What do you mean? It's defined to be a definition list. How can you
declare a browser broken if it does something with the definitions
contained therein?

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

[Claire Tucker]

On Fri, 09 Jul 2004 08:54:58 -0400, Brian
<us*****@juliet remblay.com.inv alid> wrote:

Andy Dingley wrote:

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.

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?

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

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

I'd say <h2> is pretty clear: a second level heading, a sub-heading.
So what's a "second level heading" ?

A heading for a part of a document at the outermost level of division
into sections.
Is <h1 ... /><h3 ... /> still valid ?
Of course, and you knew it. Validity is a formal concept, not about
semantics.
There's some debate over the ordering of these header elements and
whether they need to maintain a strict sequence.
Yes, but this does not make the semantics of <h2> vague.
The semantics are only clear if you read the spec !
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?).

Surely if <dl> "means" whatever you think it looks like,
<blockquote> "means" > indent and <h6> "means" small font, right?

Topology vs. typography.

"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.
<dl> means "two part structure to the list elements", which is a
topological distinction, no matter how you render it.
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.
<blockquote> is merely fonts and margins.

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.

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?

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

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

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

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

Is <h1 ... /><h3 ... /> still valid ?

Of course, and you knew it. Validity is a formal concept, not about
semantics.

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]

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

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

Surely if <dl> "means" whatever you think it looks like,
<blockquote> "means" > indent and <h6> "means" small font, right?

Topology vs. typography.

"Topology" is a particularly vague word, and "typography " isn't much
better

What's vague about topology ?

<dl> means "two part structure to the list elements", which is a
topological distinction, no matter how you render it.

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.

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.

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

<blockquote> is merely fonts and margins.

No, <blockquote> is merely 'block quotation', as you know.

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

If you take markup seriously,

I don't take HTML markup that seriously. It just doesn't have the
scope for that level of detail.
<dl> is defined as a definion list, consisting of definition terms and
definition data.
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.

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

On Mon, 12 Jul 2004, 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. [..] 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.

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