Use Theme/Skin or CSS in Asp.Net

The problems that I see:

• Non-standard way of working: you are coming up with your own, fairly non-standard way of working. Any new developers you hire will have to learn the details of your framework. Some of them may not like it (e.g. see some of the comments above), and refuse to work in it. As you go along, you will also keep (re-)inventing lots of basic functionality, like data-binding, which is essentially a waste of your efforts.
• Not using the technology's strengths: WebForms are an attempt to bring event-driven programming to the web. To enable this by default, a lot of state has to be passed around all the time. By working around this, you are losing most of the functionality and benefits of WebForms.
• Existing technologies that do this already: There are excellent technologies that do what you are trying to do, but in a much better way. ASP.Net MVC is probably the best known. If you would like to develop in a style that is closer to the way the web actually works (and would like a framework which helps in that), try it. It really is an excellent technology, a bit of fresh air compared to WebForms.

Former Designer here, turned Dev, and I used to piss and moan about Web Controls too. Honestly, its MUCH cheaper for a designer to adjust their practices than for a .NET Developer to delve into a custom impelmentation of a GridView because the designer INSISTED that each TD have a 'rel' tag (or whatever).

As Arseni Mourzenko very wisely pointed out, the decision to use Webforms is a company choice that limits some of the control over the HTML while granting some efficiencies in coding. Unless the company is willing to re-consider (which they should NOT do just to please the designers), then the designers need to accept this reality. Here's a few things they can do:

1) Stop depending on ID's for anything. Even though this felt wrong at first, I found that life was actually a lot easier when I styled everything with classes (and inheritance, of course). First of all, it equalized all my selector weights. In CSS inheritance, ID trumps CLASS. It was actually kinda nice to have everything be a child and/or class selector, and made figuring out the specificity order a little simpler. Same thing in the JS layer, it gave me ZERO pain to swap out my ID-based selectors for class-based ones.

2) Teach them what RadioButtonLists and CheckboxLists convert into, along with Label = span, Panel = div and the other non-obvious control-to-html stuff. The way .NET renders these to HTML was a little weirder than I expected, and it was much easier for me to create screens when I knew how the HTML would come out of those controls.

3) Have them do their designers IN ASPX DIRECTLY, not raw HTML (!important) . Teach the designers the basics of GridViews, ListViews, etc. Give them some code snippets to push an anonymous object collection into a Grid/ListView control. If they can learn CSS then they can learn to copy-paste this code in. They can use the free version of VS Web Express, which is quite good at CSS & JS work now. These dummy web projects will give the designers a chance to enter some controls, then View Source to see how they are rendered.

4) Explain how the FORM tag is used in .NET. Forgot about this one earlier, but another thing the designer has to get used to is that usually, a single FORM tag wraps the entire page. This alters the way form controls behave, and you can't nest FORM tags without really weird side effects. Make sure the designers understand this or else their form HTML will be a nightmare to make into WebForms.

5) Stay away from Themes and Skin. Even though the .NET framework has these tools to help style controls across an application, they are clunky and weird to normal Web Designers, and I never found them worth my time. They seem like a nice tool to devs who aren't well versed in CSS, but will only slow down the designers. Let the designers work in their natural environment (html & css files) and they will be happier and more productive.

6) Keep "prototype" projects in your site solutions. To make sure the developers always have a target to code against, have the designers create a fake web project in your real solution to keep their ASPX-only pages preserved and untouched by the real developers. This means the designers can look back to their prototypes in the same solution as the real project to check on how the developers did, and the devs can run the prototype at any time to make sure their work matches the designers' intent.

Finally, resist any complaints to convert to MVC, unless you are ready to re-train your Devs. I love MVC personally, but if you've got a team with a ton of WebForms knowledge, don't go throwing that away for no reason. If your applications are having ViewState problems, SEO problems, or accessibility issues, then absolutely give MVC a hard look. But it will take a LOT more time to train WebForms devs on MVC than it will to train Designers how to use Web Controls.

At the end of the day, there was NO DESIGN I CAME ACROSS, that I couldn't personally make work in WebForms, even if I ended up swearing at that darn GridView for an hour before figuring it out.

Are there any tools or applications to provide the designers with the rendered (html page) of the .aspx pages?

Forget Expression (I never liked it). Get them the free version of Visual Studio (Web Developer Express). It can hook into whatever source control solution you have, and it will let the designers run their ASPX pages and see the rendered HTML in a browser. The CSS and JS tooling is much better than it used to be, and there are some awesome tools baked into extentions like Web Essentials. 1-click transforming of CSS rules into all their vendor-specific deviations, color pickers and palettes right in the VS interface, 1-click embedding of images INTO css files, 'LESS' CSS transformations (you can 'code' in CSS), F12 'Navigate To' on JavaScript, plus real intellisence, and way more. Its a treasure trove for designers now, FYI, and your designers might not know about it since earlier version of Visual Studio treated CSS/JS as second-class citizens.