Re: Tables in HTML+
montulli@stat1.cc.ukans.edu (Lou Montulli)
Errors-To: listmaster@www0.cern.ch
Date: Mon, 28 Feb 1994 21:08:54 --100
Message-id: <9402282004.AA40079@stat1.cc.ukans.edu>
Errors-To: listmaster@www0.cern.ch
Reply-To: montulli@stat1.cc.ukans.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: montulli@stat1.cc.ukans.edu (Lou Montulli)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Tables in HTML+
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2268
>
> >> I disagree. Why force users to enter unnecessary end tags when the content
> >> model is clear and unambigous! The DTD allows authors to omit end tags for
> >> the following elements:
>
> > Inferring where end tags should be is not hard in valid HTML. The problem
> > arises when trying to cope with invalid variations, that include things
> > such as <P> used as carriage return, free-floating LI. The <P> element is
> > the biggest problem, since its appearance is quite random.
>
> Please tell me more about why this is difficult.
>
> My parser treats a free-floating <LI> by ungetting this token and
> calling the routine to parse a UL with the "implied token" flag set
> to true, thereby setting the attributes for UL to their default values.
> A random <P> element terminates the current paragraph container and
> starts a new one, as you would expect. Note that the parser does treat
> <P> and <LI> as containers unlike HTML. Maybe you would find it easier
> if you made that transition.
>
<li> are a problem since it has no real meaning outside of a list
structure. I think they should just be ignored if there is no open
list structure.
<p>, on the other hand, does have some defacto meaning almost anywhere.
The current use of <p> (not the spec. definition) is to put two returns
in and stay in the current style. In other words <p> means two <br>'s.
Therefore if a <p> is encountered in a list then add two returns,
the same with headers, paragraphs, etc. This isn't all that hard to
parse. There is some confusion as to what to do with extra line breaks.
Xmosaic collapses extra vertical whitespace, while in Lynx I leave it
in so that the user can get vertical whitespace if they want it.
:lou
--
**************************************************************************
* T H E U N I V E R S I T Y O F K A N S A S *
* Lou MONTULLI @ Ukanaix.cc.ukans.edu *
* Kuhub.cc.ukans.edu ACS Computing Services *
* 913/864-0436 Ukanvax.bitnet Lawrence, KS 66044 *
* Let's face it, I'm a nerd, why else would I have a sig file? *
**************************************************************************