Thank you!
And thanks for the tip, I will try it out!

Yes, I was hoping for some consistent solution and something that is valid.

Great filing the bug, as soon as this can be sorted out, the better! I saw his comment about the parser, but my hope is that it is sorted/enabled by Firefox 3.6. Otherwise, well, I guess just using lots of links as we did before is the option for now, unfortunately.

And you’re not robbing my time; on the contrary! Great input, and I really appreciate your efforts!

It’s a bit dissapointing for me, that it’s not turned on by default even in the nightlies. Based on this, I think I won’t use HTML5 for any projects.

Robert, I hope, that I didn’t robbed your time too much. Thank you for your answers.

Ian Hixie has a great explanation whats going on (http://tinyurl.com/yfyrtgv). It’s quite complicated to describe it here.

You can avoid this behavior if you wrap the block elements inside an extra <span> element:
<a href=”"><span> …. </span></a>

But note, that this is invalid in HTML5. So i don’t know any good solution now.

Because I didn’t find any bug related to this issue in the firefox bugzilla, I have filled one. Maybe we will get more information about it there:
https://bugzilla.mozilla.org/show_bug.cgi?id=524280

Great, thank you for the example! Very interesting to see it in action, and to be able to look at generated code myself.

Have you found any logic to when it breaks, and possible approaches to avoid having it break in Firefox?

So:
“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.”

I have set up a simple test page:
http://nemeseri.com/html5test/

You can see that the 4th list item falling apart in firefox (tested up to 3.6b1 canidate).

When you look at the markup, you can see, that every element closed properly.

When you open up firebug and look at the buggy element, you can see that there is a lot of elements in the generated DOM.

When you reload the page, the bug may go away. This is because it depends on the TCP/IP package borders. As mentioned by Philip Taylor ( http://tinyurl.com/m3tgb8 ), and examined by Ian Hixie ( http://tinyurl.com/yfyrtgv ).

Yes, and I replied to that on Twitter (not sure if you saw that), that that’s very unfortunate. Personally, though, I haven’t stumbled across such problems, but I would love to see a good example page to see what one should refrain from using.

Start here:
http://tinyurl.com/9lpup2
http://tinyurl.com/m3tgb8
http://tinyurl.com/yzfyvmx

Eric Meyer:
“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.”

“So it’s a bit late now, but I believe this is caused by an issue in Firefox where the parsing of blocks-in-inlines is dependent on TCP/IP packet boundaries (which is why it changes on reloads).” by Philip Taylor.

I will setup a test page shortly.

That’s a great comment!
We should not confuse our preferred style with what how it is actually rendered in a web browser – just do “View partial source” in a web browser, and you will see very varying results of how they actually interpret it.

Coding standards are great, but I would also really like to see the validator, in the future, offer at least a few more options in how strict it should validate.

The renderer doesn’t care as long as you don’t stray outside the spec, so the end result will look exactly the same regardless of which style you choose.

If the renderer behaves exactly the same either way it boils down to what looks prettiest when you view the source, which really doesn’t matter as far as the standard is concerned.

If prettiness and consistency is paramount to you or your organization, you can always formulate a coding standard for the HTML you produce. This is common in programming in order to help consistency and legibility, see the PEAR coding standard for an example. There are tools that validate PHP code against the PEAR coding standard, and similar tools could be created for a stricter HTML standard, e.g. “HTML5 Soup Nazi Strict”.