I can think of a reason I might be tempted to do it:
- so that I could still use the validator to debug my markup (ie by finding typos.. I like to keep it in verbose mode) without having it complain about invalid markup that I was dead-set on including.

However, after two years now, this article still holds true. I saw in the wild, in a script, someone had hidden some invalid markup in javascript to keep the page “valid”. (I was appalled!)

Actually hiding it still invalidates the page, the validator is just not yet sophisticated enough to detect the errors.
If you’re going to use invalid markup then you should just use it with all the confidence and knowledge that it is the right thing to do. You shouldn’t need to hide it with javascript!!!

I try to write valid (XML) code, because I want to have access to things like XSL Transformations*. I try to write valid code because I like to be able to quickly spot debilitating errors in the validator(/s). I try to write valid (not quirks mode) code because it seems to apply a more consistent experience across browsers, and I want that without having to invest any extra effort**.
I think (well, of course, I would, wouldn’t I?) that these are the right reasons for embracing XML and standards.
I think that hiding errors from the validator for the sake of getting a badge is just silly and counterproductive.

Hiding semantic code? That I’m not sure about. If it makes it more maintainable then it might not be so bad. If the non-semantic markup reduces the maintainability of your code then throw it away.

*, ** Offering non-quirks-mode xml doctypes incurs a very high set up cost with content negotiation and such so I’m not sure if it is right to call this achievable and still claim a consistent experience across browsers.
But it’s still good to combine them where we can, because these things DO have some benefits, and if we don’t use them they will disappear from the world and Internet Explorer / The Terrorists will have won.

What I am against is adding mark-up via JavaScript when the only point is to hide the markup that is just there to provide hooks for an effect. It’s totally pointless and that markup may as well be there in the first place. Also using spans which are sematically transparent you are not affecting the overall semantics of a document anyway.

It makes perfect sense to add extra features with JavaScript, whether or not it’s “valid markup,” if it will gracefully be disregarded on a non-compliant browser. If, shedding the JavaScript, the markup that will be rendered is semantic and contains all the necessary content for the user of a screen reader, mobile browser, or Lynx browser to get the info they need… by all means, make it cooler for people using browsers that can handle the JS!

I do accept that there are justified reasons for using JavaScript in this way if it provides additional benefits or functionality.

There’s no hard-and-fast rules on this. The important lesson is to evaluate the best solution for the situation.

For me I can’t see why anyone would decide to use JavaScript to obscure non-semantic markup. If you make the design decision to add non-semantic markup for whatever reason then you should stand by it and not need to hide it away.

I do agree, however, that there are many instances when this method can be abused, such as including invalid code.

So including valid, but not semantically necessary, markup is ok in my book, but including invalid markup is no better than putting it right in the source.