By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,723 Members | 1,662 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,723 IT Pros & Developers. It's quick & easy.

Problem with descriptive lists in CSS

P: n/a
I am trying to use descriptive lists, <DL>, as shown in
<http://www.maths.man.ac.uk/~jhaig/tmp/test.html> with a style sheet
at <http://www.maths.man.ac.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.
Jul 20 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
jh***@maths.man.ac.uk (Joseph Haig) wrote:
I am trying to use descriptive lists, <DL>,
The "D" in "DL" stands for "definition", not description. If you say
<dl><dt>foo</dt><dd>bar</dd></dl>,
then you are saying, by HTML specs, that the meaning of the term "foo" is
defined by the expression "bar". That is, to decide whether something is
a "foo", one should consult the expression "bar".
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?


What you are asking about is a CSS issue, not an HTML matter. From the
HTML standpoint, the relevant answer is that you should use DL for
definition lists - though the HTML specifications themselves obscure this
simple state of affairs. Generally, DL elements are particularly tricky
in CSS perspective, so it is not fruitful to use DL just to achieve a
particular layout, violating the semantic considerations, and then try to
prevent browsers from using that layout.

For example, using a table would probably be more fruitful if it is just
a collection of "things" and associated "notes".

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

Jul 20 '05 #2

P: n/a
Thank you for the reply.

Jukka K. Korpela wrote:
jh***@maths.man.ac.uk (Joseph Haig) wrote:
I am trying to use descriptive lists, <DL>,
The "D" in "DL" stands for "definition", not description. If you say
<dl><dt>foo</dt><dd>bar</dd></dl>,
then you are saying, by HTML specs, that the meaning of the term "foo" is
defined by the expression "bar". That is, to decide whether something is
a "foo", one should consult the expression "bar".


Specifically, I am using this for data taken from a database. <dt> contains
the field name and <dd> contains the information in that field. Not
strictly 'definitions' but I still think it is suitable. I will, however,
take your advise and see if I can do it some other way.
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?


What you are asking about is a CSS issue, not an HTML matter.


Could you please suggest a CSS newsgroup? I have not been able to find one
and this group seemed to be the most suitable for my question.

Jul 20 '05 #3

P: n/a
Joseph Haig wrote:
Specifically, I am using this for data taken from a database. <dt> contains
the field name and <dd> contains the information in that field.
That fits the structure of a definition list just fine, no need to
try and find a different method.
Could you please suggest a CSS newsgroup?


Try comp.infosystems.www.authoring.stylesheets

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

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
Jul 20 '05 #4

P: n/a
Lachlan Hunt <la**********@lachy.id.au.update.virus.scanners> wrote:
Joseph Haig wrote:
Specifically, I am using this for data taken from a database. <dt>
contains the field name and <dd> contains the information in that
field.


That fits the structure of a definition list just fine,


Not at all. The _meaning_ of a field name is quite different from the
different values in the field in different data sets. For example, if the
name is "year", then the definition might be 'the year in which the book
was published', if the database is bibliographic. The value of the field
could be "1952" or "2004" or something else; none of the values _defines_
what the field name _means_ - rather, any useful interpretation of the
data requires some external information about that meaning.

A collection of field name, field value pairs is - both theoretically and
pragmatically - best described as a table, perhaps so that the field name
is a <th> element and the field value is a <td> element, though one might
conceivably use <td> for both of them as well.

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

Jul 20 '05 #5

P: n/a
Jukka K. Korpela wrote:
Lachlan Hunt <la**********@lachy.id.au.update.virus.scanners> wrote:
Joseph Haig wrote:
Specifically, I am using this for data taken from a database. <dt>
contains the field name and <dd> contains the information in that
field.
That fits the structure of a definition list just fine,


Not at all. ... For example, if the
name is "year", then the definition might be 'the year in which the book
was published', if the database is bibliographic.


Yes, that's one interpretation of a definition list.
The value of the field
could be "1952" or "2004" or something else; none of the values _defines_
what the field name _means_


True, but a definition list isn't strictly for defining the meaning
of a term like in a glossary or dictionary. In that example, the
definition list can be interpreted as defining the value for the property.

Lets take a look at the example taken from the HTML 4.01 spec:
# Another application of DL, for example, is for marking up
# dialogues, with each DT naming a speaker, and each DD
# containing his or her words.

