I th ink one of the biggest problems with tableless skins is the lack of support in the web standards for layout. What I mean is that the web standards were built with content as the focus and presentation was an after thought. Today, we try to make a nice layout in something that was not really designed for the purpose. The CSS box model (which will be fixed once everyone implements CSS3 which will probably be in a couple decades) will be fixed but it is a good example of where the mindset was as you specified the size of the content but not the containing block, content was king and everything was around the content. That means the margins, border and padding where outside the size parameters you specified for the content making it impossible to use percentages in the current box model without wrapping you block within another block. Do not know how that ever got through, but that is what the Text Purists decided.
The issue of tables has to be one of the biggest mistakes the web standards group ever made next to the limited box model. Web developers have used tables for layout since they were invented. Why? Because they work pretty much for the needs and there is no other tools provided. Years back we were told to not use tables for layout but given no true replacement. Yeah, CSS helped to solve some of the issues but seem more like baling wire and duct tape. All we really need is a simple grid layout tag with column, row and cell tags and no one will ever use tables again for layout! Even if they supplied an attribute on a table to specify if it was data or layout would work. Oh well, that is a dream for sure, if ever approved it would take a decade to see all browsers implement it and have it work even remotely the same.
So, we are stuck with these limited web standards for years to come and we will have to make the best of them. At this point, we can structure using DIVs or using other element tags making them function as block DIV tags, but with the current standards, I do not see a way to have a skin that does not break if you cram to big of content in a module. When overflowing content appears, it will either rearrange some block elements (not resize) , will allow the contents to flow outside the block (has to be in the top ten dumbest ideas the web groups every came up with) or will simply clip the content so you cannot see it. This looks tacky when it happens and can confuse designers who do not know a lot of the limited standands and may cast your design in a bad light even though it is not your skin's fault.
At the end of the day, it seems that limited use of tables for bounding objects in DNN skins are probably the best option to keep the site intact for those time when you have overflowing content, which may also happen when people make posts in the forums module, blog replies, etc. It is hard to control content that is dynamic and ensure the content does not overflow the space allowed with the current CSS limitation. Skins need to remain elastic and I cannot see any other way to do it and have a professional look.
Sorry the large rant, but I have dealt with this standards garbage for too many years now.
My goal on DNN is to provide skins and contains that people can use without know HTML/CSS/XTHML, etc. and that they can use the skin without change. From what I can see, the focus appears more on the end user customizing skins rather than using them as providied. An example is the provided skins (blue, gray) assume you will have a logo that will contain your site name, logo and possibly your company slogan. That would require the use to have the knowledge of graphics programs to build their site title along with the fact it is an image instead of text.
It would be great if in the portal setup (and possibly page level override), you could specify the log, header title (which might even be different from the actual title tag) and a slogan. While a skin might not implement all of them, it would have them at their disposal to implement where possible. There might also be a couple other fields such as these that could be useful, but these are the ones I run into building my first commerical skin. I really do not want to force the user to modify the skin in order to add this information nor force them to build an image of the title they want for the site. Instead, my only option was to build a pane at the top to allow them to enter what they want and override the h1 tag for that pane to give the title the proper format. The two additional fields "header title" and "slogan" would have elminated having that pane and made the design much more clean.
There is a solution to provide added fields for developers, but it may be overkill for the needs. If there were a skin configuration manager that could read fields from an xml file and display them to the user (the person layout out the site) where they can fill in the extra field data for a specific skin, then every skin could have custom fields eliminating the need to directly edit the skin. As I have posted previously in other threads, this same skin configuration manager could have a list of CSS attributes to adjust the site without forcing the user to use the "stylesheet" overrides to enter them. One other possible feature is that they could select optional stylesheets (specified in the skind config xml file) to change the style of a skin. This addition could eliminate the need for 99% of the variation skins in a skin package and make it much easy on the user (person laying out the site) to customize the skin to their needs.
I have also been busy (until the last week with the work on this skin and module) building the Dynamic Panes module to allow admins to easily nest panes, which might eliminate the need for a three pane content area, designers could build skins with a single content pane unless they need them in other places on a skin.
As I mentioned, my goal is basically to make DNN and skinning easy for the people that have little or know real knowledge of web technologies so that just about anyone can setup a DNN site and make a business out of it, thus extending the reach of DNN and enlarging its marketplace. It would be great to take just about anyone and within a few hours of training, to be able to have them pop out basic DNN sites. Well, that is my goal at least ;)