Thanks for chiming in Will.

Your suggestion is very close to the approach I've decided to take. The difference is that the guidelines will recommend XHTML 1.1 following the W3C's Compatibility Guidelines for documents wishing to render in both XHTML-aware and modern HTML user agents but will make XHTML 1.0 Transitional available as an option "if there is an unavoidable need to use elements or attributes that were noted as deprecated in HTML 4.01".  There will also be a list of deprecated elements and attributes for presentation that will be restricted from use, even when conforming to XHTML 1.0 Transitional. With the possibility that some output will only comply to the XHTML 1.0 Transitional DTD, the guidelines will require that pages include that DOCTYPE statement.

We ultimately want to push the community towards a stricter standards compliance and the practice of separation of format and style, but have to accept that the XHTML 1.1 standard contains certain flaws that may be avoided by using XHTML 1.0 Transitional. So this approach is a good compromise between these two issues as it encourages movement in the direction we want to take them but doesn't limit functionality unnecessarily.

:-j(enni)

---

Jenni Merrifield
strawberryJAMM Designs
User Experience Design Specialist
"Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity."
- C. Mingus

IMHO the style guide should be an aid to module developers and skinners, whether or not they adhere to all the recommendations in the style guide is another matter. From Timo's experience, not all module developers have standards on their radar.
But if you put in requirements that are not realistic in a practical surrounding, there is a chance that the whole document gets dismissed, and we do not want that to happen.

Peter.

---

Peter Schotman
Cestus Websites voor DotNetNuke oplossingen in Nederland
Contact us for your custom design and skinning work.

That's exactly right, which is why the Style Guide's primary audience is the developers and designers working on components that ship "out of the box" (i.e., in the official DNN packages) and third party developers and designers are only its secondary audience.

Members of the primary audience (DNN Corp and Community Team developers/designers) will be required to make new or modified components meet these guidelines at the strictest level possible. Over the long term, these guidelines will evolve with the standards and best practices and developers/designers working on DNN directly will continually be pushed to meeting the most current ones.

Members of the secondary audience (third party developers and designers) will have access to the Style Guide so they will understand how the DNN UX will be changing going forward. These people will be encouraged to follow the guidelines in their own projects Submitbut they will not be required to do so.

:-j(enni)

---

Jenni Merrifield
strawberryJAMM Designs
User Experience Design Specialist
"Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity."
- C. Mingus