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.
Component: General → Layout: Block and Inline
Product: Firefox → Core
QA Contact: general → layout.block-and-inline
Version: unspecified → 1.9.2 Branch
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?
http://nemeseri.com/html5test/ with a <base href="..."> added
(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
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?
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
(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.
Component: Layout: Block and Inline → HTML: Parser
QA Contact: layout.block-and-inline → parser
[HTML5] in the bug summary is reserved for bugs caused by the HTML5 parser--not for bugs that it removes. :-)
Summary: [html5] Block level elements in <a> element causes not properly generated DOM tree and rendering quirks. → Block level elements in <a> element causes not properly generated DOM tree and rendering quirks.
You need to log in before you can comment on or make changes to this bug.