Re: lynx-dev <p>...</p><pre>...</pre>

[kweide]

Laura Eaves wrote:
> I haven't looked at parser code lately, but as I remember
> tagsoup treats </p> as if it were <p> (see comment in SGML.c)

Yes.

> whereas the "sorta-SGML" parser treats </p> as a junk tag.

Yes and no...

When I made the change (for "SortaSGML") to *not* treat </p>
as a </P> any more, I added some handling code for it in
HTML_end_element() under 'case HTML_P:'.  Later (while I was
not looking :) ), that code seems to have been lost, when
the code was changed to put handling of P into the separate
function LYHandleP() - that function is now called for <p> and
</p> but does effectively nothing for </p>.

But even if that missing code were there, it wouldn't make a
difference, Lynx would be behaving in the given case as it does
now (and honestly I don't know whether there's a case where re-
instating the missing piece would make a difference - I would have
to look for a test case).

> I don't know which is right.
> Klaus would know how to fix the parser if it indeed is a bug.

What I consider a bug is mostly that in TagSoup mode, lynx is
displaying text differently (for completely valid documents) in
the presence of a explicit </p> from the case where the </p> is
implied.  But that was the traditional behavior of previous lynx
versions, so I left it allone for "TagSoup" parsing.  Handling
of </p> was the only case (that I am aware of) where switching
with ^V would make a difference for *correct* HTML.

As far as Karl's complaint for SortaSGML mode is concerned -
the behavior is controlled, again, by the file DefaultStyle.c.
Specifically, by the 'before' and 'after' numbers.
I expect, but haven't tested, that changing the 'before' for
the "Preformatted" style from 0 to 1 would give the behavior
he desires.  Changing the 'after' for the "Normal" style from
0 to 1 may have the same effect _in this case_, but that may
depend on the handling code that's gone missing, and it may
have other undesirable effects.

So my suggestion to whoever wants to change this: change the
number 'before' for "Preformatted" in DefaultStyles.c, and then
test whether that's really what you want and whether it doesn't
lead to an unwanted blank line in some other situation.

   Klaus