[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lynx-dev] [Minor suggestion] Lynx should handle link elements conta
Re: [Lynx-dev] [Minor suggestion] Lynx should handle link elements containing any block elements
Tue, 15 May 2007 07:06:25 -0400
On Tue, May 15, 2007 at 09:57:14AM +0200, Mathieu Bonnet wrote:
> > It seems to work if you turn on tagsoup mode, e.g., control/V
> > (for the rest, I'll have to see if it's a bug-fix or a workaround ;-)
> It does, indeed... :) I don't know Lynx much, sorry for this.
no problem (I didn't think of it at first, but seeing that the reason
for the broken anchor was interference by div, thought it might work)
> As `<a href="#"><p>Foo</p></a>` works, however, there should not be
> any "philosophical" problem to support <div> too, in the normal mode,
I agree with that (generally - I hadn't paid much attention to that
aspect, but didn't _see_ anything in a quick reread last night of
the HTML spec that prohibited that interpretation).
> and others, if needed (I surely don't like the idea, but Lynx is often
> used by people who might not be able to use another browser, at least
> at some specific time, so it should be more "flexible", by default, to
> avoid problems with broken websites -although broken websites might
> alternative, but this is another problem).
> `<ul><a href="#"><li>Foo</li></a></ul>` does not work either, in the
> normal mode, but works in the TagSoup mode.
> Couldn't the TagSoup mode be automatically activated (with a proper
> notice to the user, in case a webmaster is testing his website with
> Lynx), if the code is incorrect (like a block element, in an inline
> element, here), and, as such, might very possibly need the TagSoup
> mode, to be completely interpreted? (or interpreted as much as
I suppose it _could_ - but the code's already very complicated (adding
a check like that sounds as if it would be a lot more complicated).
It's not been a recent topic of discussion, but several people on this
mailing list certainly recall that the choice between strict and tagsoup
got a lot of discussion.
> Also, while the website I encountered used the XHTML 1.0 Strict doctype,
> I tested without any doctype or header, and the TagSoup mode is not
> activated, automatically, either (while it probably should, without
> even testing if the document seems otherwise "valid").
That's an idea (a configuration option that would make tagsoup set for pages
that have - or lack - a given doctype).
Thomas E. Dickey