ASP.NET and standards compliancy
ASP.NET has been taking a lot of hard words since its inception. Most of the complaints are well deserved, but there are some ways to make things slightly better.
Unfortunately, this one is pretty much beyond any salvation and I hope most people have left it by now. It was released in 2000, which means that the technology was conceived during the late nineties and quite outdated these days.
The Web Controls mostly generate invalid XHTML, but there are several ways to handle this (more on this later). It’s also very important to stay away from the design mode at all costs. It will instantly change your markup without asking and could wipe out a lot of work in a second.
Also, turn off adaptive rendering to avoid generating different code for different browsers (which is always a bad idea) and reduce ViewState if you don’t need it.
An improvement is that the design mode does not change the markup by itself anymore, but you really should stay away from the design mode. I have the aspx view mode set to Source by default, and never ever touch the design mode.
The web controls mostly validate, but they are still a mess. Custom Web Controls automatically render <span> elements around the controls, which lead to invalid constructions such as block elements placed inside inline elements.
The infamous table grids are all over the place. Controls such as MenuView, TreeView and DetailsView generate layout tables by default, which is breaking checkpoint 5.3 of WCAG 1.0 (conformance level AA).
There are several tiny nitpicks for developers to discover. One is to scratch your head and wonder why empty alt-attributes are not rendered (you have to activate GenerateEmptyAlternateText), and so on. You could also run into trouble when the names of your control are mangled and prefixed with crap such as ctl00_MainContent_.
There are solutions to all this. You could write your own controls, use HTML Controls instead of Web Controls, or write some code to intercept the markup just before it is sent to the web browser and make corrections on the fly. If you don’t like the idea of writing your own controls from scratch, have a look at the CSS Adapters (more details below).
ASP.NET 2.0 emits XHTML 1.0 Transitional content by default. You cannot choose a Strict DOCTYPE from the IDE, but you can configure how your ASP.NET site render the markup by using the xhtmlConformance in web.config, like this:
The mode attribute can be Legacy, Transitional or Strict. Please note that it must be called “Strict” and not “strict”. If you follow MSDN which says “strict”, you will get a runtime ConfigurationErrorsException.
Be careful, since migrating 1.1 sites to 2.0 could enable Legacy mode which will kill partial page updates when using ASP.NET AJAX UpdatePanel controls.
In addition to using compliance filters, you can create a folder called “App_Browsers”. This folder may contain browser definitions that ASP.NET uses to identify browsers and determine their capabilities, replacing the old browserCaps element. The .browser files uses the Browser Definition File Schema.
ASP.NET does not recognize the W3C Validator and thus serves it legacy code which makes the page fail validation. One way of dealing with this is to put a w3cvalidator.browser file in App_Browsers.
Which leads on to…
The CSS Friendly Control Adapters transform the ASP.NET output to a CSS-related output. Actually, they participate in the rendering phase and don’t intercept the markup output, to make them as fast as possible. They also use .browser files mentioned above.
The main problem with the adapters is that they should be the default setting for web controls in the IDE environment. Very few .NET developers will code their own adapters just to control the markup.
The adapters are certainly not perfect, but at least a better alternative than the horrible vanilla controls. For more details on CSS adapters, have a look at my article Creating CSS Control Adapters.