Complying with W3C Standards means that ASP.NET coders will now have to avoid some commonly used tags and attributes. Not ready to upgrade? ASP.NET 2.0 will let you hit the compliance “snooze alarm” in your web.config file, but that option should be used cautiously.
One of the most significant limitations of ASP.NET 1.x is that pages do not comply with any W3C Standard for markup—HTML 4.01, XHTML 1.0, and XHTML 1.1. What’s XHTML and does it differ from HTML?
XHTML dictates that web pages be well-formed XML documents and also sets a few additional requirements for the markup. In particular, the name attribute is not allowed with the <form> and <a> elements. The <script> tag must be rendered without the language attribute and with the type attribute. The <input> tag must always be enclosed in a block level element like a DIV. In practice, when rendering the viewstate, its form, or an anchor, ASP.NET 1.x patently violates XHTML conformance.
The markup produced by ASP.NET 2.0 controls conforms to the XHTML 1.1 Standard with very few exceptions. This compliance produces a number of observable changes in the final markup served to browsers. For example, each element either includes an explicit closing tag or is self-closing (with />) and is always enclosed in a container element. For example, the viewstate hidden field is now surrounded by a <div> tag and the name attribute has been removed from the <form> element. In addition, any script tags rendered into the page include an appropriate type attribute and are rendered in CDATA elements.
Some of these changes might break existing pages. What if, say, you have a page that relies on the name attribute on the form? XHTML rendering is the default, but should that pose you problems with existing pages, you can disable it altogether. To smooth migration of ASP.NET 1.x pages, you can add the following setting to the web.config file, which forces ASP.NET to render controls as in ASP.NET 1.x.
<system.web><br> <XHTML11Conformance enableObsoleteRendering="true" /><br></system.web>
You should not abuse the option to disable XHTML rendering, as it might not be supported in future versions of ASP.NET.
The generation of XHTML-compliant output is guaranteed only for the vast majority of core ASP.NET server controls. Controls such as HyperLink, BulletedList, and AdRotator generate nonXHTML-compliant markup regardless of the settings you choose. GridView and TreeView controls are also at risk if they incorporate HyperLinkColumn and TreeNode components. You should avoid using these controls in pages where XHTML compliance is a strict requirement. If you make use of third-party controls, you should always check with the vendor to see whether they generate XHTML markup.
It is interesting to look at the reasons why these controls are not XHTML compliant. All of them make use of the target attribute, which is not permitted by XHTML. Because the target attribute is required for these controls, as a developer you should bear this in mind and explore alternate approaches for pages that must be compliant.
ASP.NET is unable to fix XHTML errors that occur in the literal part of the pages. If your page contains static text or HTML elements, the responsibility of ensuring that they are XHTML compliant is entirely yours.
How can you make sure that a given page, or perhaps a given control, renders XHTML markup? You can use the W3C Markup Validation Service at http://validator.w3.org/ by either entering the URL of your page and having it check the page or by uploading the page to the validator’s site.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
