Re: lynx-dev lynx2.8.3dev.4 - --force-empty-hrefless-a

[Vlad Harchev]

On Sat, 17 Jul 1999, Klaus Weide wrote:

> On Fri, 16 Jul 1999, Vlad Harchev wrote:
> > On Thu, 15 Jul 1999, Klaus Weide wrote:
> > 
> > >[...] 
> > > And I currently don't have most recent lynx *with* lss...
> > > Your assumption is wrong, since those anchors aren't hightlighted
> > > in any special way - except when BOLD_NAME_ANCHORS is used (see correction
> > > below), which is just the case when --force-empty-hrefless-a does nothing!
> > > (via the me->inBoldA test).
> > 
> >  Seems that any lynx with lss is required  to see that effect - not the most
> > recent. 
> 
> You saw right through my excuse. :)
> 
> I will look at it; remind me if I seem to have forgotten.
> 
> > Tweaking BOLD_NAME_ANCHORS (setting it to T or F) won't cure that
> > effect on dev3,dev4 - seems that color read from .css file is emitted
> > regardless of that setting.
> > 
> >  Why don't you use lss-enabled lynx?
> 
> I use what I'm currently testing - which happens to be lynx with slang.
> Not enough space/time to always keep various versions.
> I don't have anything against lss-enabled lynx - after all I helped put
> it in the mainstream code and keep it alive.  But I don't *need* it;
> never put much work in customizing it for myself; and after all lynx
> without lss is still the 'normal case'.
> 
> Why don't *you* use lynx without lss, at least for testing?

 When not testing my patches, I use lss lynx. When testing patches, I use both
versions. It seems to me that .lss file I created (mild-colors.lss is very
close to what I use) is much better for (at least my) eyes (and I spend almost
50% of time reading various docs) than non-lss lynx can be configured for.
 
> [ snip ]
> > > Also the name is inconsistent with the usage in BOLD_NAME_ANCHORS:
> > > what's called a "name anchor" there you call an "hrefless a".
> > 
> >  This was the Fote terminology.
> 
> As used where?

 In the comment right above the block of code that is relevant to
--force-empty-hrefless-a.

> [ big snip ]
> > > The much better solution for recovering from this kind of mess would be
> > > to detect the invalid nesting at the SGML.c level, and close the A right
> > > there.
> > 
> >  This nesting can't be detected in a right way (I meant it can be detected,
> > but too late - when the screen will be ugly). So finishing the <a> as soon 
> > as
> > possible is the only solution (and it can't be done in SGML.c IMO or could
> > be done without introducing generic approach but using only A-specific 
> > code).
> 
> Why can't it be detected in a right way?
> 
> 'Finishing the <a>' in HTML.c is not _really_ finishing it, because it means
> that <A> is still open at the SGML.c level and sooner or later the </A> will
> come along.  (Except perhaps in TagSoup mode.)
> 
> It's the _job_ of the SGML.c level to provide element start/end events
> to the following HTML.c level in a usable way.  If it cannot do that
> job now for A with the generic approach, the generic approach has to
> be modified (A-specific code would be one way, not necessarily the
> best).
> 

 I meant the following: when using lss-enabled lynx (that emits color style
changes for each tag) there is no solution to the html broken in that way
(unterminated <a>) except provided by that patch (end current element
emitting backward style changes). And support for this can't be done in SGML.c,
since in that case it should know about attributes <a> can
have. 
  And leaving <a> on the parser's stack is not very bad - if the html is 
correct, then there is closing </a>, so SGML parser stack will be in
normal condition, if html is incorrect - yes, the SGML parser stack won't be
ok (as it would be without my patch, so my patch has no effects on SGML level)
- but this is broken html - so we have the rights to behave in some incorrect
way. NS and IE don't have our problem since they don't change the appearance
of pure anchors...
 And it seems to me that SET_SKIP_STACK logic is close (at least) to correct - 
I didn't look at it very close.
 And --force-empty-hrefless-a state is OFF by default, so people know what
they are doing when using it.
 I'm enabled --force-empty-hrefless-a logic yesterday in may lynx.cfg, and
seen no visual differences from the screens I'm used to (with html files that
are not broken in that respect except that pure anchors don't have color of
inactive link - so seems SET_SKIP_STACK behaves well).

> > > (Another solution is to say "this is so messed up, don't try to cover
> > > up for it.  After all the text is still there and readable.")
> > 
> >  I prefer to consider the -force-empty-hrefless-a to be another hack useful
> > for eveybody. And you will be responsible for it since it uses your
> > SET_SKIP_STACK hack :)
> 
> A hack doesn't become useful for X by your considering it so.  It's
> useful for X if X considers it useful.
  
  You didn't see that file without the --force-empty-* logic enabled with
lss-enabled lynx. *Almost entire* (possibly except top 3 lines) document has
color of the inactive link so it looks very ugly. I don't think that anybody 
viewing that document with lss-enabled will find it acceptable, so will
consider the functionality as 'usable'.

> What I'm responsible for is '#ifdef NOTUSED_FOTEMODS', i.e. commenting
> out the section in question (but keeping it around just in case).  And
> for providing (rather: keeping alive) a parsing mode in which A is
> treated as the non-empty element it is.  And for assorted hacks in
> HTML.c that try to make that mode work while still using 'recovery'
> code in HTML.c that was written for a different model (where A is
> treated as fake-empty).
>  I hope you're not saying that you are not interested in hearing
> about (actual or potential) problems with -force-empty-hrefless-a.

 I'm interested in hearing about problems with it (hope they'll never happen).

> > >[...]
> > > There are flags for what elements can close what kinds of elements,
> > > but they do not distinguish between detecting an error at a start tag
> > > and detecting an error at an end tag.  We don't allow an <H1> to close
> > > a still-open <A> to avoid generating a "hidden link" in some cases,
> > > but that also means that a </H1> cannot close an open <A>.  At that
> > > level we also don't keep track of which A's were hrefless.  But adding
> > > some more fine-grained control at the SGML.c level for when recovery
> > > can occur would be better IMO than mucking around in HTML.c for this.
> > 
> >  Yes, may be, but it requires time..
> 
> A bit, but in the longer term, probably less time than messing around
> in HTML.c.

 IMO hacking SGML.c doesn't worse support for -force-empty-* functionality,
but it may worse fixing parsing of files with messed <H1> and <A> mentioned
above. But I afraid I'll have no time to make such internal changes (I have
time to make short user-visible changes).
 As for more "fine-grained control" - do you mean another field in HTag
structure?

>    Klaus
> 

 Best regards,
  -Vlad