So, I’m spending part of my Friday at work like I usually do, working on prototype applications or product ideas I have. I’m working inside my XML Editor (OxygenXML 8) to validate my layout and I hit the pretty print button. All hell breaks loose with my layout. Firefox and Safari both render the layout exactly the same in the broken version, which told me that it probably wasn’t a “bug” but a misunderstanding of the spec on my part.

Here’s a sample of what happened. I went from this:

to this:

After several hours of close reading, double-checking everything, and generally pulling my hair out, I found out that the problem is that the XML editor turned an empty div in my code into an empty XML element. In other words, the only change to the source was from:

to this:

All of this stems from the fact that XHTML uses XML semantics without a real XML parser. The bottom line is that unless the element is defined in the XHTML DTD as EMPTY, you shouldn’t use the empty element notation. It’s better and correct to leave it as separate open and close tags. Many developers have run into similar issues with the script tag, which also has some weirdness when used in the empty element notation. This is why, apparently, browsers do this. I don’t know if they handle it well, though.

Continue reading if you want more information and some links on the background for this.
(Click here to read the rest of this post)

So, I noticed earlier today that none of my posts were showing up in Technorati. I’ve found that whenever this happens, and it happens relatively often, the problem stems from the HTML on this site not validating properly. Since I’m using XHTML 1.0 Strict, this means that anything the least bit unusual generally breaks the page.

I have a couple of custom fixes I’ve had to include to the WordPress installation which disappear every time I upgrade WordPress. I have to figure this out, by the way, because I can’t be the only one impacted by this, so I must be doing something wrong… or it’s one of my custom written plugins. Hmmm.

Anyway, I tried embedding the YouTube player today and that destroyed the page. First of all, the embed tag isn’t part of HTML or XHTML 1.0. So, I can’t include it in the post, which means I can’t let Firefox users see the player. So, I decided to use SWFObject, a JS-based flash embedder. It went downhill from here.

Between X-Valid and the default wpautop and wptexturize, the whole script tag was getting destroyed. The CDATA block was getting ripped out, the > in the CDATA close tag was getting converted to &gt;, and there were <p> tags everywhere.

Even disabling wpautop and wptexturize (via the TextControl plugin) and disabling X-Valid for that post didn’t help. Everything was fine except something kept killing the final > on the CDATA close tag, which is supposed to be ]]>. After worrying about it, then thinking that I need to make another patch to my wordpress install (noooooo!), I just gave up and removed the CDATA blocks and made sure my JS didn’t have any characters that would break validation.

This isn’t a workable solution, so I’ll have to look more. A quick google shows that it might be the rich editor, but I’ll have to look later. Holy crap, though, this is an insanely annoying bug.

Update: And my custom fixes have been removed. CDATA elements still break validation, but the other issue I mentioned where I had to have a custom patch is now resolved. Turns out it was this ancient (by Internet standards) tagging plugin I was using to display the tags on each post. I’ve switched to Christine Davis’s excellent Ultimate Tag Warrior plugin. This plugin should be held up as a poster child for well thought out plugins, at least from a user standpoint. It imported the tags from the old plugin and set them up. There was one problem with the + signs I used for multi-word tags, but a little SQL magic and we’re all set. Still looking for a fix for the CDATA issue, but that will have to wait. I need to get to bed so I can finish a spec tomorrow morning.