Moving to HTML 5
August 13th, 2009
Today I’m making the grand leap of moving, where possible (i.e., when I have time … ha!), over to HTML 5. The future is now.
I was pushed over the edge when I peaked at the code for John Resig’s site. I looked again at the differences between HTML 5 and HTML 4. I looked again at how HTML 5 differs from XHTML. I looked again at the vexing problem of application/xhtml+xml.
And then I looked at an example HTML 5 document:
<!doctype html>
<html>
<head>
<meta charset="UTF-8">
<title>Example document</title>
</head>
<body>
<p>Example paragraph</p>
</body>
</html>
The clouds parted and a Voice said, “Move, little one. Move.”
Looking at Resig’s code, has the charset declared as <meta http-equiv="content-type" content="text/html;charset=utf-8"/>. The draft says:
Using a meta element with a charset attribute that specifies the encoding as the first element child of the head element. could be used to specify the UTF-8 encoding. This replaces the need for
I ain’t picking on Resig, honest. I follow his lead and I think it’s useful (understatement) to compare his work to what the WHATWG suggests. I’d be curious to know, then, (if he hasn’t already blogged about it), why he retained use of the previous charset declaration. Well, for starters I could guess: it doesn’t harm anything.
Other great ironies: the HTML 5 spec page uses an HTML 4 doctype as does the HTML 5 and 4 differences page. I suppose they’re sticking to W3C recommendations until the HTML 5 draft becomes a recommendation.
And who else is on board? Google (peak at their code). Apple. Microsoft.
Anchorage and Pseudo-Anchorage
February 24th, 2009
I have what a former professor of mine called fear of the “fraud squad.” Today’s example: if someone looking at my CSS asked me to articulate the difference between a and a with the :link pseudo-class, i.e., a:link, could I explain the difference? Or would I throw out a useless definition and then hear the fraud squad busting through my office windows from their black helicopters?
I couldn’t articulate the difference but can now. The venerable W3C states that browsers use :link and :visited to distinguish between links that have not or have been visited. Also, these pseudo-classes are mutually exclusive. So, what’s true for a:link will never be true for a:visited, and vice versa, but if you define a style for a, it will be true for both.
About pseudo-classes: a layman’s definition of a pseudo-class is hard to find, but 456 Berea Street has a blog entry on pseudo-classes that’s helpful.
If you were wondering …
February 5th, 2009
$( ‘#white_house’ ).addClass( ‘validates jquery’ );
January 20th, 2009
I was pleased to see that whitehouse.gov passes W3C XHTML validation and uses jQuery.
jQuery and … Microsoft?
September 29th, 2008
John Resig announced today that “jQuery will be distributed with Visual Studio.” Scott Guthrie, a Corporate Vice President in the Microsoft Developer Division, talks more about “adopting jQuery” in his blog.
I hope Microsoft doesn’t begin to hover over jQuery like this:
Firebuggin’ (to steal an entry title)
July 21st, 2008
John Resig, JavaScript Evangelist for Mozilla and the creator and lead developer of jQuery, announced today that he’ll be “driving the direction of the brand-new Mozilla Firebug team” (read more).
Where would we be without Firebug? Resig himself notes that there are “trends in web development that Firebug has single-handedly revolutionized.” And that might even be an understatement.
The XML Prolog
July 16th, 2008
If you’re serving an XHTML file, the W3C states: “XHTML document authors are strongly encouraged to use XML declarations in all their documents.” The XML declaration, in this case being the dreaded XML prolog: <?xml version='1.0' encoding='utf-8'?>. But, it’s really not so dreadful unless you’re using PHP. The server-side PHP processor sees the <? and starts to process the XML prolog as PHP code, which it isn’t. This throws an error like:
Parse error: syntax error, unexpected T_STRING in /foo/index.html on line 1
Zeldman says avoid the prolog and use the metatag: “specify character encoding by inserting a Content-Type element into the
of your document.” But, this isn’t what the W3C says to do and I always waffle: follow the W3C and risk breaking a website or don’t follow the W3C and fail at compliance.One work around of the PHP problem is to echo the XML prolog:
<?php echo "<?xml version='1.0' encoding='utf-8'?>" ?>
That’s what I’m doing for now. It follows W3C recommendation, let’s the page work with PHP processing and doesn’t require reconfiguration of PHP settings like short-open-tag.
Forums abound where people recommend abandoning the XML prolog altogether (usually for IE6 quirks mode reasons), but I’d prefer to go the standards route wherever (humanly) possible. And since the death of IE6 (Microsoft’s IE6 page directs you to download IE7), going the standards route is getting easier.
application/xhtml+xml?
July 14th, 2008
There’s a mini-war over what MIME type to serve XHTML as: either application/xhtml+xml or text/html.
First, a definition: MIME stands for Multipurpose Internet Mail Extensions. Even thought HTTP is not email, “HTTP requires that data be transmitted in the context of e-mail-like messages, even though the data may not actually be e-mail” (see the W3C protocol). MIME types are usually defined in the server’s .htaccess file. In a (fragile) nutshell, serving a file as either application/xhtml+xml or text/html tells the browser what to do with it: treat the file as XML (a standard with strict coding guidelines) or HTML (a standard with looser guidelines).
What this means is that an invalid, i.e. not strictly coded according to XML guidelines for well-formed documents, XHTML document gets chewed up and spit out by the browser as, well, broken. As James Edwards puts it: “the strictness of a validating XML parser may be too extreme for real-world use. For an invalid XML document, browsers did not even make an attempt to parse the document as best they could, as they would with HTML—instead, they just displayed a validation error and stopped.”
There’s a significant group of developers and other groups who argue that XHTML should only be served as application/xhtml+xml. The list: Ian Hickson, Anne van Kesteren, Mark Pilgrim and the WebKit team. The W3C makes it clear as well: XHTML documents should be served as application/xhtml+xml.
I’m working on a large web application that, from the beginning in 2007, has been using XHTML 1.0 Strict DTD served as text/html. Given the above links and recommendations, this is wrong. But, as Hamlet said, “there is nothing either good or bad but thinking makes it so.”
Other developers have taken the stance that serving XHTML as text/html is fine. Brad Fults, for example, finds Hickson’s argument, “wholly unconvincing” and details why. For example, “the biggest advantages to XHTML are its readability, uniformity, well-formedness as it pertains to authoring, and the consistency of the rendered DOM (which is also a result of any well-formed HTML document).” XHTML Validation, then, is the author’s responsibility, but not a burden on the browser, which (when serving as text/html will render the page as HTML. Fults again:
Is there a harmful issue here? No. Whether or not documents validate is a completely separate issue from the MIME type as which they are sent. It is up to authors alone to worry about validating their documents with a validator.
Back to James Edwards, he takes a stance that it matters, sort of. Serving as text/html ensures that users get a readable webpage even when code might be malformed or not supported by the browser. To lean on his phrasing, an XHTML page served this way can fail cleanly.
I’ve written all this up to determine what a project I’m working on should do in terms of DTD and MIME type. Right now, I’m working on Puma, a network device visualization web application that acts as a detailed catalog of nearly 15,000 devices (routers, switches, APs, etc.). Serving the application as application/xhtml+xml, in no uncertain terms, breaks it. Somewhere in the thousands of lines of code, there’s malformed XHTML. Maybe. As a device page starts to build, a small portion of it succeeds, but at a certain point early in the process, it borks. I’m curious if it’s a JavaScript problem. A lot, maybe 95% or likely more, of the page is built by jQuery and JavaScript that relies on a JSON document for content. It seems as if when the JSON document comes into play, the borking begins. But I could be wrong.
To sum up, I’m going to continue serving Puma as text/html until the borking can be pinpointed. This way Puma can fail cleanly and still take advantage of the well-formed document structure XHTML demands.
The Cone of Uncertainty
July 11th, 2008
When contemplating why I’m a designer (I really do love kerning, well, really tracking even more), I stumbled across this three-part blog entry, Designers Hate Estimating, about the problems of estimating a project’s cost and time.
David Sherwin references an article on “The Cone of Uncertainty” and I think the gist of the problem can be tackled by the imperative: “determine what you don’t know.” Most of the rest of his blog entry relates better to the sort of work I used to do–commercial work with new clients, not web application design for repeat clients that are in-house and technically savvy and generally do know what they need. But still, in terms of estimating generally, it’s a useful read.
Bad New Window, Bad
June 27th, 2008
Since 1999 (if not before), when Jakob Nielson declared opening a link in a new window evil, usability experts, web developers and the like have followed suit and followed the practice: don’t open links in new windows.
One page I found on spawned windows writes that, “Usability studies show that novice users (including those without disabilities) often do not understand the concept of stacked windows and think only one window is open at a time.” I’d agree with this, but I’ve tried to find the studies this page references and I’ve yet to find them. If anyone has found them, knows where they are, please do leave a comment.