Firefox rendering gone WRONG - see something really weird

I have the following is really weird. Bassically when I view the source of the page everything looks fine but the page looks all wrong. So I decided to take a look at the source using firebug and firebug shows a very different story. But if I refresh the page the page looks fine and the source and firebug match up.

See below for what the source is but what firefox displays and firebug shows:

View source shows this:

<div class="mainpanel">  
    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Little-Rock"> 
        <div class="thumbphotoimage"><table cellpadding="0" cellspacing="0"><tr><td><img src="/Assets/Photos/Portfolio/BB001D_0.jpg" alt="Little Rock" /></td></tr></table></div>
        <div class="thumbphototitle">Little Rock</div> 
    </a>  
    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Split-Rock"> 
        <div class="thumbphotoimage"><table cellpadding="0" cellspacing="0"><tr><td><img src="/Assets/Photos/Portfolio/BB002D_0.jpg" alt="Split Rock" /></td></tr></table></div>
        <div class="thumbphototitle">Split Rock</div>
    </a>  
    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Rock-Pointer"> 
        <div class="thumbphotoimage"><table cellpadding="0" cellspacing="0"><tr><td><img src="/Assets/Photos/Portfolio/BB003D_0.jpg" alt="Rock Pointer" /></td></tr></table></div>
        <div class="thumbphototitle">Rock Pointer</div>
    </a>   
</div> 

But firebug shows this and it renders on the screen as if its like this:

<div class="mainpanel">  
    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Little-Rock"> 
        <div class="thumbphotoimage"><table cellpadding="0" cellspacing="0"><tr><td><img src="/Assets/Photos/Portfolio/BB001D_0.jpg" alt="Little Rock" /></td></tr></table></div>
        <div class="thumbphototitle">Little Rock</div> 
    </a>  

    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Split-Rock"></a> 
    <div class="thumbphotoimage"><table cellpadding="0" cellspacing="0"><tr><td><img src="/Assets/Photos/Portfolio/BB002D_0.jpg" alt="Split Rock" /></td></tr></table></div>
    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Split-Rock"> </a> 
    <div class="thumbphototitle">
        <a class="thumbphoto" onclick="window.location=this.href;return fa开发者_Python百科lse;" href="/Photograph/Narooma/Split-Rock">Split Rock</a>
    </div> 
    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Split-Rock"> </a> 

    <a class="thumbphoto" onclick="window.location=this.href;return false;" href="/Photograph/Narooma/Rock-Pointer"> 
        <div class="thumbphotoimage"><table cellpadding="0" cellspacing="0"><tr><td><img src="/Assets/Photos/Portfolio/BB003D_0.jpg" alt="Rock Pointer" /></td></tr></table></div>
        <div class="thumbphototitle">Rock Pointer</div>
    </a>   
</div>

The offending html is the middle a tag which goes crazy...

Any ideas.

Cheers Anthony

Like others said, this happens because your markup is invalid. Going a bit deeper, the problem is that when the parser received <a><div> in its input, it may mean two things:

1. You forgot to close the anchor tag, in which case this should become <a></a><div>... in the DOM, or
2. The anchor wraps the div, in which case the DOM should be <a><div></div></a>.

The correct decision can be made only when more (potentially much more) characters are known; the parsing, as you could have noticed, happens incrementally -- i.e. you can see parts of the page before it's fully downloaded.

Unfortunately, the Mozilla's HTML parser (as of Firefox 3.6 and earlier) is non-deterministic in this case -- the resulting DOM depends on the portions your HTML is split into, while going over network.

There's a Mozilla bug about a problem that looks very similar to yours.

I'm sorry for you, and I don't know how to implement (nor have any desire to try implementing ;) the solution to your original problem, but perhaps a hack involving setting innerHTML (to avoid parser non-determinism) is in order?

BTW, it would be interesting to check how the HTML5 parsing algorithm says your markup should be treated, since that's what will eventually be implemented in the browsers.

You should not wrap block elements/tags (like <div>) in inline tags (like <a>). That's asking for trouble.

That's because your HTML is invalid. Inline elements can only contain other inline elements and cannot contain block elements.

Browsers encountering HTML which breaks this rule is allowed to do anything at all in order to parse the page (including not displaying the page) and apparently firefox's interpretation of anything-at-all is not the same as yours.

Note that you can convert inline elements like <span> to a block element by setting it's display css property. But I'm not entirely sure if that is legal for an element with additional semantics such as an <a> tag. Of course, you could convert those divs to inline elements.

I don't want to stop putting block elements inside anchors. It's just too useful: http://html5doctor.com/block-level-links-in-html-5/

I developed a workaround which seems to disable progressive rendering and avoid this problem.

I use server-side sniffing to look for "Firefox/3" in the user-agent. If found, I put this right after <body>:

<script type="text/javascript">
      // hack for firefox 3.x progressive rendering pessimism
      document.body.style.display = 'none';
</script>

And this right before </body>:

<script type="text/javascript">
      document.body.style.display = 'block';
</script>

In testing, I found that simply inserting an empty <script> tag after the body tag avoided the issue I was experiencing. But it feels more correct and safer doing a show/hide.

Hard to know for sure what FF is really thinking - I'm curious to know whether this solves the problem for others.

I'm used to doing this sort of thing for IE. FF3.x is vying for my new least-favorite browser award.