The more I come across it, the more it irritates me... I understand why it exists, but how necessary the injection of the "dnn_" prefix to all runat="server" ids is beyond me. The problem I have with it, is that this phenomenon requires skinners to add additional markup to skins to accommodate panes or use classes for everything as opposed to being able to target the IDs for styling.

I use IDs for a lot of my markup, as IDs are meant for elements that only appear once on a page. IDs are also almost always preferred... I'm paraphrasing here, but,

"The key thing to know is that IDs identify a specific element and therefore must be unique on the page - you can only use a specific ID once per document. Many browsers do not enforce this rule but it is a basic rule of HTML/XHTML and should be observed. Classes mark elements as members of a group and can be used multiple times, so if you want to define a style which will be applied to multiple elements you should use a class instead."

So, essentially, we should be observing the following:

Use a class tag if:

1. The style is used in various places throughout the document
2. The style is very general

1. The style is only used once ever in the document (like most panes are)
2. The style is specific to a certain area of the document (like most panes are)

DNN's inherent injection of dnn_ to server-time IDs changes things somewhat.

My recommendation would be for a future release where this didn't occur. It would allow skinners to be able to style the panes / wrappers based on their ID's as opposed to having to add an extraneous class name for it as well.

Your thoughts..?

Jon

Shebang Websites - A product of Mogridge Design
Hey, we're partnered with UntangleMyWeb.com

 +1 from me too :)

DNN should NOT be injecting anything into to the sites HTML. This not only creates messy HTML but it also makes it harder for skinners to work with DNN.

The mistakes that have been made in the past have to be fixed one day & I think the Corp just needs to bite the bullet & correct them.

What I don't understand is why the Corp approves breaking changes - like having to have a core login module on a custom login page. This change alone broke just about every site with a custom login module (including 20+ sites I have upgraded in the past week). To me this was just plain wrong to break everyones site just to look after a few people who had no login module on their page (especially when there is a login page reset script floating around that worked quite nicely for the very few people that actually needed it).