ASP.NET, Part 9: Rendering Cleaner HTML
Welcome to part 9 of my tour through ASP.NET 4.0 [http://blog.hmobius.com/post/2010/02/09/ASPNET-40-Cometh.aspx]. In this episode, we’ll conclude our look at the ways that ASP.NET has been tweaked in v4.0 to produce cleaner, leaner HTML that we can turn to our purpose without having to deal with some of the inconveniences of previous versions – control IDs and injected HTML we can’t control being two. More control over viewstate being a third.
ASP.NET 2.0: Only Technically Standards Compliant… Even in 2005, the idea of producing pure HTMLwebsites had gained quite a foothold. XHTML had been a W3C Recommendation since 2001 and CSS was evolving and being used more prevalently. Sites like CSS Zen Garden [http://www.csszengarden.com] had been championing cross-browser sites and advanced layouts with this approach for a couple of years. All it required was control over the HTML generated by your site and some reasoned application of CSS.
Regrettably, ASP.NET 1.1 didn’t produce standards-compliant HTML at all, so ASP.NET 2.0 created a new setting in web.config called xhtmlConformance [http://msdn.microsoft.com/en-gb/library/ms228268(loband).aspx] that would determine how its server controls were to be rendered as HTML. By default, controls would render markup compatible with the XHTML 1.0 Transitional standard (Transitional). Alternatively, the setting could be changed to have ASP.NET render markup compatible with XHTML 1.0 Strict (Strict) or as v1.1 (Legacy) has rendered it before. Websites upgraded from v1.1 to v2.0 were set to this Legacy mode.
Unfortunately, sites running in Legacy mode didn’t work with ASP.NET AJAX [http://weblogs.asp.net/scottgu/archive/2006/12/10/gotcha-don-t-use-xhtmlconformance-mode-legacy-with-asp-net-ajax.aspx] and while Transitional and Strict modes were technically compliant with the XHTML 1.0 standard, they could equally have been described as CSS-intolerant.
- Menus were rendered as tables rather than lists (not only harder to work with in CSS, but semantically wrong too) * Several properties like border=0 or disabled=disabled were mandatorily added to various elements without a way to remove them. * For templated controls, you had full control over the templates themselves, but not over the outer table that surrounded the templates.
Technically correct, but not a good foundation to build standards compliant sites upon. The introduction of the ListView [http://msdn.microsoft.com/en-gb/library/system.web.ui.webcontrols.listview.aspx] & DataPager [http://msdn.microsoft.com/en-gb/library/system.web.ui.webcontrols.datapager.aspx] controls in ASP.NET 3.5 and the out of band CSS Control Adapters [http://www.codeplex.com/cssfriendly] release helped somewhat but it’s only because they’ve been able to go into System.Web for .NET 4.0 that Microsoft have been able to make ASP.NET (mostly) CSS-friendly. Indeed, emitting cleaner markup was one of the main goals for ASP.NET 4.0
ControlRenderingCompatibilityVersion Like xhtmlConformance in ASP.NET 2.0, a new setting is now available in web.config to control how controls render HTML. It is called ControlRenderingCompatibilityVersion.
CRCV, as we’ll call it, takes one of two values. Set it to 3.5 (the default for sites upgraded from ASP.NET 3.5) and all server controls will render as they did in ASP.NET 3.5. Set it to 4.0 (the default for new web site and web application projects) and the following happens
- xhtmlConformance is set to Strict. * Menus are rendered as lists rather than tables * Extraneous properties like border=0 are removed from the emitted markup. Even the error text on validation controls is no longer set to red. * The rendering of the outer table for templated controls can now be controlled with the new RenderOuterTable property.
Let’s look at these changes in detail.
Menus Let’s consider a very simple menu control with three items.With CRCV set to 3.5, we get three CSS styles for the menu added to the HTML
, 53KB of script files added in by two calls to WebResource.axd (21KB for the standard script to handle postbacks, 32KB for a menu-specific script file), and the following HTML for the menu itself.