User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.9.3a5pre) Gecko/20100408 Minefield/3.7a5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100408 Minefield/3.7a5pre Just compere with html5 enabled and disabled. Also with html5 all links cant be clicked (except only this upper menu) and searchbar is rendered on wrong place Reproducible: Always Steps to Reproduce: 1. enable HTML5 (about:config => html5.enable=true) 2. go to http://www.gf-hunters.de/ Actual Results: Wrongly rendered site Expected Results: Properly rendered site with clickable working links

That pref just controls the parser; it has nothing to do with layout. Henri, can you please take a look? It looks like the relevant part of the markup is: <button type="submit" id="searchsubmit" value="" /> </form> which is an unclosed button; this causes all the rest of the web page to be inside the button with the HTML5 parser. I presume the </form> closes the button in the old parser?

This markup works in Safari and Opera too, so probably needs a spec change to support it.

Though I can't figure out _why_ it works in opera.... Maybe it lets links inside buttons be clickable? Certainly live dom viewer claims the links are inside the button.

Looks like <button> should not be a scoping element. I wonder why it is per spec. Furthermore, </form> should pop stuff more aggressively when the element pointed to by the form pointer is in scope.

(In reply to comment #4) > Looks like <button> should not be a scoping element. I wonder why it is per > spec. > > Furthermore, </form> should pop stuff more aggressively when the element > pointed to by the form pointer is in scope. It's sufficient to make <button> non-scoping. Changing how </form> is handled is not necessary. Filed a spec bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9496

The spec got changed: http://html5.org/tools/web-apps-tracker?from=5031&to=5032