When I write HTML, running code through the W3C Validator is part of my process. If the code doesn’t pass the validator, there’s a slim chance I’ll consider that code ready for anything.
So after I upgraded this blog to WordPress 3.01’s Twenty Ten theme, I was mildly irritated to find that I had a few validation errors. I viewed the source code to investigate the offending lines of code, and noted that the code the validator cited was not in the source.
This phantom code led me to suspect that DOM scripting from a plugin caused the errors by inserting more code into the markup. That was it, and this evening I finally took the time to track it down. Here’s the scoop.
First, the phantom code that broke validation
Honestly, the first time I saw this error message, I didn’t notice the error text that pointed to the target attribute. No, I was first startled by a pattern that looked to me like the tail-end of Javascript code used in an anchor’s href or onclick attribute. I was startled because, having already looked through the code, I thought I would’ve noticed that pattern, since it is one that I avoid.
Where was this code? Well, all 9 errors were in the same area of code: links to other websites (blogroll) in the sidebar. I wanted to see it for myself, so I opened the page and viewed the source code. I used the Find command and pasted in some of the code from the validator error message, but the Find came up empty-handed.
While the offending code was not in the served markup, the validator was certainly picking it up, so I went back to the validator to examine that code in more detail.
The value of the onclick attribute was the immediate tell for where this code came from. It was the Google Analytics plugin I’m using.
Investigating the plugin that caused the validation error
Google Analytics for WordPress is a fantastic plugin. It makes integrating Google Analytics easy, and it has some excellent advanced settings.
One setting is to track outbound clicks and downloads as events so they are are viewable in Google Analytics.
To test the theory, I unchecked that box, saved the settings, and revalidated the web page.
It passed with flying colors.
Validation error identified, but I’m actually curious about tracking downloads
For the time being, I’m okay with leaving that feature turned off. I’ll let the plugin author know about it and hope the problem will be resolved soon.
Yes, I lose a feature to get back to valid code. Perhaps there is a support group for this kind of behavior.
But in my defense, this is just a personal site. I don’t make any money on it, and my interest in tracking downloads is just curiosity. I only have a few downloads or outbound links I’m interested in, and I have nothing riding on that knowledge beyond satisfied curiosity.
Still, the entirety of this problem can be laid to rest on a simple, meddlesome, and empty target=""
attribute. That’s irritating.
3 responses to “Google Analytics for WordPress (version 4.09) trips HTML validation when tracking outbound links”
To be honest, should target even be generated by the plugin? Isn’t that just bad news waiting to happen?
I can’t say as I’m surprised by the plugin breaking validation though, I rarely see as strict adherence to valid markup as I’d like from other plugin authors.
Also, you’re still broken according to validator. http://validator.w3.org/check?uri=http://blog.davingranroth.com/2010/11/google-analytics-for-wordpress-version-4-09-trips-html-validation-when-tracking-outbound-links/&charset=(detect+automatically)&doctype=Inline&group=0
Feel free to disregard this comment. :p
Yeah, I agree, why add a target attribute where none was needed before?
And thanks for pointing out this additional validator issue. I didn’t check the individual blog post pages.
It looks like the same plugin is adding some javascript to track comment form usage. That’s another optional feature of the plugin, I think.
However, it is using a
charset
attribute on the script element where none is needed. As of the current W3C work on HTML5, you only usecharset
on a script when thesrc
attribute is also used, referring to an external script resource.