Re: lynx-dev strict SortaSGML rules for <PRE>...</PRE> content

[Klaus Weide]

On Thu, 5 Aug 1999, Vlad Harchev wrote:
> Those sites are completely unusable without this change in SortaSGML mode,
> not that they look slightly worse.

Since "those sites" figure heavily in your reasoning, you should give
some samples of that particular hall of shame.

>  I agree that approach of adding options for each small hack is slightly ugly
> (but this is called "true configurability"). I agree that DTD parsing would be
> better for this, but entire lynx should be rewritten (if DTD will specify
> attributes too, not only nesting details) if DTD support is implemented.
  [...]
>  As I said above, implementing complete DTD support is useless since lynx 
> uses 
> fixed integers to denote tags and their attributes.

We could read in a file with the tags_new information at runtime. Just
hex numbers (so it would look more ore less like what's in HTMLDTD.c)
or soemthing slightly more readable.  Our own mini-DTD format.  Either
for the whole tags_new[] or only to override specific elements.

I don't find the idea very attractive, but it is preferable to lots of
separate new command line flags (that is more than slightly ugly).

> >[...] 
> > As a more specific criticism, I feel that changing the 'contains' and
> > 'icontains' as you suggest - whether dynamically at runtime or fixed -
> > leads straight back to "TagSoup".  It is changing the info about tags
> > to not express their "real" content model, but something made up, in
> > order to achieve some specific error recovery behavior.  (More or less
> > the same as saying an element is empty when it isn't.  I invented
> > "SortaSGML" parsing to get rid of some of this [and therefore get rid
> > of the need to handle mis-ordered tags at the HTML.c level].)
> > 
> > Instead I would strongly prefer - as long as we are just thinking about
> > the "DTD" structures such as they are and not a fundamental redesign -
> > that 'contains', 'icontains', 'contained', and 'icontained' continue[*]
> > to reflect the "real", official DTD, and that changes in behavior are
> > done by changing only the 'behavioral' fields ('canclose', 'flags').
> > 
> > Coming back to the Hn vs. PRE case, the effect desired by Vlad for
> > <Hn> tags can be achieved by changing a bit in 'canclose' in each the
> > T_Hn macros.  It will also have an effect on <Hn>'s interaction with
> > some other tags though which may not be desirable (while Vlad's
> > approach has an effect on <PRE>'s interaction with some other tags
> > than <Hn> which may also not be desirable).
> 
>  Yes, changing 'canclose' could be a better idea for this case, but the
> tag class to which PRE belongs contains the following elts:
> ADDRESS, BANNER, BLOCKQUOTE, BQ, BUTTON, CENTER, DIV, FIELDSET, FIG, FN,
> NOTE, PRE
> 
> While Tgc_Plike contains
>  H[1-6],P, BDO, Caption ,Credit.
> 
> So, in this particular case changing 'contains' and 'icontains' seems to be
> less harmful.

Whether the change it is harmful or positive or neutral doesn't depend
on the number of elements but on what the effect actually is.
In general, if it makes sense to change what happens when X clashes with
Y, then it may also make sense to change the effect when X' and X''
(assumed to be similar in nature to X) clash with Y.

I this specific case, setting the flag in 'canclose' for <Hn> would not
directly affect any of the other tags in PRE's class, since they all
already allow <Hn> in their content.

>  And I think that this change should go to tags_new
> permamently and unconditionally - so no options should be introduced - 
> (and this will also be in tact with Big Two) - do you agree?

I don't agree or disagree that the change should go in.  I haven't
seen those sites, for one thing.  But I wouldn't object.  I think the
'canclose' part should be changed, not something else, there's no good
reason for changing anything else.  I agree that if the change is made
it should be unconditionally (i.e. not configurable) - unless you want
to implement a loadable sorta-DTD as outlined above. :)

About your phrase "in tact with Big Two" - first, that's not
automatically a desirable goal (unless perhaps if you enjoy chasing
their taillights all the time - what when they change their bad ways
in the next version).  Second, there's already a mode that's supposed
to come closer to their traditional treatment of HTML as a tag soup,
see also Larry's response.  Third, I don't know how they handle this,
do you or are you speculating?  Fourth, if they treat <Hn> within PRE
more or less as a <B> (or some other kind of font-like change) instead
of a block-like structure, then the lynx 'fix' doesn't come very close
to be in tact with that.  The rendering by lynx would still break the
preformatting when the rendering in those others doesn't, changes in
HTML.c (or some more nefarious trick) would be needed to change that
(compare special handling that is already under 'case HTML_Hn:' for
the case of <Hn> within lists).


   Klaus