I agree it should be easier to have no styling as a basis.
The problem is default.css IMO not the existance of the .Normal or .Head class.

(BTW, you can set the cssclass for the title skin object, Head is just the default)

IMO we need versioning for default.css, so if a skin is for skin engine version 5 or DNN 4 it will load the current version, if it's for "the new" skin engine 5.5 it will load the cleaned up version of default.css.

That way we can support "old" skins and allow the creation of cleaner new skins

IMO this is a very obvious point in time to rework default.css, because now that DNN has seperated the admin and host modules in DNN 5, a large part  of default.css is useless.
A lot of styling in there is for specific admin modules, where this really should be in the module.css for that module, so the css does not get loaded if you use a different filemanager for instance.

Jon,

Apologies if you thought I was trying to be smart regarding the workaround, my reference to a solution was included simply as a pointer for those reading the post who might be looking for a workaround to the issues of multiple CSS files and cascading. As Timo also pointed out you can specify the class of the titles in an XML file, but the ideal situation, which is what you're getting at, would be that it's all left unstyled, so we can define this ourselves and keep the CSS as clean as possible.

As a designer I completely agree that there are some improvements to the use of CSS within the framework that can be made. I am currently going through the default.css file myself, creating a template file for use on my own skins and there's a lot of inconsistency regarding fonts, sizes and so on.

Regards,

Rick.

I agree with this being an issue. This has been the source of many headaches and long days for me. Granted, 4 yrs into it, I have a good base css that overrites the default, but this is hardly ideal. And, as Jon mentioned, it all changes once you begin using ems. I used them for about a year and finally went back to pxs just for the simplicity. This is also causing problems for those just getting into DNN skinning. I mean, don't we want this to be something easy for people to get into. The easier, and more straightforward, the more people will stay with DNN and not go to something else and the larger DotNetNuke will grow.

I think the ability to turn off the injection of the additional spans and classes would be fantastic. And, if there were a way to set that in my skin file, all the more better! I also understand the module developer's argument, to an extent, as I have had this discussion at DNN user groups on more than one occasion. They are concerned with keeping the layout that they have come up with and think is best, however, they keep missing that what is best for their setup may not be best in mine. 

This consistently seems to be a battle between skinners and module developers. And rightly so, sort of. When applying a purchased skin, the particular module may not have been considered and therefore is lacking the necessary styles to make it appear as it should. However, when I am doing a custom skin, I can style for that module as needed.

But, I think this thread was started with more of a focus on the core. Again, I think the purpose of their approach is a valid one, to maintain consistency. Which, is what we are trying to do as skinners, isn't it? As Cuong Dang pointed out in the session, "Bridging the Gap Between Module Developers and DotNetNuke Designers" at the 2009 Day Of DotNetNuke, a simple, consistent naming pattern needs to be used.

All of that to say, I like the idea of being able to turn off the injection of spans and classes.