Master Page Stumbling Blocks
Deeper down the hole of ASP.NET Master Pages, I ran into an issue with name and ID mangling. The article I mentioned the other day actually touches on this, but the comments on ScottGu's post on the same subject get into name and ID mangling in much greater detail. The problems are 3-fold: CSS selectors may need to know IDs, Javascript on the page may want to use IDs, and external applications may want to use IDs. There are at least partial solutions to the first two - for javascript, use the RegisterClientScriptBlock method. For CSS, use themes (which have their own set of issues) or to not use ID based selectors at all (though being told to simply use class-based CSS selectors rubs me the wrong way, it's like telling an OO programmer that they can't use the Singleton pattern or static). For the third part, there seems to be no solution. In particular, the test framework I use often loads a page and then looks up a control by ID or name - it looks like all the test code will have to change to accommodate the master page implementation. This is what Carson is complaining about in Why serious web developers can't use Master Pages - even though the name mangling happens in a predictable manner, now my test code has to know something about the structure of a page to look up a control, where previously, the name or ID was enough to do the job.