Skinning in ASP.NET
I've been working with skinned controls a lot lately. Even on this site. The roadmaps circulating for ASP.NET mention skins and themes being part of the framework. Good news, I hope the implentation is comprehensive--although I haven't yet seen what a theme is defines as (is that a brand-friendly word for master pages?).
Right now, on 1.1, master pages and skins are a fairly well defined way to do dynamic layouts and look & feel. They're a bit tedious and you could probably spend a decade building out the plumbing and infrastructure, but they get the job done.
One thing I'd love to see in the ASP.NET 2.0+ presentation technologies is less reliance on inline styles. It's part of the default controls, control developers follow suit and you end up with a lot of RAD formatting that's decidedly un-rad. Just leave the formatting to CSS, please. Inline styles should be the blue-moon exception, not the other way around.
From working with skins recently, all I ever really want is a placeholder (not literally, but you get the point) control to hang my logic on, zero formatting beyond CSS if need be. The other thing that I've been dwelling on is you have to go the extra mile for a good skin architecture. Every discrete presentation element should be mapped to a placeholder location. Which takes time. Ergo the tediousness.
It's simple loose coupling really, if you look at this page and you see a permalink to the left of the date, it's quicker, easier and just effective in iteration one to lump the two together in some behind the scenes presentation code. The bite comes when you want to go ahead and move permalinks to a different location, now you have to go back to the code and uncouple day title and permalink as well as work on the skin control itself. Roughly nine stitches worth of effort.
Tonight's first rule of skinning: pull out all the stops when breaking out logical presentation elements on the page. Even if tightly coupling two presentation elements together makes sense in your initial layouts, even if there are no discrete requirements for their separation, take a step back and play devil's advocate.
And the Second rule of skinning: don't use any inline styles or deprecated formatting tags in your skins. Use decent transitional html for your structure, CSS selectors for the rest. Try and avoid table layouts, they're rarely required unless you are going downlevel. I don't wince much when I see table used for structural presenation and even formatting when you can kind of see the business case behind them. When they're used for simple alignment and layout it gets a little painful.