So, a sample definition list could be used to markup content like this:
<dl>
<dt>Fred</dt>
<dd><q>Hello Barney</q></dd>
<dt>Barney</dt>
<dd><q>Hi Fred</q></dd>
</dl>

So, technically, that doesn't fit your strict definition for a
defintion list either, since "Fred" doesn't mean "Hello Barney", it is
just the what Fred said; but it does fit what the specification says.

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

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
Jul 20 '05 #6

P: n/a

"Lachlan Hunt" <la**********@lachy.id.au.update.virus.scanners> wrote in
message news:Hf*******************@news-server.bigpond.net.au...
Jukka K. Korpela wrote:
Lachlan Hunt <la**********@lachy.id.au.update.virus.scanners> wrote:
Joseph Haig wrote:
Specifically, I am using this for data taken from a database. <dt>
contains the field name and <dd> contains the information in that
field.

That fits the structure of a definition list just fine,
Not at all. ... For example, if the
name is "year", then the definition might be 'the year in which the book
was published', if the database is bibliographic.


Yes, that's one interpretation of a definition list.
The value of the field
could be "1952" or "2004" or something else; none of the values _defines_ what the field name _means_


True, but a definition list isn't strictly for defining the meaning
of a term like in a glossary or dictionary. In that example, the
definition list can be interpreted as defining the value for the property.


I agree with this.

Lets take a look at the example taken from the HTML 4.01 spec:
# Another application of DL, for example, is for marking up
# dialogues, with each DT naming a speaker, and each DD
# containing his or her words.


I have some hesitation about this. It would be fine if a list consists of a
set of distinct characters, each matched with a set of his well-known
catch-phrases:

Fonzie
Aaaaaaayyyyyyyy.
Arnold from Different Strokes
Whatchu talkin' 'bout, Willis?
Flip Wilson's Geraldine
The devil made me do it!
What you see is what you get! (Yes, this is where WYSIWYG comes
from.)
Whoooooo!!!
Chester Riley
What a revoltin' development this is!

But a script departs from this pattern in a couple of ways. First, it isn't
an association of *distinct* terms with their corresponding values, in the
way that a real definition list is. The same character appears on multiple
entries in the list. Second, it's limited to special cases, because the
general case of a script or dialog is not a uniform list of characters their
lines. In the general case, stage directions are interspersed, breaking up
the monolithic nature of the list. You could have a series DLs separated by
the stage directions, but that would be semantically dishonest, because the
set of lines that happens to be between two successive stage directions
might not be a single cohesive unit. I'm not sure what a *better* markup
would be in that case, but DL would be rather artificial for this purpose.

Jul 20 '05 #7

P: n/a
Lachlan Hunt <la**********@lachy.id.au.update.virus.scanners> wrote:
True, but a definition list isn't strictly for defining the
meaning of a term like in a glossary or dictionary.
Really?
In that example, the
definition list can be interpreted as defining the value for the
property.
But that's completely different; a <dl> element contains <dt> and <dd>
elements, and <dt> stands for definition term, and each <dd> supplies a
definition for some of the term. It's not about defining values of fields
but about defining meanings of terms.
Lets take a look at the example taken from the HTML 4.01 spec:
# Another application of DL, for example, is for marking up
# dialogues,
Which is just nonsense. A dialogue is not a definition list in _any_
sense. We have two options:
- We think that the W3C has no meaningful definition for what <dl>
means. Hence we should not use it all. (It does not really serve
in a useful way as a presentational trick, since CSS can do
such jobs much better.)
- We take the normative part, the definition, seriously - more seriously
than the specification itself - and ignore examples that do not fit
into that meaning.
<dt>Fred</dt>


Remember that <dt> comes from "definition term". Is "Fred" really a term
being defined?

If <dl> is not a list of definitions for terms, then what _is_ it?
Anything that someone wants to use to achieve a particular layout?
(Rather poorly, since the default rendering is not very good and the odds
of styling it are worse than the odds of styling e.g. a table.)
It's nonsensical to define an element in one particular way and then
start telling how it "can be used" for completely different meanings as
well.

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

Jul 20 '05 #8

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message news:<Xn*****************************@193.229.0.31 >...
- We think that the W3C has no meaningful definition for what <dl>
means. Hence we should not use it all.
This is a rather "dog in the manger" attitude. I could support it more
easily if HTML had semantics worth talking about. We all know the
"HTML = content, CSS = presentation" argument, but the sad fact is
that HTML just doesn't have the inherent detail to support this
(without bolting <span class="..." id="..." > everywhere)

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)
(It does not really serve
in a useful way as a presentational trick, since CSS can do
such jobs much better.)


