Can we please avoid too tight a definition:
(from From: Dan Connolly Thu, 14 Jan 93 to www-talk)
> Can we do the following instead of using paragraphs in DL?
>
> <DL>
> <DT>large
> <DT>big
> <DD>Large and big are synonyms.
> <DD>They share a definition.
> <DD>This is the third paragraph of explanation about big
> and large things.
> </DL>
>
> It appears that the linemode browser generally groks. Thus, let's
> not mess with P's in DL's. (P's in UL's are messy enough to leave
> out too, I guess.)
I support:
o DD terms can include <P> breaks
o LI terms can include <P> breaks for UL and OL lists
The use of <P> in lists is both natural and easy to implement, and I for one
would find the repeated DD's awkward to deal with as well as screwing up the
natural semantics of a one to one relationship between DT and DD text.
o DT terms can be arbitrarily long and are wrapped onto the line below
This occasionally happens, e.g. when people place long anchors as DT terms.
It was also reasonably simple to implement.
It might be an improvement to emulate the approach used by Latex as in:
\begin{description}
\item[TERMS ARE IN A BIG FONT]
while their defintions follow in the normal font
and wrap round with a margin indent.
\end{description}
giving:
TERMS ARE IN A BIG FONT while their definitions follow in the normal font
and wrap round with a margin indent.
versus the HTML guidelines which suggest:
TERMS ARE IN A BIG FONT while their defintions follow in the normal
font and wrap round with a margin indent.
The Latex approach allows terms to be as long as you like, and avoids the
issue of what to do when terms collide with the definition text. Perhaps
the HTML guidelines should leave this issue open ...
I would further like to have the freedom to embed lists, e.g. OL in UL and
vice versa, but allowing only one level of embedding, e.g.
<UL>
<LI>This is a simple item.
<LI>While this one requires some amplification:
<OL>
<LI>first point
<LI>second point
<LI>third point
</OL>
<LI>Another simple item
</UL>
My implementation of lists is fairly relaxed whilst being able to support
smooth scrolling of arbitrary length HTML documents. The processing demands
for this require the browser to be able parse backwards - working forwards
from the start of the document each time is MUCH TOO SLOW. This is not a
problem unless there is an HTML feature which forces you to go back
arbitrarily far before you can figure out the state (margins, font, active
tags etc.) from which to work forwards again to your current location.
The awkward features turn out to be:
a) ordered lists
b) multi-line DT terms
In practice neither of these has caused real problems since actual documents
keep their use to relatively short sections at a time. A way out of my
problems would be to embed state info in the buffer as processing attributes,
so far I have been able to provide good scrolling performance while keeping to
the vanilla text representation of HTML docs.
Cheers for now (the Pub is bekoning)
Dave Raggett