I recently shared an early draft of the DNN UX Style Guide document with the members of the DNN Experience Community Team asking for some feedback. One particular issue immediately rose to the forefront and I think it would be useful to open it up to the DNN community at large:
What XHTML Document Type Definition should be required for DNN-generated markup going forward?
I was going to write a blog post about the issue, but ended up deciding that bringing it to the forums would likely elicit more comments and discussion, hence this post. Sorry it’s so long, but I felt it was necessary to ensure readers would be privy to all the details before engaging them.
To begin, I’ll post the relevant section of the draft style guide, some discussion about XHTML 1.1, a couple of comments from the Experience Team about the core issue with a few of my own thoughts and then I’ll open the floor to your comments.
Here we go! Buckle yourself up and hang on...
DRAFT Guidelines
4. General Web Development Considerations
In today’s interconnected society, web developers regularly face the challenge of creating websites that are optimally accessible to different people, browsers, search engines and devices. The guidelines in this section ensure that DNN’s core application components are designed to assist rather than hinder this process.
There are three types of guidelines in this section:
- Requirements – guidelines which use the words ‘must’
- Recommendations – guidelines which use the words ‘should’.
- Options – guidelines which use the words ‘may’.
Failure to follow required guidelines may result in invalid mark up that could cause DNN site pages to fail to load properly. Required guidelines also define the minimum level of support expected for other standards (e.g., the Web Content Accessibility Guidelines) and considerations (e.g., browser compatibility).
Front-end developers and UI designers should follow recommended guidelines under most circumstances. Although these guidelines can be adapted and restructured to suit special needs if a particular component warrants it, it is strongly recommended that front-end developers and module UI designers avoid deviating from these styles unless absolutely necessary.
Optional guidelines generally provide for more detail, complexity or a greater level of standards compliance than associated requirements or recommendations and are provided when such additional considerations may be applied or implemented if a front-end developer or UI designer chooses and when doing so will not countermand other guidelines.
4.1 Hypertext Markup Language
→ Core components of the DNN application must generate or contain markup that adheres to the XHTML 1.0 Standard according to the W3C specifications for the markup of web sites.
→ Core components of the DNN application must generate or contain markup that adheres to the XHTML 1.0 Strict Document Type Definition as specified in the XHTML 1.0 Standard.
→ All web documents generated by core components of the DNN application must include the complete Document Type Declaration for the XHTML 1.0-Strict DTD, exactly as shown here, both in spelling and in case.
Concerning XHTML 1.1
In addition, there is one more option available which I hadn’t originally considered—XHTML 1.1. The abstract of the W3C XHTML 1.1 Recommendation has this to say:
This Recommendation defines a new XHTML document type that is based upon the module framework and modules defined in Modularization of XHTML. The purpose of this document type is ... to provide a consistent, forward-looking document type cleanly separated from the deprecated, legacy functionality of HTML 4 that was brought forward into the XHTML 1.0 document types. This document type is essentially a reformulation of XHTML 1.0 Strict using XHTML Modules.
On the surface, it would seem that XHTML 1.1 would be the “best” standard to use if the primary goal is to focus on the most current standards. However, there was the tricky problem that a W3C Note, XHTML Media Types (released August 2002), recommends that XHTML documents should be served with the ‘application/xhtml+xml’ Internet media type (it may also be sent with ‘application/xml’ or ‘text/xml’ but this is discouraged), with ‘text/html’ should be limited to HTML-compatible XHTML 1.0 documents. Unfortunately, although Microsoft has added XHTML support to Internet Explorer 9, both IE 7 and IE 8 fail to handle the ‘application/xhtml+xml’ format properly (rather than rendering ‘application/xhtml+xml’ content, a dialog box invites the user to save the content to disk instead). In addition, there are so many issues that arise when XHTML 1.1 is sent as ‘text/html’ that the practice is essentially broken and even using ‘application/xml’ or ‘text/xml’ is risky at best.
I have recently learned, however, that XHTML Media Types – Second Edition was released in January, 2010, and this revised note “contains suggestions on how to format XHTML to ensure it is maximally portable, and how to deliver XHTML to various user agents – even those that do not support XHTML natively.” In summary, an XHTML document may be served as either ‘application/xhtml+xml’ or ‘text/html’ based on what the user agent’s accept header claims it will recognize, so long as the document satisfies a specific set of compatibility guidelines included in Appendix A of the XHTML Media Types note, thereby making XHTML 1.1 a viable alternative to XHTML 1.0 Strict.
Experience Team Comments
Here are two comments from the Experience Team that gets to the core of the “controversy” (as it is).
(As I haven’t asked for permission to identify the writers, I have left them anonymous here. If they wish, they should feel free to identify themselves in the comments.)
We must be XHTML compliant, but I don't agree with the XHTML strict doctype.
IMO it's a theoretical standard that's unusable in practice simply because it's too strict.
One example is that the target attribute for a link is not allowed in XHTML strict, which IMO is quite stupid.
I would say "Must use an XHTML transitional doctype"
I think you are correct to say that DNN Application MUST generate ... XHTML 1.0 Strict Document. It is very correct. After all we don’t want to have in any of the Modules or Core part of the DNN to contain or etc... as then the skinner trying to do anything significant in UI would have to hack the core, will find it difficult to change things with just Skinning.
The first quote makes a good point that there are a few tags and attributes found in HTML 4.1 that are not allowed in the XHTML 1.0 Strict DTD (or the XHTML 1.1 DTD) which are still very useful – the writer specifically mentions the lack of the ‘target’ attribute which was placed into the XHTML 1.0 Frames DTD as its original intended use was for opening links into different frames of a framed document, but it also allowed a link to open a URL in a new browser window. It is, of course, possible to use scripts to open a URL in a new window, but one must agree that this is a rather convoluted approach to achieving an action that was simplicity itself in HTML 4.1.
(As an aside, while the XHTML 1.1 DTD does NOT include the target attribute, there is an XHTML Target Module. In theory, it would be possible to create a custom XHTML-family document type equal to XHTML 1.1 + Target, but I don’t think we want to go there...)
The second quote also makes a good point that we want to encourage skin designers to move away from using most of the HTML 4.1 tags and attributes that were deprecated in XHTML 1.0, especially ones that define presentation rather than structure (later guidelines in the document require all presentation to be managed through CSS). If the guidelines require the Strict or XHTML 1.1 DTD this practice would be enforced automatically. While we could require the Transitional DTD and recommend Strict or XHTML 1.1 DTD, I would also want to include a recommendation against using deprecated tags or attributes, but this is a risky stance to take as a page using the Transitional DTD may technically validate even though it doesn’t meet our other guidelines and it would be all too easy for a skin designer to accidentally slip up concerning (or even deliberately ignore) such guidelines.
Now that I think about it, I suppose we could also require the Strict or XHTML 1.1 DTD but include a recommendation allowing the few otherwise invalid tags and attributes, such as the target attribute, that we consider useful enough to allow breaking the standard.
Opening the Floor
So, I’d like to know what the community thinks. Should we:
- Relax the guidelines, requiring XHTML 1.0 Transitional, recommending XHTML 1.0 Strict and recommending against using most deprecated tags and attributes?
- Stay with the existing guideline, requiring XHTML 1.0 Strict “as is”?
- Modify the existing guideline, requiring XHTML 1.0 Strict but allowing specific exceptions for particularly useful deprecated tags and attributes?
- Upgrade the existing guidelines, requiring XHTML 1.1, as is?
OR
- Upgrade and modify the existing guidelines, requiring XHTML 1.1 but allowing some exceptions?
I do have a preference, but I think I’ll keep it to myself for the time being – at least until there has been some feedback from one or two others in the community. If you do comment, I’d like to know the why behind whatever option you chose.
Let the discussion commence!
:-j(enni)