Re: LYNX-DEV Lynx changed handling of TABLEs

[Klaus Weide]

On Sat, 15 Nov 1997, Alan J. Flavell wrote:

> On Sat, 15 Nov 1997, Foteos Macrides wrote:
> 
> > >A consequence is that a long-standing trick, TABLE in PRE, no longer
> > >works (nor does PRE in TABLE).
> > 
> >     You are confusing two different sets of changes in the
> > development code.  
> 
> Ah, thanks for clearing that up.
> 
> > It uses a SortaSGML parser by default, and
> > both of your HTML kludges are invalid, so its SGML-like error
> > recovery prevents either from working. 

This is true for the PRE-in-TABLE kludge.

For the TABLE-in-PRE kludge, the SortaSGML parsing doesn't really close
the enclosing PRE when it encounters the TABLE; it complains with a
message if TRACE is on, but then passes the <TABLE> on to the HTML.c
processing stage anyway (it's really only "Sorta").  The changes that
prevented the TABLE-in-PRE from working were the same changes in that
later stage as in Fote's code, the ones described by the 1997-05-21
message and FOTEMODS/CHANGES.new entry.

> Fair comment.  One really isn't entitled to expect anything, if one
> writes invalid HTML.
>
> Maybe I'll take up stuffing with no-break spaces, after all.

(...and make the HTML look as ugly as Netscape's mail attachments...)

> (Again there's no guarantee that multiple no-break spaces don't
> get collapsed, but at least it's not invalid HTML syntax).
> >  The mods I made last
> > May retained support for the PRE-in-TABLE kludge.  You can check
> > that with the development code by using ^V to toggle to the
> > TagSoup parser. 
> 
> Ah, right.  As you say, it works with PRE inside TABLE (as long as
> "tagsoup" parsing is enabled), though it no longer works with TABLE inside
> PRE - both of which "worked" (I hesitate to use that term in relation to
> invalid syntax, so let's just say "produced the hoped-for result") in Lynx
> 2.7 and earlier.
> 
> > I don't know why both that and the TABLE-in-PRE
> > kludge are needed,
> 
> Either one would suffice; I chose one over the other after lots
> of tests with browsers that are, presumably, all dead by now.
> It's in my writeup from way-back, anyhow.

Personally I find the PRE-in-TABLE kludge "uglier" than the
TABLE-in-PRE kludge.  Maybe that's not based on good reasons, but it
seems better to kludge around outside of the TABLE's structure than
within it, given that TABLEs have a rather strict structure (no mixed
content, only specific elements allowed) and can give strange effects
in various implementations if not treated the right way.

> > but it's easy enough to support both with the
> > TagSoup parser, so I did that in the lynx271f code for SSL.

Those changes, to re-enable the TABLE-in-PRE kludge, can be directly
applied to the devel code, with the same effect _as far as I have seen_.
So they'll be in the development code.

But note that this doesn't completely restore the 2.7.1 (or earlier)
behavior, at least for the following: if the whole construct is enclosed
in a DIV ALIGN=CENTER or CENTER, that centering will apply; and if the
TR elements have ALIGN=CENTER attributes, the centering will also apply.
That means lines will be centered individually, probably not the desired
effect although it may not hurt in some cases. This can be seen in
<URL:http://www.forwiss.uni-passau.de/~ramsch/> and
<URL:http://ppewww.ph.gla.ac.uk/~flavell/hours.html>, respectively.

> Many thanks. I think that's cleared it up.

I hope it's cleared up even more now...

    Klaus
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;