Archive
Monthly
Go
|
|
DNN Blog
Jul
15
Posted by:
cathal connolly
7/15/2008 10:52 PM
Hopefully the changes detailed here regarding xhtml compliance will come as welcome news to the community, we've tried our best to make the necessary changes without causing anyone an impact. Theres no doubt that if DotNetNuke had been created in the past few years, rather than still having some legacy values from it's original 2002 codebase, we would have started off using xhtml, as the benefits around accessibility compliance, smaller sized skins, performance and document validity ensuring the correct working of ajax frameworks, are great advantages (plus skin developers would not have to create custom *doctype.xml files).
In addition, XHTML 5, an update to XHTML 1.x, which is being defined along with html 5.0 , is increasingly seeing support being added to a number of modern browsers with the html 5 video element being added to firefox 3, and the forthcoming IE8 browser implementing HTML 5 spec's such as cross-document messaging, a client-side storage API, network connection awareness and a window location hash meant to place Web applications into the browser's back/forward stack. I also expect browsers to start adding support for the other html 5.0 APIs such as audio, graphics and video & interactive document editing, so supporting xhtml 1.0 is an important first step to ensuring that DotNetNuke is well future proofed.
With both these thoughts in mind, there was some debate as to whether it would be wise to make the default doctype xhtml 1.0 to ensure that DotNetNuke is adequately forward thinking and well placed to allow skin and module developers the ability to take advantage of these enhancements. However, whilst theres not a huge amount of difference between the html 4 and xhtml 1.0 specs, as xhtml 1.0 was designed to be html 4.0.1 reformulated in xml, with minor restrictions , there is a small danger that existing skins may show minor cosmetic issues if the doctype is changed. This is something we wanted to avoid, so to try and support the desire to future proof DotNetNuke but also preserve existing sites look & feel, we've made a small change to the default doctypes with 5.0.
If you're upgrading from a previous version we will preserve html 4.0.1 as the default doctype, but if you are installing DotNetNuke 5.0 for the first time we'll switch the default doctype to be xhtml 1.0 transitional. We've exposed the value as a host level setting, so that it can be changed easily if required. To do this, log in as a superuser, and go to the host->host settings menu. There you'll see a drop-down for Default Doctype, which allows selection of the default doctype for the install.
This value acts as the default doctype, but can still be overridden in a number of ways. First of all, it will respect the existing *doctype.xml support , so any skins that supply this file will correctly switch the doctype at the appropriate time. Secondly, the value itself is stored in a new property of the TabInfo object, SkinDoctype, so can be switched at run time e.g. you can add code in your ascx.vb to change the value of PortalSettings.ActiveTab.SkinDoctype.
Finally, if you know in advance of your install that you would prefer a different doctype such as html 4.0.1 or xhtml 1.0 strict, you can edit the Install\DotNetNuke.install.config and change the DefaultDoctype value ie.
<DefaultDoctype>0</DefaultDoctype>
would ensure that a new install used html 4.0.1 as it's default doctype.
We hope that these changes will not cause undue impact to users, and will act as a solid framework for future skin and module development, as well as encouraging the long-overdue movement into xhtml.
11 comment(s) so far...
Re: DotNetNuke 5.0 xhtml compliance : Part 2
First of all, I am so glad to hear the core is finally becoming XHTML compliant. It's been a sore spot for me for a long time. Kudos to the team for making it happen!
It is also very useful to be able to switch the doctype on the fly using the drop down menu as shown. It might also be wise to go ahead and include all the common doctypes rather than just the 3 chosen, but that's being nitpicky.
However, I would strongly recommend against having this only as a host level setting. Doctype is 100% tied to the chosen skin. Without a skin in context, it has zero meaning. Furthermore, what if some of the portals on the installation have an XHTML compliant skin and some don't. Under this scenario, its an all or nothing choice for the default.
Yes, I realize you can still implement the required doctype by supplying a doctype.xml file for the skin, but then what's the point of putting this very cool feature?
It would be MUCH MUCH better to take this extremely useful concept all the way to completion and provide it everywhere that a page level skin can be chosen. Portal Settings, Tab Settings, and yes, Host Settings as well. I can easily envision scenarios where someone might implement an XHTML 1.0 strict skin for public pages but then a HTML 4.0 Transitional skin for Admin pages where they know what the browser is. It would be awesome to be able to easily switch the the doctype on the fly on a portal by portal basis or even page by page basis.
Almost there! Please take the concept to completion.
By mathisjay on
7/16/2008 10:21 AM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
@mathisjay, I considered making it a page level setting that inheritied from portal which in turn inherited from host, but in the end as all we were doing was switching a hardcoded install wide default I decided to go with the simpler move of supporting a user selectable/scriptable install wide default. The scope for 5.0 is frozen now (except for bug fixes), but it's something I'll bear in mind for a future release, provided theres sufficent desire for it.
By cathal on
7/16/2008 10:25 AM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
I fear for how bad my site will pass when it comes to allowing page admins to have that right. Every other page will have a different compliance level set, cause someone thinks they know something about webdevelopment cause they read something on msn. Rather keep the control out of page admins / admins in general, and leave it to the skin developers and site host.
Too much power is easily abused.
Overall at the page level the core should still be attempting to render in xhtml the components it creates then just let the skin manage the rest, nothing really changed much in far as how things work, except older skins might be getting a html compliance doctype. If your trying to run your site in mixed mode.
Overall I really don't like the page level idea, unless I can set rights to that page settings and who gets to change it.
By keeperofstars on
7/16/2008 12:55 PM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
Ya, on second thought, it would make more sense to have this as an attribute attacjed to the skin package itself. So, on the Admin->Skins or Host->Skins page, there would be a drop down field to specifiy the DOCTYPE to use for the each skins. I noticed there is a Skins table in the DB, but in all of my installations, its empty.
By mathisjay on
7/17/2008 10:01 AM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
@mathisjay, FYI the skins table is legacy, i don't think it's been used since the early 2.x days, there are no skin level settings stored anywhere, the skin package is it's own definition. In 5.0, skins now can have a manifest defined so perhaps we'll look at this in a later version.
By cathal on
7/17/2008 10:06 AM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
Hi all
In my opinion is the doctype decided in the design phase, so why should anyone have a reason to change it?
If you make a skin xhtml1 valid and change the doctype (down) to html4, isnt that asking for trouble? You don't get a valid skin out of that.
By njhvidberg on
7/17/2008 11:46 AM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
Hi Cathal,
Do the changes in Cambrian include changing the NavigateURL function to generate XHTML compliant URLs when using SEO Unfriendly URLs? We have been doing some work on the Events module for the next release to improve XHTML compliance, and the validator has complained about the URLs.
See here for a test site - http://validator.w3.org/check?uri=http%3A%2F%2Fwww.getdigital.ch%2Fv1%2FEvents%2FThemeFixedBlue%2Ftabid%2F142%2FModuleID%2F538%2FItemID%2F1%2Fmctl%2FEventDetails%2Flanguage%2Fde-CH%2FDefault.aspx%3Fselecteddate%3D19.07.2008.
Of course I may be reading the output from the validator wrong :-(
Thanks
Roger
By rogerselwyn on
7/17/2008 4:49 PM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
@roger,
i don't think so - i know the issue of correct encoding was mentioned (i.e. changing & to & etc.), but I don't know if anything was checked in - my inclination would be to make the changes at the friendlyurl level rather than within individual functions.
Theres certainly going to need to be some additional work done, both in the core and on modules - if you've any core module specific issues feel free to email me directly (Ernst-Peter can get you my email address if you don't have it)
By cathal on
7/17/2008 1:30 PM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
my note above should read "changing & to & amp ;" but the encoded value is being rendered and not the encoding [to get this message I've added extra spaces after the & and before the semicolon]
By cathal on
7/17/2008 1:33 PM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
Hi,
Is there any reason why the 0 is not in the DotNetNuke.install.config anymore?
If I use it in my clean install I get an error and my Portal is created with switched permissions.
Administrator can be edited and all users is locked.
Regards,
Eky
By Ely on
2/19/2011 7:34 PM
|
Re: DotNetNuke 5.0 xhtml compliance : Part 2
@Eky, this has been fixed in 5.6.1 AFAIR
By cathal connolly on
2/19/2011 7:34 PM
|
|