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

[Klaus Weide]

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?

[ 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?

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

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

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.

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

   Klaus