Forcing ASP.Net towards standards
In the recent Web Standards Project Buzz post ASP.Net & Standards Part II, Chris Kaminski writes a whole lot about ASP.Net, web standards, and how to make it possible to use both in the same project.
I’ve had some recent experience with this, and can only agree that the “HTML” that ASP.Net produces out of the box is for the most part horrible, invalid, non-semantic junk straight out of last century. A slap in the face of anyone who dares believe that people foolish enough to use a non-Microsoft web browser should be allowed to visit a site built with ASP.Net.
I obviously could not leave things that way for this site. When a client actually requests that their site is built with web standards, you really want to do whatever you can to get there. I went looking for workarounds, and thanks to Milan Negovan’s tutorial on response filters I was able to get rid of a few ASP.Net problems. I also use that method to remove any
target attributes inserted by the site’s editors and replace them with Strict DOCTYPE-friendly ECMAScript, as described in Accessible Pop-up Links at A List Apart.
However, the major offenders when it comes to invalid HTML are the controls built into ASP.Net, so most of them had to be replaced. Not being a hardcore ASP.Net developer myself, I had to nag my friendly coworkers about it until we had nice, clean, and valid code.
But wait, there’s more. As Chris mentions in his Buzz post, ASP.Net puts a hidden
<input> field called
_VIEWSTATE on every page. In theory, it’s a good thing since it’s there to keep track of what a visitor has entered in a form if something goes wrong. In practice, however, you really need to keep what goes in the
_VIEWSTATE field to a bare minimum. If you don’t keep an eye on it, well, I’ve seen sites with
_VIEWSTATE fields that are well over 25 kb in size. Per page. Sent to the server and back every time a form is submitted. Ouch. So we disabled that for all pages that don’t really need it. In this case, that meant almost every page of the whole site.
It took some work, but we and our client are happy with the end result. I’ve seen statements that the next version of ASP.Net will produce valid XHTML 1.1 by default. Hopefully that will happen, and soon. Most of the workarounds described here would then be unnecessary. So much the better.