Re: Correct syntax of <LI> tags

Arjun Ray (aray@pipeline.com)
Wed, 21 Jun 1995 13:13:13 -0400 (EDT)


Date: Wed, 21 Jun 1995 13:13:13 -0400 (EDT)
From: Arjun Ray <aray@pipeline.com>
Subject: Re: Correct syntax of <LI> tags
To: Murray Maloney <murray@sco.com>
Cc: www-html@www10.w3.org, ccaamwd@ucl.ac.uk
In-Reply-To: <9506211217.aa10508@dali.scocan.sco.COM>
Message-Id: <Pine.3.89.9506211205.A21650-0100000@pipe3>



On Wed, 21 Jun 1995, Murray Maloney wrote:

> ccaamwd writes:
> > 
> > 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, 
> >[...]
> > Is the emacs mode right, [...]  or is the whitespace being correctly 
> > interpreted by Netscape [...]?
> 
> For what it's worth, my reading of the spec and 
> experience with browsers is that a space following
> an <LI> should be presented by the browser.  
>[...] 
> HTML as an SGML application
> should respect white space between the <LI> tag and subsequent
> text.  Multiple white spaces should be collapsed to a single
> space, but it should still be presented.

The SGML part of it would indicate only that the space is legitimate
character data. What the rendering engine does with it is independent
of that.

> 
> If you were to follow the <LI> with a newline, then you would
> get the browser behaviour that you are seeking.
> 

Semantically, <LI> implies a line-break. So the issue is really whether,
in free-form text, any leading whitespace should be presented over and
above any indentation levels and styles already in effect. As a matter
of presentation, probably not, IMHO.

Suppressing leading white space leads to consistent treatment of free-form
variations in the original markup, viz

...
<LI>Some text
...

versus

...
<LI>
Some text
...

As a side benefit(?), this also picks up any inadvertent trailing 
whitespace in the second variant, after the <LI> and before the newline...
After all, there's no harm in browsers ate least trying to pretty up
the presentation:)


Cheers,
ar