Serving the Correct MIME Type for XHTML

Posted on Wed 01 November 2006 in XHTML

"Work In Progess"

This article is work in progress. It will be expanded upon and become more reader friendly - at the moment it is just a brief list of my ideas.

This is a topic of much debate, but I have decided on my strategy.

  • XHTML has a much stricter markup than using HTML 4. This is one of the most appealing aspects of using it. If you decide to use it you must abide by the rules.
  • I wish to use XHTML, but also want it to be as compatible as possible with older browsers (if compatibility with really old browsers is of the utmost concern, you should probably stick to HTML 4.01 Strict).

Serving up XHTML:

  • Use XHTML 1.0 (Strict / Transitional). XHTML 1.0 should be served as application/xhtml+xml, however it may be served as text/html. Any version of XHTML later than 1.0 should not be served as text/html.
  • Serve as application/xhtml+xml to user agents which support it (e.g. Mozilla FireFox, Opera).
  • Serve as text/html to user agents which do not specify acceptance of application/xhtml+xml, but do accept text/html (e.g. Internet Explorer).
  • Serve as application/xhtml+xml (i.e. as it should be) to user agents which do not specify acceptance of text/html (e.g. the W3C Validator).
  • Using ASP.NET 2.0? See: Serving the Correct MIME Type for XHTML using ASP.NET 2.0.

Implications:

  • Use UTF-8 character encoding.
  • Only add the <?xml version="1.0" encoding="UTF-8" ?> declaration if serving as application/xhtml+xml. It should normally be included, but is not required when using UTF-8. Because IE6 switches to "quirks" mode when this is included, omit when serving as text/html.
  • Only add the <meta http-equiv="content-type" content="text/html; charset=UTF-8" /> element if serving as text/html.
  • Mark all <style> and <script> contents as CDATA (using the backwards-compatible method). See: Marking Script and Style as CDATA.
  • Follow the XHTML 1.0 Appendix C HTML Compatibility Guidelines.
  • Stick to the 4 XHTML Safe Named Entities: &lt; for <, &gt; for >, &amp; for &, &quot; for ". &apos; for ' is not supported in IE6. For this and all others use numbered entities (e.g. &#39; for ').
  • Check that all your JavaScript works. You can't use document.write() or innerHTML (this is from my reading and is unchecked/tested).
  • Make sure you style the <html> element, as the <body> element doesn't cover the entire viewpoint.
  • Validate, validate, validate! Make sure your XHTML is perfect, and that your pages work in a multitude of browsers.

Marking Script and Style as CDATA

Posted on Wed 01 November 2006 in XHTML

When using XHTML, the contents of <script> and <style> elements must be marked as CDATA. This is essential when serving XHTML correctly (as application/xhtml+xml).

When possible, use external script and style files and reference these from your XHTML document (behavioural and presentational separation). However, the examples below show how to place <script> and <style> inside your XHTML document correctly. This method should be compatible with older browsers, and therefore degrades gracefully.

Marking <script> as CDATA:

<script type="text/javascript">
  <!--//--><![CDATA[//><!--
    ......
  //--><!]]>
</script>

Marking <style> as CDATA:

<style type="text/css">
  <!--/*--><![CDATA[/*><!-- */
    ......
  /*]]>*/-->
</style>

ASP.NET 2.0

If you are serving ASP.NET pages as application/xhtml+xml (see Serving the Correct MIME Type for XHTML using ASP.NET 2.0 ), then the automatically generated JavaScript will not be marked as CDATA, and will therefore not work. For a workaround see: Marking ASP.NET 2.0 Generated JavaScript as CDATA.

The Importance of Standards Compliance and Accessibility

Posted on Wed 01 November 2006 in XHTML

The aim of this article is to underline the importance of standards compliant web pages in promoting usability, compatibility, and accessibility - therefore allowing equal opportunity and equal access to content for all.

A History of Non-Compliance

When Netscape lost the "Browser Wars" in April 2002, Internet Explorer was in complete dominance of the web browser market - with a 96% share (source: OneStat.com). For web developers at the time, this meant that designing for Internet Explorer was all that mattered. The dominance of a single web browser led to a disregard for standards compliance.

  • Accessibility & usability problems when sites were accessed using other browsers.
  • Decreased efficiency due to increased file sizes, and website code not following a standard set of rules.
  • Misuse of HTML as a design tool.

The Benefits of Standards Compliance

The number of different ways to access the internet are increasing. Some of the less common user agents include:

  • Mobile phones
  • Televisions
  • Text-mode browsers
  • Text-to-speach synthesisers
  • Braille browsers
  • Robots (such as search engine spiders)

Standards compliance can be seen as a way to "future-proof" a website. New browsers will still correctly render websites constructed using past standards.

In the United Kingdom and Australia, accessibility is the law. The implementation of standards is a vital step towards accessibility. Accessibility benefits those with and without disabilities.

The use of standards is the only way to ensure that a website is accessible by all visitors, no matter how they access the web. By ensuring accessibility you are not neglecting any of your potential visitors.