However, I still like to see myself as the first Swede out with such a blog post: How to generate valid XHTML with .NET :-)

Regarding the limitation of one form for the entire page I don’t think it affects accessibility that much. If you want to use multiple forms, check out the open source component WilsonWebForm which allows you to use multiple forms in the same page.

Personally I find using XML/XSLT is much more powerful and gives finer control of the output that you need to create. Using ASP.NET on the server side is still useful for the OO power that .NET gives, but we just typically override the Render() method in a base Page class, which transforms xml data (this of course assumes you can get your data in XML format easily) with a specified XSL.

The child classes, the actual pages, simply set the data, which XSLT to use, and any XSLT Parameters that might be needed.

For optimization, as well as page output caching, the XSLT can be compiled and cached into the Cache object, with a dependency on itself, so that when it changes, the cache is appropriately invalidated.

This has worked quite nicely for us on a very, very high profile site (not sure I can mention it just yet).

Anyway, I had another question:

What do you think about the limitation, typically, of one form for the entire page? Sometimes, semantically, and for accessibility, it would make sense to break parts of a page into multiple forms (e.g. a form at the top of the page may be for searching, a form near the end of the article may be for comment posting, and another form somewhere else could be for email subscription or something.)

While technically this can be made to work in one form, semantically these are all different forms, and for assistive technology, they could present different forms for the user to fill in.

Hence, I believe that the one-form-suits-all approach of Visual Studio .NET is not always appropriate (another reason why XML/XSL approach works for us).

Apologies for the long comment!

Anup