Re: Correct syntax of <LI> tags

Daniel W. Connolly ([email protected])
Wed, 21 Jun 1995 12:28:49 -0400


In message <[email protected]>, ccaamwd writes:
>Dear All,
>
>I hope someone out there can give me a definitive answer on this one:

The definitive answer is: strictly speaking, both netscape and Mosaic
comply with the HTML 2.0 spec on this issue. But Mosaic seems
to follow a suggestion in the spec that Netscape ignores...

>I use the emacs html-major-mode to edit html-2-compliant files.
>The emacs mode inserts a whitespace after every automatically generated
><LI> tag within a <UL> which, on most browsers, seems to be ignored.
>Only Netscape seem to attach significance to this,
> which makes the list display with an untidy ragged left edge,
>approximately thus:
>
>Mosaic and others:
>
>* Text.....
> continuing...
>
>Netscape:
>
>* Text...
> continuing...
>
>
>Is the emacs mode right, and Netscape should be ignoring something which it
>isn't, or is the whitespace being correctly interpreted by Netscape, in which
>case it simply shouldn't be there?

The relavent verbage in the spec is:

Hypertext Markup Language - 2.0 - Characters, Words, and Paragraphs
http://www.w3.org/hypertext/WWW/MarkUp/html-spec/html-spec_6.html#SEC63
Fri Jun 16 19:56:22 1995

|An HTML user agent should present the body of an HTML document as a
|collection of typeset paragraphs and preformatted text. Except for
|preformatted elements (PRE, XMP, LISTING, TEXTAREA), each block
|structuring element is regarded as a paragraph by taking the data
|characters in its content and the content of its descendant elements,
|concatenating them, and splitting the result into words, separated by
|space, tab, or record end characters (and perhaps hyphen
|characters). The sequence of words is typeset as a paragraph by
|breaking it into lines.

In other words, a paragraph is a sequence of words, and the amount
of whitespace before, after, or between the words _shouldn't_ matter.

I've had feedback that what's in the spec isn't quite clear enough.
The spec is otherwise solid enough that I'd like to let it become
an RFC as is. But if enough feedback comes in that I need to spin
another draft, I'll clarify this paragraph a bit.

Dan