Are you talking about the overall use of CSS and DNN or the way dnn works with the CSS hiearchy.  There is alot to be said about making sites work in CSS only, and have any form of functionality.  Joe Brinkman posted a lengthy blog about it - and I have to agree with it.

I think there is plenty of scope for improvement - but overall, if you get hung up on the CSS issues, you are overlooking the functionality of DNN and I sometimes think that some people might be better off using PHP, Drupal, Mambo, anything but DNN if they want to have these pure CSS skins. However the trade off is more than what people want to give up and why I'm seeing more and more people move to DNN with all it's inbuilt flaws and problems because of the fact it's the only product that offers you such a brilliant method to skin.  Having said that - we / me / us.. we're exploring more commerical CSS skinning and in January - there will be quite a few more out there to learn from..

I went to a talk where they were discussing DNN and Sharepoint - how the the new sharepoint coming out is fantastic, does lots of things, but at the end of the day - line them up thanks - they all look the same - it's like wearing Avon perfume - where people know it's Avon.  Line up the average CMS site and they all look the same - line up the high end DNN sites and you know you can't pick they are DNN - that's the part that has the appeal for people over and above the shortcomings.

There's also another area - the use of modules - why bother using DNN if you find that by going to CSS based skins you're limited to only a few of the modules - I can't remember all of them - but I know there are limitations.. And yes there is still lots of 1.1 baggage, but also how content is rendered on sites, it needs tables in many instance to display and hold the structure in place.

And in spite of caching issues, challenges with some CSS that needs tweaking, I think the DotNetNuke skinning engine, the concept, how it functions, the thought behind the architecture is really one of the strongest areas of DNN and the guys involved in the writing of it did an amazing job.

If you are using DotNetNuke as a business model, it's up to to you make it into the structure you require to suit your requirements, your client needs, your own developing/designing preferences.

I create my own master builds - in fact I've spent a week or so doing a few now - for my new projects - I customise the areas I need/want, remove the modules I don't want, add the modules I know are important, customise the web.config file, the templates uses, the skins used, the whole lot - to make the *dnnportal* for ME.. And from there - I run with that for several months, or until a build is available again that I see fit to go through the process and re do the Nina Installation - rather than the DNN one, and I suggest if you want to use DNN in business you consider doing things like this as well.  So I don't use the install files provide here - but customised, tweaked ones since I know now what to get rid of.  It will never make into Gemini  - many of these things are personal preferences.

It might sound off topic, based on the heading of the post, but you're raising issues about DNN that in many instances go deeper than just caching and I think that if you really understood the mechanics of DNN you would understand that aside from it's ongoing challenges at times, it's an amazing product to work with.

I would also like to tell you that I was commissioned to convert a tableless site to a DNN one, and let me tell you that I felt it looked like the dogs dinner before going into DNN, and there hundreds of classes, confusing, hard to pick up and follow, complex, and between IE 6, 7 & FF I can't see how it passed the final sign off.. Having said that- it's a great site - but just because it's all css, doesn't mean it's any better..

From my perspective, I am working with many businesses in getting the jobs done, cleanly as possible, as efficiently as possible (boy that's a hard one sometimes) and now, with our new site - skincovered.com - I will be working closely with Armand and John in doing what we can to show you how to make skins that are compliant, are commerically attractive, and educating people on how they can confidently modify their builds without really changing the core - but it is hard work - not because it's DNN - but because CSS is also an unforgiving, frustrating and crazy thing we all get drawn to  - because you can do so much with it.

So I guess I didn't solve anything - nor did I offer to make your life easier, but hopefully give you a little more insight about DNN.. As frustrating as it can be sometimes - I'm yet to see something that allows such flexibility, and the price of flexibility is visible in the cost of creating cutting edge websites and the time it takes.

Man - I better go to bed and have a rest!!   All this thinking hurts. I've enjoyed reading your posts and thoughts - and are they negative, probably not - they are just your thoughts at the time of writing as is this.

Nina Meiers

Timo,

I don't doubt your intentions, the way you are helping other out with their skinning questions proves your intentions are very positive. So no worry. Improving DNN is what most people on these forums are doing. Sometimes, however, it takes a long time for those suggestions getting incorporated into the core or into modules. WRT skinning issues like: the ability to specify a doc type in your skin is on the agenda (hopefully it will materialize quickly), this type of enhancement to dnn should improve skin quality and ease the live of a skinner.

Sometimes improvements are also a matter of taste, I think tableless skinning, however elegant, is also more difficult and the result can sometimes be less robust (in the light of the current state of DNN modules) than skins that use tables. So what is better? and with what objective in mind do you evaluate it?

I do hope, however, that modules will evolve and have less hardcoded styling in it. So what could we do to get involved? How about writing a short paper for module developers with guidelines and best practices w.r.t. styling their module. How about that?

Peter

Hi Timo - I'm certainly not offended or insulted - believe me I get put in place more often by the core team board more than any other core team member I think about what I write or how I post., so your comments aren't what I call offensive in the slightest - and although English isn't your native language.. you delivered your thoughts well.

I don't suggest you create an installer at all - but you might like to call it that - since all I'm doing is creating a customised zip file on how I think DNN should be built for my requirements.

How to Get Involved!    
.........................................................
Using the projects, testing, reporting issues, making feature requests, et cetera, is an essential role. Your feedback helps the projects to improve and grow.

... I think that's meant to see enhancements posted into Gemini - Perhaps a post called *feature request* for skinning might help - I don't know as the skinning and design element is not as high on the road map from my understanding but it will eventually, like all the elements of DNN be brought to the table for review.

So please don't think you're insulting anyone, least of all me..I didn't want to sound defensive, but there are so many posts to answer here and sometimes time is limited. What happens is we see alot of new people come in with very similar questions and comments - and we have to go through the process again of either finding the posts that answer (and the search isn't that crash hot), or page through hundreds and hundreds of posts just to find a link to add, or rewrite the post again to clarify to people about the behaviour of DNN.

Feel free to add as many feature requests as you like but I think to be listened to you'll need to back them up with some substance, which we could call *white papers*  for it to be listened to as youc an imagine now that DNN has evolved into a rather large project.  And can you imagine the implications on businesses, designers, developers if this major change was made - the outcome could be quite devastating for a while on the visual impact of many sites, and how modules display, so, would that mean that we run with another build when it's hard to manage two different .net platforms, 3 different builds, and then something like changing the doc type header, a few classes here and then and removing some tables .that could result in some rather unhappy people.

That's why I try to keep things simple - I work with the flaws since it's software like anything, try to find a good mix that suits my needs, then just zip it up like any other DNN build - and it's called CustomInstallXXX.zip - and I use that as my commercial build - so that building sites for clients isn't so much of a task each time. This is how I'm pretty sure most companies would do things.

Like I said before it was good reading people's thoughts and I was just sharing how I work around the problems because I think there may not really be enough information out there to explain things at the finer level and newcomers to DNN might pick up some tips or ideas that we share here.

:-D

Nina Meiers