Wow, it really does sounds like an 'us and them' attitude here - Here is a validation output link that has the vanilla install of DNN 5.0 downloaded from HERE   - we are talking abou the same build here aren't we???  Tt doesn't validate either.  I feel that when I read some of these comments - you're sort of attacking the community by saying - hey it works for me.. it must be you..

However, the validation issue is a minor thing in my opinion, compared to the impact on skinning and the lack of backward compatibility. 

So not sure where this problem is coming from but I can verify publicly that it's not validating for what it's worth.

Nina

Nina, I would have thought you'd know me well enough to know that I don't ever intend any of my posts as "us and them", I'm simply trying to establish enough information to diagnose the problem.

I downloaded and installed dnn 5.0 from codeplex, and used firefoxes web developer extension to validate it via the "validate local html" function . The only question I asked was about doctype which I think was a fair question to ask, particularly as the errors returned by the validator state "This error is often caused by incorrect use of the "Strict" document type with a document that uses frames ...".

As you know validators can return different results for different devices/user agents and asp.net server controls can generate different code for different browsers, so at the minute all I knew for sure was that I could generate valid output locally (I do not have access to a web hosting account at the moment)( and the user who originally posted cannot, so all I was looking was sufficent detail to work out what the issue was.

Now, that I have a public instance (your http://www.dnnbeta.com/Home/tabid/75/Default.aspx is very handy), when I try to validate it from IE 8.0.6 it does not validate, however when I try via firefox 3.0.5 it does validate. Therefore the issue seems to be caused by browser detection code, either in asp.net or (more likely) hardcoded into the menu (probably to work around an IE quirk). Now I have a repro, we can work to a solution.

Therefore the earlier posts where it validates for some users, but not others are completely understandable -we're simply using different browsers, hence the apparently contraditory results.

Cathal

Skins can be delivered as single zipped files with the skin files in them and the name of the skin - eg.. myfilename.zip used and uploaded as just a skin on it's own.

Containers can be delivered in the same way.

If this method was being used - I'd select the 'upload skins' option and upload the myfilename.zip file and then click the 'upload containers' and use the same method and upload the container files called 'myfilename.zip' as well. That's a two step procedure.

But, until now, you could create a skin package - that is - combine the skins and containers together and upload them in a single instance and it would then be one step procedure.

Packaging them was a little more work - eg.. you worked on your local machine and have containers/myfilename/container.ascx file ... and you would have skins/myfilename/skinname.ascx -  - you would zip the skin file up in a zipped file called.. skins.zip and you would, in the container folder, zip up the files and call  container.zip  - you would then copy the container.zip file and paste into the same folder where the skin.zip file was...  

That would give you two zipped files - one called skins.zip and one called containers.zip together and you'd right click in that folder where they are and zip the two zips to gether... and give that the myfilename.zip name.. which would be your skin package..

Also in that skin package - you could put an 'about.htm' file in there which give you information abou the skin, the author etc..  That was commonly known as a skin package and many skins on snowcovered are presented that way. 

But now, what happens that if you have a skin package - and you unzip that package - and you don't rename the skin.zip to the 'skinpackage'  name- it uploads to skins/skins/  - each and every skin you have will go to the same folder.

The same thing occurs with containers..

I know it has to be changed, but all the skins i have on my free skinning site now need to be repackaged completely to work in dnn 5.  This will take some time but it has to be done or we'll have lots of people unable to use the free skins I have.

Now, if the developers did what they say they do - that is allow for legacy skins, backward compatiblity it would buy time for those who provide skins for the community either free or commerical.

I vote we bring back 'legacy skin' support.  If you parse these skins - eg.. use the uploader, you'll find that now the 'about' skin will appear but will break the page becuase it has no 'tokens' in it. Before DNN knew that there was an about.htm skin and it remained that way - but now - that's all gone as well.

That's what I mean about impact on skinning...

Nina Meiers