I tend to get quite sad when people approach ASP.Net and can drag and drop controls and build a site without really thinking about the markup that gets sent to a client. I know that part of their brief is to make it easier for people to build sites, but the added layer of abstraction of using a framework often means that people never gain an understanding of the underlying technologies involved.
I’ve seen lots of respectable developers work on sites without running validators over their work or nosing around in the markup that is generated. People will learn the interface for consuming a particular server control without ever getting near the HTML. You’ll see posts from beginners along the lines of ‘how do I set the src attribute on an image’ - so you learn to set the ImageUrl property on the server control.
I tend to approach development in ASP.Net from the other direction… how can I get the framework to generate this markup that I require in the most effective way? I think there should be minimal difference between how you would author a static site, and the generated markup from a dynamic site. Otherwise you’re compromising the quality of the site to accomodate constraints from the framework that you’re using.
I think ASP.Net is a great framework. However I strongly believe it should be used to build custom controls that serve the specific markup needs you have for a site. Generally if you’re doing things correctly, the actual HTML is purely content and therefore very simple. It’s not actually that much effort to author nice simple custom controls that just serve your requirements and do nothing else.
A simple example is how all of the ‘free’ server controls will always render an id attribute to the client - generally this will be autogenerated and long and bloated. Firstly this can interfere and make it hard to use ID based selectors in CSS, but also (more importantly) you should only render an ID attribute if you need a hook for styling or behaviour. Otherwise you’re simply bloating the stream of data that gets sent to the client, and wasting bandwidth and server resources.
I always tend to build a base custom control class where you can specify whether and ID should be rendered, and also whether the ID should be scoped or not. If set to true, the ClientID property gets written to the output stream (the fully qualified value), otherwise the exact ID that was set on the control. The default for rendering the ID attribute is false. This means that the markup does not get bloated with unnecessary information, and as an author you have complete control over the value that gets rendered (so using ID selectors in CSS is back on the cards).