Steve Albers

  Home  |   Contact  |   Syndication    |   Login
  19 Posts | 0 Stories | 12 Comments | 0 Trackbacks

News

Twitter












Tag Cloud


Archives

Post Categories

Tuesday, March 20, 2012 #

This is the fourth entry in a series of descriptions & demos from the “Using HTML5 Today” user group presentation.


For practical purposes, the original XHTML standard is a historical footnote, although XHTML transitional will probably live on forever in the default web page templates of old web page editors.

The original XHTML spec was released in 2000, on the heels of the HTML 4.01 spec.  The plan was to move web development away from HTML to the more formal, rigorous approach that XHTML offered, but it was built on a principle that conflicts with the history and culture of the Internet: XHTML introduced the idea of Draconian Error Handling, which essentially means that invalid XML markup on a page will cause a page to stop rendering.

There is a transitional mode offered in the original XHTML spec, but the goal was to move to required Draconian handling.  You can see the result by changing the doc type for a document to “application/xhtml+xml” - for my class example we change this setting in the web.config file:

<staticContent>
<remove fileExtension=".html" />
<mimeMap fileExtension=".html" mimeType="application/xhtml+xml" />
</staticContent>

With the new strict syntax a simple error, in this case a duplicate </td> tag, can cause a critical page error:

xhtmlError

While XHTML became very popular in the ensuing decade, the Strict form of XHTML never achieved widespread use.

Draconian Error Handling was one of the factors that led in time to the creation of the WHATWG, or Web Hypertext Application Technology Group.  WHATWG contributed to the eventually disbanding of the XHTML 2.0 working group and the W3C’s move to embrace the HTML5 standard.

For developers who long for XML markup the W3C HTML5 standard includes an XHTML5 syntax.


For the longer, more definitive look at what happened to XHTML and how HTML5 came to be check out the Dive Into HTML mirror site or Bruce Lawson’s “HTML5: Who, What, When Why” talk.


Shims help when adding semantic tags to older IE browsers, but there is a huge range of other new HTML5 features that having varying support on browsers. Polyfills are the tool to work with many of these new features.

Polyfills are JavaScript code and/or browser plug-ins that can provide older or less featured browsers with API support for recent browser advances.  The best polyfills will detect the whether the current browser has native support for a given feature, and only adds the functionality if necessary.  The Douglas Crockford JSON2.js library is an example of this approach: if the browser already supports the JSON object, nothing changes.  If JSON is not available, the library adds a JSON property in the global object.

This approach provides some big benefits:

  • It lets you add great new HTML5 features to your web sites sooner.
  • It lets the developer focus on writing to the up-and-coming standard rather than proprietary APIs.
  • Where most one-off legacy code fixes tends to break down over time, well done polyfills will stop executing over time (as customer browsers natively support the feature) meaning polyfill code may not need to be tested against new browsers since they will execute the native methods instead.

Your should also remember that Polyfills represent an entirely separate code path (and sometimes plug-in) that requires testing for support.  Also Polyfills tend to run on older browsers, which often have slower JavaScript performance.  As a result you might find that performance on older browsers is not comparable.

When looking for Polyfills you can start by checking the Modernizr GitHub wiki or the HTML5 Please site.

For an example of a polyfill consider a page that writes a few geometric shapes on a <canvas>

<script src="jquery-1.7.1.min.js"><script>
<script>
       $(document).ready(function () {
           drawCanvas();
       });

       function drawCanvas() {
          var context = $("canvas")[0].getContext('2d');

	  //background
          context.fillStyle = "#8B0000";
          context.fillRect(5, 5, 300, 100);

          // emptybox
          context.strokeStyle = "#B0C4DE";
          context.lineWidth = 4;
          context.strokeRect(20, 15, 80, 80);

	  // circle
          context.arc(160, 55, 40, 0, Math.PI * 2, false);
          context.fillStyle = "#4B0082";
          context.fill();
</script>

 

The result is a simple static canvas with a box & a circle:

canvas

 

…to enable this functionality on a pre-canvas browser we can find a polyfill.  A check on html5please.com references  FlashCanvas.  Pull down the zip and extract the files (flashcanvas.js, flash10canvas.swf, etc) to a directory on your site.  Then based on the documentation you need to add a single line to your original HTML file:

<!--[if lt IE 9]><script src="flashcanvas.js"></script><![endif]—>

…and you have canvas functionality!  The IE conditional comments ensure that the library is only loaded in browsers where it is useful, improving page load & processing time.

Like all Polyfills, you should test to verify the functionality matches your expectations across browsers you need to support.  For instance the Flash Canvas home page advertises 70% support of HTML5 Canvas spec tests.