524280 - Block level elements in <a> element causes not properly generated DOM tree and rendering quirks.

Status: RESOLVED INVALID

(Core :: DOM: HTML Parser, defect)

Description

[Andras Nemeseri]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b1) Gecko/20091019 Firefox/3.6b1

When you place any block level elements in an <a> element, you can experience rendering quirks. See the example in the URL above. The 4th list item is falling apart.

When you look at the markup, you can see, that every <a> element closed properly. When you open up firebug and look at the buggy <li> element, you can see that there is a lot of <a> elements in the generated DOM.

When you reload the page, the bug may go away. 

This bug is recognised by Eric Meyer too: 
“What I didn’t want, though, was the randomized layout weirdness that resulted once I started styling the descendants of the link. Sometimes everything would lay out properly, and other times the bits and pieces were all over the place. I could (randomly) flip back and forth between the two just by repeatedly hitting reload. I thought maybe it was the heading elements that were causing problems, so I converted them all to classed paragraphs. Nope, same problems. So I converted them all to classed spans and that solved the problem. The layout became steady and stable.”
Read the full article here: http://tinyurl.com/9lpup2

In the comments of the article, Philip Taylor points out, that the bug is related to the gecko "blocks-in-inline" rendering method: http://tinyurl.com/m3tgb8

Which is described by Ian Hixie here: http://tinyurl.com/yzfyvmx


Reproducible: Sometimes

Steps to Reproduce:
1. Wrap some block level elements in an <a> element.
2. Copy-paste the code sometimes.
3. You can see that sometimes the <a> elements in the generated DOM not properly closed (and there are extra <a> elements too). 
Actual Results:  
In the generated DOM the <a> elements are not closed properly, which causes some weird rendering quirks.

Expected Results:  
There is no extra <a> elements in the generated DOM.

Comment 1

[David Baron :dbaron:]

Does the "[html5]" in the bug's summary mean you have the html5.enable pref changed to true and you're using the HTML5 parser?  Or are you referring to the HTML5 spec in some way?

Comment 2

[David Baron :dbaron:]

Attachment: reporter's testcase

http://nemeseri.com/html5test/ with a <base href="..."> added

Comment 3

[David Baron :dbaron:]

(In reply to comment #0)
> Read the full article here: http://tinyurl.com/9lpup2

http://meyerweb.com/eric/thoughts/2009/01/02/an-event-apart-and-html-5/

> In the comments of the article, Philip Taylor points out, that the bug is
> related to the gecko "blocks-in-inline" rendering method:
> http://tinyurl.com/m3tgb8

http://meyerweb.com/eric/thoughts/2009/01/02/an-event-apart-and-html-5/#comment-457988

> Which is described by Ian Hixie here: http://tinyurl.com/yzfyvmx

http://ln.hixie.ch/?start=1138169545&count=1

Comment 4

[Andras Nemeseri]

I didn't turn on the html5 parser. When I turn it on, the bug goes away.
I'm sorry about it.
BTW when will you turn the HTML5 parser on by defult?

Comment 5

[David Baron :dbaron:]

(In reply to comment #4)
> I didn't turn on the html5 parser. When I turn it on, the bug goes away.
> I'm sorry about it.
> BTW when will you turn the HTML5 parser on by defult?

I'm not sure; however, we're unlikely to do significant work on the current parser since essentially all development effort on parsing is going into the HTML5 parser.


I'm not sure that INVALID is the right resolution, though... but it probably doesn't really matter.

Comment 6

[Henri Sivonen (:hsivonen)]

[HTML5] in the bug summary is reserved for bugs caused by the HTML5 parser--not for bugs that it removes. :-)