Why Are Plugins and Tools Making My Code Invalid?

W3C LogoI’ve mentioned a few times over the last couple of weeks that I’m currently working on a new design for this blog. I’ve now stumbled into a problem, one that will be difficult to overcome. The problem at hand is to do with code validity. I won’t bother going into the pros and cons of valid code here, I’ll save that for another post, but suffice to say, I want to be valid. And not just valid, I always set out to write XHTML 1.1 strict code. Once again, the benefits of doing this are out of the scope of this article, but I think it’s important enough to expend some effort in trying to achieve valid XHTML 1.1 code.

Because I knew this was my aim right from the very start, I planned for it. Every element was structured semantically and hierarchically. So by the time I reached the first draft of the theme, it was completely valid. Both in XHTML 1.1 and CSS. And it remained that way until I started to activate the plugins currently used on the blog. As soon as I had done this I continued to tweak the design so they fitted in and looked part of the site and not what they were, third party tools that had just been plugged in. Designing is always an iterative process, so this went through a number of iterations, with the design changing with each. At the end, when I was reasonably happy, I went about validating the code again, confident that I had not made any changes that would lead to invalid code.

How wrong I was.

I went from having valid XHTML and CSS to both being invalid. That’s right, something in there had actually caused the CSS to invalidate, something which is actually quite difficult to do. Now I don’t want to sound like I’m just moaning, so let’s look at what’s causing this invalidity, and how that can correct it.

CSS

Fortunately, but not unsurprisingly, there was only one aspect of CSS that caused validation to fail. Surprisingly, it actually comes from Google and one of the Adsense units. The specific line causing the problems is this:

.ch{cursor:pointer; cursor:hand;}.textcolor{color: #ffffff }

So that’s google trying to assign two different cursor values to the same class. I suspect this is because I’m using two different types of adsense units, so the loaded styles are conflicting. It may also be that I’m using one newly generated Adsense unit and at least one old one. Google could quite easily fix this, the real fix would be to use real hyperlinks in their ad links so they didn’t need to selectively style the cursor. Poor show, Google.

XHTML

XHTML, and I’m sure most of you already realise this, can be difficult. Just one slip-up can lead to literally 100s of validation errors. So when i checked and only came across 6 errors, two of which were clearly down to poorly formed test data, it didn’t seem that bad. That doesn’t change the fact that none of these errors are down to the theme, they were all down to plugins. Unfortunately, upon investigation, it appears that all four errors are down to a single plugin. Just one.

The plugin in question is from addthis.com, they provide links to many of the most popular social bookmarking and news sites. You can see their button at the bottom of every post. It’s a very popular plugin that you’ll find on many websites and blogs. This single plugin has, in no particular order, a link with a target attribute (x2), inline deprecated styles (e.g. border), and an image with no alt text. I know inline styles are bad, but if you must use them, at least make it CSS and not HTML styles.

The easy way to fix this, and I will do this by editing the plugin when the theme finally goes live, is to use CSS and not inline HTML styles, give the image some usefull, accessible alt text and remove the target attribute from the link. Something bizzarre I noticed was that the addthis plugin actually self-closes the img tag for the image, to at least attempt XHTML validity, but then makes the other really obvious mistakes. Strange.

The Current Theme

This all got me thinking. When i validated the theme currently used by this site, I did so prior to enabling all the plugins it currently uses. So I wonder if they have caused similar problems. In a word, yes, but I’m also to blame.

I’ve been proudly displaying the Valid XHTML and Valid CSS buttons on a number of websites and blogs for a number of years. I see them as a stamp of quality. So when I revalidated this blog I found a whole host of problems. As mentioned above, many of these have come from plugins and widgets using wither invalid code or, more often, HTML as opposed to XHTML. There are also some problems with slight tweaks I’ve made to the theme as well as posts I’ve written. Specifically the alignment of images. When including images in post I align them using the WordPress Rich Text Editor. What this does is add an “align” attribute to the image. This isn’t valid XHTML. What it should do, and what I will do from now on, is use floats to align images left or right.

A Suggestion

Understanding, as I do, that not all blog owners, writer, authors and managers are familiar with the underpinnings of their blog and theme, I think it’s important to not alienate them. That’s why I’d like to see some options available when using plugins and widgets. Specifically, I’d like to see a “naked” option, where the widget/plugin isn’t styled at all but rather marked up, semantically of course, such that it can be styled through CSS, which I can leave in a seperate file. I’d also like to see further options, for those less technical users, to change the styles before downloading. Google does a good job of this when setting up Adsense Units. For the new theme I’m actually manually editing some of my most used plugins so that the code they use is valid, and no longer use in line styles. Depending on my success, and the licence of the plugin, I may approach the author with what I come up with and/or release it for download. I’m sure there’s demand for it.

Have you come across any other offending plugins or widgets? Looking through the blogs I run, it seems like a pretty widespread problem.