Why Are Plugins and Tools Making My Code Invalid?
I’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.
I also had a lot of issues with plugins on my page. I’m using XHTML 1.0 Strict as I don’t like 1.1 much, especially as there are some browsers which have issues with 1.1….
Anyway, first of all I’m using ShareThis instead of AddThis. I had AddThis at first but I got tired of it and ShareThis behaves valid with my template, without having to apply an own fix. Maybe it is worth trying for you. 🙂
Oh, yes, I got only one bookmark button (which is still generated by addthis) in the sidebar and it behaves valid…
GoogleAdsense….well…I see it this way:
These days many people are using AdBlockers and are most likely blocking the Google Ad. That’s why I don’t consider the ad as a part of the site, especially as it is included and generated with JavaScript.
The WordPress’ Rich Text Editor is something I don’t use at all. I prefer seeing the code, ensuring validity right from the beginning of typing an article.
Other than that I only have/had a few plugins which required my helping hands to get my blog valid again. One of the is “Subscribe to Comments”, just place a whitespace entity and a closing p tag in front of that HTML code and an opening p tag + whitespace after the HTTML code you find in the plugin. Only someone who really views the source may discover this “walkaround” 😉
If you don’t mind I had a look at your source code and got a few fix recommendations for this page. If you are interested I will write them in an email as a comment is not a good place to share such fixes, especially if the one or the other tag may be stripped away or used in the comment, breaking things even worse 🙂
Thanks for the offer Marco, but I’m actually part way through doing it myself. As you rightly pointed out, the subscribe to comments plugin is causing a few problems however the worse offender is the CAPTCHA plugin from ProtectWebForm. I think it’s one of the best plugins out there, but the code is really quite horrible, so it’s taking longer than expected. There’s loads of incorrectly escaped characters and some sloppy HTML. It’s a shame because I LOVE the plugin.
It’s a shame the plugins ruined that on ya. (And I can’t stand the WordPress Visual Editor. It’s just a pain to write code with! xD )
hm…about that plugin, maybe you give Peter’s Custom Anti-Spam image a try. I used on my blog for quite some time but don’t use it any longer as I trust Askimet. Another blog of mine is still using it though.
Michael – I’m still using the WordPress inline editor, but it’s only for lack of an alternative I like enough to stick with. I’m waiting for Ecto and Mars Edit to merge into a single, glorious, application.
Marco – That plugin looks interesting, I may try it out. The reason I use the plugin I do is because it’s only supposed to challenge spam bots with the CAPTCHA text, and not the average user. Supposedly giving the best of both worlds (i.e. making it very difficult for the spam bots, while still being seamlessly easy for real commenters).