I use <dl> a lot, and I use it whenever I need a list structure where
there's a substantial "two part" nature to each list element. I do the
rest with CSS, and if I wanted a numbered list I might even do that
with CSS. Marking-up dialogue (as the W3C suggest) works well with
<dl> and has a reasonable fall-back in the "lost CSS" case. Doing it
with <li> would involve rather too many <span>s and changing display
properties for my taste.
Jul 20 '05 #9

P: n/a
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)
I'd say <h2> is pretty clear: a second level heading, a sub-heading.
<address> is oddly named, but the semantics seem clear enough. "Who's
responsible for this page?"
I use <dl> a lot, and I use it whenever I need a list structure where
there's a substantial "two part" nature to each list element.
As do I. <dl> is most valuable for me as a way to structure groups,
where each group does not have the same number of items, e.g.,

menu item, price, description, (optional) additional combo price

A table could be used, with empty fields, but that's not the best in
terms of a data structure.
Marking-up dialogue (as the W3C suggest) works well with
<dl> and has a reasonable fall-back in the "lost CSS" case. Doing it
with <li> would involve rather too many <span>s and changing display
properties for my taste.


I agree, though using <dl> for these purposed -- or for mine -- is
dubious. In the end, I've unilatererally changed <dl> from defintion
list to general 2+ array list. 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.

--
Brian (remove ".invalid" to email me)
http://www.tsmchughs.com/
Jul 20 '05 #10

P: n/a
On Thu, 08 Jul 2004 10:42:18 -0400, Brian
<us*****@julietremblay.com.invalid> 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!
Jul 20 '05 #11

P: n/a
di*****@codesmiths.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

Jul 20 '05 #12

P: n/a
Brian <us*****@julietremblay.com.invalid> wrote in message news:<10*************@corp.supernews.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).
Jul 20 '05 #13

P: n/a
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**********@lachy.id.au.update.virus.scanners

Remove .update.virus.scanners to email me,
NO SPAM and NO VIRUSES!!!
Jul 20 '05 #14

P: n/a
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/
Jul 20 '05 #15

P: n/a
On Fri, 09 Jul 2004 08:54:58 -0400, Brian
<us*****@julietremblay.com.invalid> 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
Jul 20 '05 #16

P: n/a
di*****@codesmiths.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

Jul 20 '05 #17

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message news:<Xn*****************************@193.229.0.31 >...
di*****@codesmiths.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.
Jul 20 '05 #18

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.fi> wrote in message news:<Xn*****************************@193.229.0.31 >...
di*****@codesmiths.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.
Jul 20 '05 #19

P: n/a
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!
Jul 20 '05 #20

P: n/a
di*****@codesmiths.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

Jul 20 '05 #21

P: n/a
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/
Jul 20 '05 #22

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.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 "description 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.
Jul 20 '05 #23

P: n/a
di*****@codesmiths.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

Jul 20 '05 #24

P: n/a
On Tue, 13 Jul 2004 16:30:13 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.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><td /></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
unfortunately 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><blockquote> 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 "<blockquote> 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
"definitions"). 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
Jul 20 '05 #25

P: n/a
Andy Dingley <di*****@codesmiths.com> wrote:
On Tue, 13 Jul 2004 16:30:13 +0000 (UTC), "Jukka K. Korpela"
<jk******@cs.tut.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
"definitions"). 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

Jul 20 '05 #26

P: n/a
Tim
On Mon, 12 Jul 2004 15:18:01 +0000 (UTC),
"Jukka K. Korpela" <jk******@cs.tut.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.
Jul 20 '05 #27

P: n/a
Jukka K. Korpela wrote:
Andy Dingley <di*****@codesmiths.com> wrote:
"Jukka K. Korpela" <jk******@cs.tut.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/
Jul 20 '05 #28

P: n/a
"Jukka K. Korpela" <jk******@cs.tut.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 "lightweight" 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.
Jul 20 '05 #29

P: n/a
di*****@codesmiths.com (Andy Dingley) wrote:
"Jukka K. Korpela" <jk******@cs.tut.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 "generalised" 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 "harmonizing" 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

Jul 20 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.