Salaro.. was it you who was working or managing the skinning framework?
I have a lot of comments about that aspect of DNN and would be happy to pass them on at some point if you are looking at any major revisions to it in future.
I've just now had a look through the forums here and can't find one for the skinning framework, so I'll just post a few ideas here and you can take them or leave them as you see fit.
For a start I feel it is important to try and get that fine point of separation between interface and code behind consistent across all modules. One suggestion I have is to create a standard non-themed skin, one that is plain text and plain tables with no further styles other than what is in the default.css. This unstyled skin would be used to define the point of separation mentioned above. Module designers could be encouraged to provide unique named classes for each item/table/cell/text etc. but not to otherwise do any sizing or styling in the code behind. I feel that a fairly simple hierarchy, not just of style sheets, but of rules on where to do what, could be devised to provide a more powerful skinning system in some future version of DNN.
Here's a rough write up of what I've been thinking:
Code-behind:
Only insert code providing functionality - no layout , design, spacing or styling at all.
Code up front e.g ASCX files:
Use tables, divs, spans etc for layout and provide a unique class for each, named according to some sort of naming standard that relates to the module name and the location of the item. Do not insert space, padding, margins or any other sizing information.
If the module has templates with tokens for arrangement of the various I/O bits like the Gooddogs Repository then perhaps the DNN skinning manager system could be leveraged to provide a facility for creating the ASCX files from user-created HTML and Attribute files. We do it for the skins already; we could do it for modules too.
Module.css:
Style the unique classes from above in a manner that makes the module appear correctly within the new standard non-themed DNN skin mentioned in my post further up. Provide specific rules around the use of styles taken from the default.css. e.g. 'Normal' should only be used in the plain text content areas of the module, not everywhere where text is.
The result would be modules that fit tightly into containers. They would have clearly named classes that control the sizing and spacing and appearance of the module inside the container. They would also not use default DNN classes for anything other than their output (separate module appearance styles from module content/output styles). Currently too many modules use default classes for everything from titles, to column headers and footers and it really just reduces the flexibility of the system.
I have many ideas in this area gained from many hours of fiddling with these things. Let me know if I can comment further.
Regards,
Rob
P.s. Sorry for going off the thread here.