A peculiar thing happening in Firefox

[httpwebwitch]

I have some HTML being rendered on my page.

This is how it is supposed to look (greatly simplified):

<div id="block"> 
 <a> 
  <div><img/></div>  
  <div>.</div> 
  <div>.<i>.</i></div> 
 </a> 
 <a> 
  <div><img/></div> 
  <div>.</div> 
  <div>.<i>.</i></div> 
 </a> 
 <a> 
  <div><img/></div> 
  <div>.</div> 
  <div>.<i>.</i></div> 
 </a> 
 <a> 
  <div><img/></div> 
  <div>.</div> 
  <div>.<i>.</i></div> 
 </a> 
</div> 

And... most of the time when I load my page, that's what I see in the DOM.

But then sometimes - maybe once every 4 or 5 refreshes, I see the DOM messed up:

<div id="block"> 
 <a> 
  <div><img/></div> 
  <div>.</div> 
  <div>.<i>.</i></div> 
 </a> 
 <a> 
  <div><img/></div> 
  <div>.</div> 
  <div>.<i>.</i></div> 
 </a>
 <a></a> 
 <div><a><img/></a></div> 
 <div><a>.</a></div> 
 <div><a>.<i>.</i></a></div> 
 <a> 
  <div><img/></div> 
  <div.</div> 
  <div>.<i>.</i></div> 
 </a> 
</div>

(weird part in red)

See how the <a> node has been broken, and its children are being positioned as siblings, and there's an extra <a> wrapped around the contents of each.

What might cause this?
Is Firefox rebelling because I put block elements inside an inline element?

[httpwebwitch]

pls ignore the syntax typos in the example

all my tags are closed and formed properly. But sometimes... the browser moves those DOM nodes around as illustrated.

I suppose I should check whether it's the browser, or whether a raw HTTP GET shows the same weird DOM mixups

[httpwebwitch]

OK I checked. The response of the GET request is perfectly structured, like the top example. Each <a> node is an identical structure of HTML content, which they should be since they're created using a loop in PHP!

But when the DOM is rendered in the browser, it is messed up as illustrated. I view the DOM in Firebug, and the nodes are nested wrong, and on the page it looks terrible.

Something (a bug?) causes FireFox to mess up the DOM structure when the HTML is parsed.

I've looked at the raw source dozens of times. The HTML is well-formed, there are no naughty attributes, the content is not suspicious in any way.

Yet this problem happens - not every time - but with enough regularity that it's rather troublesome.

[httpwebwitch]

I have a feeling it's because of the block elements (<div>) inside the inline element (<a>). I know that's naughty, invalid, so perhaps I should fix that first and see if the problem goes away.

That and I should be sent back to HTML school with a slap on the wrist

[httpwebwitch]

that worked. I changed the <a> into a <div> and added clickability with a JavaScript onclick event and a CSS cursor.

I haven't seen that symptom come back, the page is rendering properly every time now.

By the way, my DOCTYPE is strict all the way.

[tedster]

Thanks for the narrative. Your episode proves that the DOM is pretty important for JavaScript, I'd say.

[penders]

The HTML is well-formed, there are no naughty attributes, the content is not suspicious in any way.

But it was invalid?! Like you say, and from your example, block-level elements inside inline elements.

Different browsers render their own interpretation of invalid markup. If the markup is invalid then there is no correct or wrong way to render it since there is no specification to follow. When you 'view source' in these browsers (I forget which browsers exactly, may be Firefox does this now as well - I've certainly noticed this with Chrome and Opera) you are seeing the browsers 'interpretation' of the page, not the actual page as sent from the server. You can see where the browser has closed any open tags or corrected incorrect nesting etc. (The browsers do 'correct' these things differently!) However, if the HTML is valid to begin with then there should be no change.

Not sure why you were only seeing this difference "once every 4 or 5 refreshes", the browsers should at least be consistent in this respect.

[httpwebwitch]

Yeah, the inconsistency was the odd part for sure. I'd guess 80% of the time the page looked fine, 20% of refreshes had that weird bit in the DOM where the nodes were exploded out.

I have this little nagging suspicion that the issue may have had something to do with packet sizes. Maybe that glitchy bit occurred at a border between HTTP chunks? It wouldn't be the first time that's been a factor in odd rendering in Firefox, though examples are rare (I know it's happened before, though I'm challenged to remember specifics).

The HTML was *well-formed* - but invalid. No tags to close or pieces missing. Just that block-inside-inline faux pas, which seems innocent, or at least it isn't the worst HTML sin you can commit!

Lesson from this parable is that the DOM is not the same as the Source. Source is what the server sends in response to a request. DOM is the browser's interpretation of that. There are times when looking at the source will reveal nothing, but a good DOM viewer (all the latest browsers have them) will show what the browser *really* thinks.

Some rendering oddities, I could understand. Like, if I put a <textarea> inside a <select> or something like that. This was some <div>s inside a <a>, because I wanted the whole rectangle to be naturally clickable with an href.

Always learning...

[penders]

Yeah, I think whacking an anchor round a block of content to make it clickable is a common make-do - there needs to be a block anchor (is there with HTML 5?). Recently dealt with a page that had loads of DIVs inside SPANs - some browsers chose to close the SPAN before the opening DIV, others didn't - and this was evident from the view source option in the browser.

[httpwebwitch]

some browsers chose to close the SPAN before the opening DIV

Very same symptom as above, then. The <a> gets closed before the <div>, thus the <div> becomes a sibling, not a child. The repetition of the <a> inside the <div> smells like a workaround that Mozilla created to enforce validity, while retaining functionality. Even though it royally messes up someone's CSS.

Seems that this "no blocks inside an inline" is a more critical rule than I previously thought. I mean, valid HTML is a good thing, but this is harsh. Then again, I do employ a STRICT DOCTYPE, so I ought to expect strictness.

I wonder whether this:

<i><blockquote>lorem ipsum</blockquote></i>

would be turned into this:

<i></i>
<blockquote><i>lorem ipsum</i></blockquote>

... 20% of the time. !

I grieve users who have JavaScript disabled, since I'm using JS to apply the "onclick" event handler that makes the <div> clickable.

<sigh>

[penders]

Yes, it does hammer home the concept of invalid markup == cross browser/future headache. Browsers have problems enough keeping up with the standards without having to deal gracefully with markup that clearly breaks the standards.

However, the browsers behaviour should at least be consistent - 100% of the time?! It is after all a machine.

I grieve users who have JavaScript disabled, since I'm using JS to apply the "onclick" event handler...

You could provide a conventional anchor inside your DIV for the few who are without JS (you could even hide this with JS) - and for the benefit of the search engines....?

[httpwebwitch]

You could provide a conventional anchor inside your DIV

ah, yes good point. I should do that right away.
thanks penders, you're top shelf