1999102808 build. Load the cited url. Click down in the page whitespace a few times, or select some of it's text. The page contents move around the page when you do this (this is the bug). Maybe a page reflow problem.

I'm testing this with 1999102708 mozilla.exe & viewer.exe on Win98 The problem is not related to tables. The page starts with <a name="Top">, which isn't closed. While mozilla doesn't show the page as link, and it doesn't change the mouse cursor, when you click, everything turns into "active link" state. The shifting is caused by _images_ which normally doesn't have a border, but when clicking on the fake link they get one. (Look at the testcase.) Looks like a parser problem to me. Changing summary from "Springy tables"

I think there is a similiar problem with stories on the web site: www.smh.com.au. eg: http://www.smh.com.au/news/9910/30/pageone/pageone6.html

Another site with the same problem: http://www.afr.com.au/content/991030/world/world2.html

Here is the content-model: html refcount=3< head refcount=2< > body refcount=3< Text refcount=3<\n\n> a name=Top refcount=3< Text refcount=7<\n\nclick me!\n> img width=40 height=30 refcount=3<> Text refcount=3<\n\n\n\n> > > > Anchor tag can contain TEXT and IMG..and the model represents that. So, this cannot be a parser problem.

According the the HTML 4.0 spec, the end tag is *required* for <A> elements. See the first text after the attribute list at http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2 The HTML 3.2 spec is not so specific, but from the example given for <A NAME></A> it is clear that <A> has always been meant to be non-empty in all circumstances. Based on that, it looks like the bug is in the HTML, not in the browser. This one is going to crop up often, though. I've seen lots of HTML code like <A NAME="section1> <H2>Section 1</H2> ... to be used as a target for HREF="#section1" instead of the proper <H2><A NAME="section1>Section 1</A></H2> ... It seems that the parser is working properly for an unclosed <A NAME="Top>, so suggest changing Component from "Parser". Is this worth treating as a Nav Quirk (treating A element as empty iff the only attribute is NAME)?

Kipp, based on the content-model the problem appears to be layoutish.

Update your html.css and try again :-)

Kipp - your fix is the wrong fix. This is a dup of bug 12765 (and bug 12766 is very strongly related). Instead of a[href]:active { } ...you should say :link:active, :visited:active { } See the quoted bugs for details. I won't reopen since those other bugs are effectively covering this issue anyway.

Is there something wrong with the fix, or is it just not the optimal fix? Should I back it out?

Just sub-optimal. I wouldn't back it out unless you implement the fixes mentioned in bug 12765 and bug 12766. Having said that, doing those two fixes is easy. Replace all occurances of... with... a[href]:link :link a[href]:visited :visited a[href]:link img :link img a[href]:visited img :visited img a[href]:active :link:active, :visited:active a[href]:active img :link:active img, :visited:active img a[href]:hover :link:hover, :visited:hover a[href]:hover img :link:hover img, :visited:hover img a[href]:focus :link:focus, :visited:focus a[href]:focus img :link:focus img, :visited:focus img I'm not sure what the ":out-of-date" pseudo is, but similar things have to happen to that too. I'm sure Pierre would be very happy for you to make those changes... ;-)

It seems there is an additional issue beyond the scope of anything done to html.css - nesting of <A> elements is prohibited. "12.2.2 Nested links are illegal Links and anchors defined by the A element must not be nested; an A element must not contain any other A elements." <URL:http://www.w3.org/TR/REC-html40/struct/links.html#h-12.2.2> Taken together with the requirement for end tags for all <A> elements, this makes any page that starts with <A NAME="Top"> with no end </A> tag illegal HTML with a less-than-ideal content model. IMHO the fix applied here is a workaround, one that disguises the reality that such a page really *is* one big hyperlink, and has an unmatched element as the parent for everything else in the <body>. It *is* a bit of a tightrope to break the least existing pages while honouring the HTML 4.0 spec as much as possible. In this case a strict interpretation of the spec for the first <A NAME="whatever"> would leave the whole page as one big hyperlink, and guarantee that the DOM would contain illegally nested <A> elements. As far as I can tell, the existing fix also leaves the DOM with illegally nested <A> elements. I'm not sure that it wouldn't be better to, in cases where the page has anything "older" than the HTML 4 strict DTD as its DTD, explicitly treat <A> as empty if and only if its only attribute is NAME. This would better protect the integrity of the DOM and ensure that the widely-used idiom of <A NAME="sectionNN"> does not result in a DOM with NN unmatched, nested <A> elements. This would dishonour the absolute requirement for end tags for <A>, but it looks like the lesser of two evils - unless the best judgement is that HTML authors who wreak havoc on their pages' DOMs deserve what they get. Of course, making any element sometimes a container and sometimes empty does confuse things, and this may not be practical to do. On the other hand, I wouldn't want to try making sure that all legal DOM manipulations always work when a page's DOM contains multiple illegally nested unmatched <A> elements. If any of this raises a red flag, suggest REOPENing for further consideration.

sidr: In standard mode we automatically close the <a> tag (I think) when we come across the first invalid child (I think). In compatability mode, we allow the <a> tag to contain whatever. (This is the whole "residual style" thing.) We cannot know what the author expects -- after all, if he says: a[name] { color: blue; } and then includes: <a name=""> <table> ... ...he may well expect that the table be blue. (Who knows.) Since doing what you suggest involves changing our behaviour for non-standard documents, and we have no commitment supporting those, and the change that has been applied already fixes the problem, I would suggest that we just leave it as is and not waste engineer time over the issue. I would indeed say that "the best judgement is that HTML authors who wreak havoc on their pages' DOMs deserve what they get". Also, note that you say "In this case a strict interpretation of the spec for the first <A NAME="whatever"> would leave the whole page as one big hyperlink": this is untrue. The spec says that UA behaviour for invalid documents such as this one is entirely undefined. So we can do whatever we want, including generating a badly formed DOM, to doing what you suggest, to triggering the local coffee pot's "pour" command.

*** Bug 17216 has been marked as a duplicate of this bug. ***

*** Bug 17606 has been marked as a duplicate of this bug. ***

If the <A> is indeed implicitly closed when the first invalid child is parsed, then the whole issue of nested <A> elements goes away, and so does any need to address it further: it makes sense to let the existing fix stand.

Marking as verified fixed in the Nov 15th build.