Although I'm not quite sure why yet, I changed the doctype of this template from XHTML 1.0 to XHTML 1.1 and am sending a Content-type: application/xhtml+xml
header to browsers that support it, meaning Mozilla will regard each page as xml and won't show the content if there's an error in the markup.
Which meant spending a couple of hours going through the monthly archives, correcting each entry that triggered an xml parse error. Now all of the 2300+ entries are valid well-formed x(h)tml and I have learned to never ever not end my &'s in amp; or use < instead of < in javascript: hrefs (damn those bookmarklet for-loops).
Remaining Javascript-weirdness resulting from the switch:
document.write
(which I use to generate spam-safe mailto: links) no longer works, I'll have to use a more DOMmy method (explained here);- The 'hide searches' link above the Referrers disappears after the first click, something to do with my use of innerHTML no doubt.
.firstChild.nodeValue
instead of .innerHTML
to make the link text change.
Update 2:
My new method of generating mailto: links is as follows: I write out email addresses in this form
<span class="mailto">domain,account,name</span>
which is converted to
<a href="mailto:account@domain">name</a>
by the following function:
function setMailtoLinks() { if (!document.getElementsByTagName) { return; } ar_spans = document.getElementsByTagName('span'); for (i=0; i<ar_spans.length; i++) { if (ar_spans[i].className == 'mailto') { ex = ar_spans[i].firstChild.nodeValue.split(','); tmp = document.createElement('a'); tmp.href = 'mailto:' + ex[1] + '@' + ex[0]; tmp.appendChild(document.createTextNode(ex[2] ? ex[2] : ex[1] + '@' + ex[0])); ar_spans[i].replaceChild(tmp, ar_spans[i].firstChild); } } }
I haven't had any problems since I switched. I don't think the 'fear' of checking every page should stand in the way of changing you content-header.
Dikke pluim in je reet, dat jij daar wel zin in had!
Anyway, it's fixed now.