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

[Vlad Harchev]

On Sat, 7 Aug 1999, Klaus Weide wrote:

> 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.

 As I said, they contain preformatted text wrapped in <PRE>, but that <PRE>
contains H[1-6]. In SortaSGML mode, lynx implicitly closes <PRE> as soon as it
sees H[1-6], so text after the H[1-6] is formatted by lynx. You can imagine
how it will look if it was a C source (properly converted to HTML by 
substituting angle brackets and ampersand to named entities), but formatted by
lynx. (I assume you don't need URLs of them now).

>[...] 
> 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).

 Seems implementing even such support should have very little priority.
 
>[...] 
> 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.

 Seems you are right.
 
> >  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

 Leonid said that Big Two behave that way in his original message (I guess he
meant that at least they don't close <PRE> implicitly). Rendering them as true
H* won't be harmful.

> 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
> 
 Since you don't object, here is a patch that will modify 'canclos'.

 Best regards,
  -Vlad

--- HTMLDTD.c~  Sun Aug  1 10:27:58 1999
+++ HTMLDTD.c   Thu Aug  5 20:32:30 1999
@@ -1212,17 +1212,17 @@
  /* { "FRAMESET", frameset_attr,HTML_FRAMESET_ATTRIBUTES, SGML_MIXED }, */
 #define T_FRAMESET     0x10000,0x90000,0x90000,0x90000,0x93000,0x9FFFF,0x00000
  /* { "H1"     , h_attr,       HTML_H_ATTRIBUTES,      SGML_MIXED }, */
-#define T_H1           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80317,0x00000
+#define T_H1           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80117,0x00000
  /* { "H2"     , h_attr,       HTML_H_ATTRIBUTES,      SGML_MIXED }, */
-#define T_H2           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80317,0x00000
+#define T_H2           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80117,0x00000
  /* { "H3"     , h_attr,       HTML_H_ATTRIBUTES,      SGML_MIXED }, */
-#define T_H3           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80317,0x00000
+#define T_H3           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80117,0x00000
  /* { "H4"     , h_attr,       HTML_H_ATTRIBUTES,      SGML_MIXED }, */
-#define T_H4           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80317,0x00000
+#define T_H4           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80117,0x00000
  /* { "H5"     , h_attr,       HTML_H_ATTRIBUTES,      SGML_MIXED }, */
-#define T_H5           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80317,0x00000
+#define T_H5           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80117,0x00000
  /* { "H6"     , h_attr,       HTML_H_ATTRIBUTES,      SGML_MIXED }, */
-#define T_H6           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80317,0x00000
+#define T_H6           0x0100, 0x0B04F,0x0B05F,0x36680,0x37FAF,0x80117,0x00000
  /* { "HEAD"   , gen_attr,     HTML_GEN_ATTRIBUTES,    SGML_MIXED }, */
 #define T_HEAD         0x40000,0x4F000,0x47000,0x10000,0x10000,0x9FF7F,0x00006
  /* { "HR"     , hr_attr,      HTML_HR_ATTRIBUTES,     SGML_EMPTY }, */