[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev non-bug in non-comments (was bug in comments process)
From: |
Klaus Weide |
Subject: |
Re: lynx-dev non-bug in non-comments (was bug in comments process) |
Date: |
Tue, 3 Aug 1999 06:15:45 -0500 (CDT) |
On Sun, 1 Aug 1999, Vlad Harchev wrote:
> On Sat, 31 Jul 1999, Klaus Weide wrote:
>
> >[...]
> > No, I don't know what IE does, it doesn't really matter.
> >[...]
> >
> > Since you are speculating, let me speculate, too: IE does not do [...]
>
> So, did you try it with IE or not?
The first quoted sentence, together with the word 'speculate' in the
second, was supposed to tell you that I didn't.
> >[...]
>
> Let it be what you say - less TODO items... I'll fix psrc mode soon.
As a somewhat related topic:
While the 'SGML_LITTERAL' treatment is right for SCRIPT and STYLE, lynx
also parses some other elements' contents this way, and for those it
is not always appropriate. Take as example TEXTAREA: its content model
is
<!ELEMENT TEXTAREA - - (#PCDATA) -- multi-line text field -->
which means that SGML comments are valid between <TEXTAREA> and
</TEXTAREA> and should be treated as such; but that is not what lynx
does (try it). This should be fixed... it's not trivial since
textarea content is treated in a special way in HTML.c, there are
issues with chartrans among other things if SGML.c would pass the
TEXTAREA content to HTML.c in a different way than now.
The best way I can think of to fix this (without changing too much)
involves introducing YA state in the SGML.c machine and treating
SGML_PCDATA differently from SGML_MIXED and from SGML_LITTERAL
(and then treating TEXTAREA as SGML_PCDATA).
Another case is OBJECT; here the SGML_LITTERAL treatment may actually
be the most appropriate (although it's not what the spec says), given
that HTML.c does some unusual things with it (passing contents back to
SGML. in *include chunk for re-parsing). (And there is yet another
open problem which became apparent with OBJECT_MAP, but that's not
strictly related.)
Klaus