lynx-dev
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]