Just because the developers of WordPress itself put such attention onto XHTML standards compliance doesn’t necessarily mean plugin authors do the same. Even if the author of the theme you use put substantial effort into total compliance, your installed plugins nevertheless have the potential to mess things up.
To raise awareness that there are some plugins out there neglect to follow these established coding practices (”programming grammar,” if you will), I’m publishing a list of plugins that I know of that produce invalid XHTML. (We still like you plugin authors, just fix them please!)
-
PDF24 WordPress Plugin — Apparently the authors of this plugin didn’t realize that WordPress is XHTML-based, because this plugin’s old-school HTML output will add literally hundreds of errors to your blog’s homepage alone.
-
BloggingZoom Vote Button — Whenever you use this plugin to include a BloggingZoom button in a post, the plugin will output a block-level <div> element that gets enclosed in a inline-content <p> element, effectively invalidating the source code of the post in question.
-
Ultimate Tag Warrior — This once-popular (pre-2.3) plugin puts your tags into an inline <span> element instead of in a block-level element like <p> or <div>.
For the record, basically all browsers can display invalid XHTML just fine, although more serious mistakes can result in hard-to-track-down rendering issues. Complying with web coding standards also helps future-proof your blog, and gives a good impression to tech-savvy visitors who might check up on your site using the W3C validator. (For more reasons to maintain validation, refer to the World Wide Web Consortium’s Why Validate? article.)
Do you know of other standards-noncompliant WordPress plugins? Let me know in the comments so I can add them to the list.
Tags:
Subscribe to feed