Can someone please tell me, what is the correct way to specify that my skin will be an XHTML standard document, so that the page is not rendered in quirks mode?

I have searched and have found numerous threads discussing a few different ways, however the core recommended approach had possible performance issues and were in discussion about being fixed as of v4.4.0, I had found some work arounds as well.

My skin is being developed as an HTML file that will be parsed by DNN and turned into an .ascx file, I am not creating the .ascx file directly.  (i only mention this because one of the solutions I saw suggested sounded like the .ascx file needed the 'workaround', because the HTML parser would become confused by the tags.

I want to make sure that I do this in the 'newest' way possible; and so could someone either explain what should be done, or refer me to the most recent recommendation?

Thanks very much,

Matt Christenson

Oh and its also possible to change / alter the default.ascx page in the portal however this changes all skins and containers to be compliant and some modules do not render xhtml coding standards so they will possibly break. Thus its better to make the change per skin / container you create / buy and then test it with all your modules to ensure no errors occur.

There is a free module you can get called open viewstate. www.opendnn.com just register on site and goto free downloads, find version 3.0. Its a module you can stick on any one of your pages, (works for the whole DNN installation) The module lets you choose to cache the viewstate via xml, memory, or sql database. Version 3.0 provides all the changes inside the module. Just set the time outs etc based on user traffic and server loads. Basically any page a user views is cached and if the page doesn't change IE viewstate remains the same, then the cached version of the viewstate is sent to the user. Saving tons of resources on both client and server side. It greatly speeds up DNN sites, I use it on all of mine and have seen enourmous performance gains. Since I have large storage I save it via xml, and set the cache to like a week long.  So all my "Static" pages are nearly instant loads for my returning visitors. Since they aren't causing a full server hit just a call to the xml file, my server can focus on new visitors / dynamic content.

Hopefully the core team will build a better option right into the core systems, but till then this is a life savor.