With support in Chrome, Firefox 3.5, Opera, and Safari, HTML 5 is coming at you like a runaway train. Here are some suggestions to help you prepare to get on board rather than be left at the platform or tied to the tracks.
See what others have done#section2
The first thing you can do to prepare for HTML 5 is see how other people are using it. A visit to the HTML 5 gallery will show you how several sites are already using the new HTML 5 elements. Use the source, Luke!
Now you do it#section3
You can look at the sites, read all the articles here and elsewhere, and even read the specification—but none of that will help you understand HTML 5 as much as using the new elements. You can modify part of an existing site or experiment by creating new pages. I did this myself by updating a trip report I made for friends and family. (I never intended it for public display, but here it is.)
By doing this, you’ll find out what works and what doesn’t. For example, I discovered that, as of this writing, Firefox 3.5 treats elements like article and section as display:inline, and I had to explicitly set them to display:block to make them work as expected.
X marks the spot#section4
If you are like most designers, you probably don’t write all your markup by hand. But until the tools you use catch up to the new elements in (X)HTML 5, you will be doing some markup by hand while you learn. There’s been a bit of confusion (and controversy!) about the relationship between HTML 5, XHTML 1.0/1.1, and XHTML 5. Let’s clear that up right now.
HTML 4.0 (the markup language we all know and love) is based on a “rulebook” called SGML. In the SGML rulebook, element names are not case sensitive, you can have elements with optional closing tags (like <p>), and you can have attribute values without quotation marks. XHTML 1.0 and 1.1 are based on a rulebook called XML. In the XML rulebook, element and attribute names are case sensitive, every opening tag must have a closing tag, and attribute values must be quoted.
HTML 5 defines a markup language that isn’t based on either rulebook, but that can be written in either “HTML form” (or serialization, as the spec calls it) or “XHTML form.”
When you write markup in HTML form, you are allowed to leave off some closing (and opening!) tags, you don’t have to quote attribute values if they don’t contain blanks, and element and attribute names aren’t case sensitive. You also get to use some of the XML markup; you can have a trailing slash on elements like <img /> or <hr />.
When you use the XHTML serialization, you have to follow the XML rules mentioned a few paragraphs ago.
I suggest that you write your markup in XHTML 5, or, if you use HTML 5, do the markup as if it were XHTML. You will be better off staying with the XML standard that requires a closing tag for each opening tag rather than spending your time optimizing markup for tags that have optional closing and/or opening tags. Similarly, quote all your attribute values rather than trying to decide when you can leave the quotes off. In addition to not having to waste neurons on those decisions, your markup will be more consistent.
Once the automatic markup generation tools catch up, you may still want them to generate XHTML 5 rather than HTML 5. Use of XML is forward-looking; its namespaces allow you to have “polyglot documents” that consist of multiple markups beyond the RDFa, MathML, and SVG of HTML 5. You can also use tools such as XPath, XSLT, and XQuery on XML-based markup, using any XML parser of your choice (though there is a Java-based parser that will process plain HTML 5).
Of course, it’s not all good news. If you do go with XHTML 5, remember that your server must deliver the documents with a MIME type of application/xhtml+xml or text/xml. This may involve negotiation with your hosting service. Also, when you deliver an XML file, any syntax error will cause an error message.
Fig. 1. XML parse error for mismatched tags.
If you are doing markup by hand, think of these error messages as a way to keep you honest. If you are using tools that create XHTML, there is no problem; the tools should always produce well-formed XML.
Regular expressions#section5
HTML 5 extends the input element by offering new attributes that allow you to specify what data you will allow as input. These attributes include min and max (to set a numeric range), and HTML 5 also offers new values for the type attribute, such as url, email, date, and time.
If none of these new input types suits your needs, HTML 5 provides the pattern attribute for input elements with type="text". The value of the pattern attribute is a regular expression, as defined in ECMAScript and used in JavaScript. Regular expressions are a concise and perhaps somewhat cryptic way of specifying a pattern of characters. For example, if I want to match a five-digit or nine-digit US ZIP code or a six-character Canadian postal code, I can use this pattern:
([0-9]{5}(-[0-9]{4})?)|([A-Z][0-9][A-Z]\s+[0-9][A-Z][0-9])
The new web form capabilites are partially implemented in Safari and Chrome, and completely in Opera (see this site for browser capability information). Don’t worry if your browser does not yet support the form extensions for HTML 5; you can download Google’s Web Forms 2 and off you go!
Here is a sample form that validates a date and a postal code:
And here is the relevant markup:
<p>
Enter a date: <input type="date" name="day"
required="required"
title="Use format yyyy-mm-dd" />
</p>
<p>
Enter a US or Canadian Postal Code:
<input type="text" name="postCode"
required="required"
pattern="([0-9]{5}(-[0-9]{4})?)|([0-9][A-Z][0-9]\s+[A-Z][0-9][A-Z])"
title="US: 99999-1234; Canadian: 0A1 B2C" />
</p>
Regular expressions are well worth the time it takes to learn them. Many text editors offer integrated regular expression search-and-replace features, and once you start using them, you’ll wonder how you ever got along without them.
Static art with SVG#section6
Fig. 2. Image of SVG showing colored shapes.
If you want the crisp edges of vector-drawn art, HTML 5 allows you to embed SVG (Scalable Vector Graphics) in your documents. Putting SVG inline is partially implemented in Firefox, Safari, and Opera, according to this site.
You can already link to an SVG file in Firefox 3.5. That graphic is a bit complex—here’s a much simpler one (see Fig. 2) showing some simple colored shapes.
And here’s the SVG that generates it:
<svg xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
viewBox="0 0 200 100"
width="200px" height="100px">
<circle cx="50" cy="50" r="30"
style="stroke:none; fill:#ff0000;"/>
<g transform="translate(100, 20) scale(1.65)">
<polygon points="36 25, 25 36, 11 36, 0 25,
0 11, 11 0, 25 0, 36 11"
style="stroke:none; fill:#0000ff;" />
</g>
<rect x="60" y="20" height="60" width="60"
style="stroke:none; fill:#00ff00;
fill-opacity: 0.5;" />
</svg>
While it is possible to use JavaScript to dynamically modify an SVG graphic, HTML 5 provides a better solution:
The blank canvas#section7
The canvas element is one of the most exciting features of HTML 5, and it’s supported by Firefox, Safari, Opera, and Chrome—but not Internet Explorer. (Color me surprised.) The canvas element is truly a forward-looking feature. You use JavaScript to draw whatever you need on this (literally) blank canvas.
Here’s the same graphic as the SVG graphic, only on a canvas:
And here’s the JavaScript that created it (with multiple statements per line to save space):
function drawSimpleCanvas() {
var canvas =
document.getElementById("simpleCanvas");
if (canvas.getContext) {
var ctx = canvas.getContext("2d");
ctx.beginPath(); // the circle
ctx.fillStyle = "#ff0000";
ctx.arc(50, 50, 30, 0, 2*Math.PI, true);
ctx.closePath();
ctx.fill();
ctx.save();
// move and resize the octagon
ctx.translate(100, 20);
ctx.scale(1.65, 1.65);
ctx.fillStyle = "#0000ff";
ctx.beginPath();
ctx.moveTo(36, 25); ctx.lineTo(25, 36);
ctx.lineTo(11, 36); ctx.lineTo(0, 25);
ctx.lineTo(0, 11); ctx.lineTo(11, 0);
ctx.lineTo(25, 0); ctx.lineTo(36, 11);
ctx.closePath();
ctx.fill();
// restore graphics as they
// were before move and resize
ctx.restore();
ctx.fillStyle = "#00ff00";
ctx.globalAlpha = 0.5;
ctx.beginPath();
ctx.rect(60, 20, 60, 60);
ctx.closePath();
ctx.fill();
}
}
Here is a <canvas> that demonstrates simple user interaction:
Normally, you will use a canvas to display graphics that support your content. For example, saying “the mean of a set of numbers is the ‘center of gravity’ of that set” is fine, but using a canvas element with associated JavaScript to let the reader enter a set of numbers and show her that the mean is the “balance point” is much more effective.
These examples don’t even begin to show the scope of the canvas element’s capabilities. See Mozilla’s Canvas tutorial for a more thorough introduction as well as links to examples.
What are you waiting for?#section8
Although some developers have reservations about the direction in which HTML 5 is taking the web (and although I share these reservations), HTML 5 has enough new and interesting features to be well worth exploring. So, start looking at other people’s markup, experiment on your own, and go wild with the new form validation and canvas features.
I have to say I’m quite looking forward to getting to grips with HTML 5. It looks like the next logical step and I think with a bit of time to learning it it will be really good to use. Especially the form validation options!
The html 5 gallery examples were quite good as well. I always find it useful to see working examples.
Great article as always!
Being a webdesigner for more than 10 years now, I studied the HTML5 spec intensivly over the past year. And I followed the discussion on the WHATWG list. I played with it a bit and I have come to the conclusion that I hate it.
The spec is bloated, inconsistent and it adds possibilities to HTML that break the rule that HTML is for markup only.
After some discussions, the WHATWG list itself admitted to me that HTML is nothing more than a hooking language (for styles and scripting).
Nothing added to HTML5 cannot be done with the existing HTML with or without some scripting. It adds next to nothing in terms of accessibility.
Do not forget that HTML5 started out as WebApplications. And that is what it seems to be, yet another addition to web development, and NOT web design. Why? Isn’t ruby, ajax, flash, etc. etc. enough? Again, I have yet to see anything in HTML5 that cannot be done with any of the above.
For the first time ever, I am glad IE8 doesn’t include any HTML5 (AFAIK). So, it will be a while until it becomes the standard.
And before then, I hope someone will have invented a better way of creating websites.
We will just have to play the cards we are dealt I guess, but I don’t have to like it.
I think you need to be a little clearer when recommending people use XHTML5. I didn’t see any mention of the fact Internet Explorer does not support proper XHTML 1.0 let alone XHTML5 (or HTML5).
Also your reasons for using XHTML5 over HTML5 are fairly weak. There’s nothing stopping designers/developers from creating well formed, well considered HTML5 and certainly no need to “think” about it any more than when creating XHTML5.
Cool stuff, but none of the examples on the page work. I think you might be missing a js file to define the show_ok(), displayData(), etc functions.
There has been much talk about HTML 5. I am looking forward to try it now. Thanks for the brilliant article.
Serving XHTML up with the proper MIME type is really a futile effort, especially when you’re in a multi-user development environment (or heaven forbid you have a content management system).
In these two situations having your pages validate 100% of the time just isn’t feasible and when Firefox gives you the ‘yellow screen of death’ it doesn’t help your end-users very much.
It is possible to serve XHTML to IE using XML as seen here – http://www.nealgrosskopf.com/tech/thread.php?pid=1
HTML 5 has become my new standard and favorite language very fast, but I still did not know everything about it—for example the new attributes of the input element which seem quite interesting. And as you said, the canvas enables some great possibilities even though IE cannot display it. I will have a closer look at it. Thanks for this article!
bq. Cool stuff, but none of the examples on the page work. I think you might be missing a js file to define the show_ok(), displayData(), etc functions.
The problem has been fixed. Thanks!
Hi, I just found this page – and -> i love it.
The articles are great I really enjoy reading.
Keep on doin a great job!
bq. the canvas enables some great possibilities even though IE cannot display it.
There may be a solution for you at “explorercanvas”:http://code.google.com/p/explorercanvas/ ; I haven’t experimented with it.
I can’t seem to get enough of HTML5. Great article, especially the demos of canvas & javascript elements. Thanks!
Shouldn’t this article be using the standard name of “HTML5,” with no space? I think that needs to be an important part of articles like this that introduce HTML5 to new people.
Thanks for a great article — it was an education. One little nit:
([0-9]{5}(-[0-9]{4}))?|([A-Z][0-9][A-Z]s+[0-9][A-Z][0-9])
should be changed to:
([0-9]{5}(-[0-9]{4})?)|([A-Z][0-9][A-Z]s+[0-9][A-Z][0-9])
the first time the regex appears in the arcticle. Your code example has it right.
I see a lot of potential in the svg vectoring. I think that we will see come really cool designs implementing this without eating up much bandwidth!
bq. Shouldn’t this article be using the standard name of “HTML5,” with no space? I think that needs to be an important part of articles like this that introduce HTML5 to new people.
Until last night, official documents at WHATWG and the W3C referred to the specification as both “HTML 5” (per normal W3C styling; see “HTML 4”) and “HTML5” (the original WHATWG styling). There was no standardization of the name.
Following the publication of the “HTML5 Super Friends”:http://www.zeldman.com/superfriends/ documents and related blog posts yesterday, Hixie fixed the inconsistency in the WHATWG version of the specification, so that at least one of the two working groups now has a consistent standard name: HTML5, with no space.
But “HTML 5” is still the correct name on the W3C’s version of the same specification (and the W3C refers to it as both “HTML 5” and “HTML5” with some randomness in that document).
bq. ([0-9]{5}(-[0-9]{4})?)|([A-Z][0-9][A-Z]s+[0-9][A-Z][0-9])
This has been fixed. Thanks!
One thing that I don’t believe that this article fully explained that I see as a common misconception is that many people believe that if you use HTML5 instead of XHTML5 your elements must not have the closing slash on self-closing elements. This is absolutely not the case. You may self-close elements.
I’ve seen people torn on this because they like having the self-closing elements, but do not/can not serve a page using the application/xhtml+xml MIME type.
That said, I have absolutely no idea how to write a META tag that is both HTML4/XHTML1 and HTML5 compatible for Content-Type/charset that serves the same purpose. Am I mistaken in that HTML5 requires the use of the http-equiv format and HTML4 can use either http-equiv or name?
You mention in you article that HTML 5 has support for numerous other XML-based markup languages (such as SVG, XPath, XSLT, etc.) but that HTML 5 can be written according to the HTML “rulebook” or the XML “rulebook”. Surely it would be best to stick to the XML rules if you intend on embedding SVG graphics for example?
(Unless it’s possible to embed SVG in a document that only complies with the HTML rules…)
Thanks for a great introduction to HTML 5. I have several projects coming up in the next few months and I may experiment using it in one these.
Nice article 🙂
bq. (Unless it’s possible to embed SVG in a document that only complies with the HTML rules”¦)
Quick experimentation shows that Mozilla 3.5 doesn’t display the SVG unless the file ends in .xhtml (when loaded locally) or served as xhtml+xml from the server. In either case, the document has to follow XML syntax. Also, if I don’t add the xmlns=”http://www.w3.org/1999/xhtml” attribute to the <html> element, paragraphs show up as inline rather than block elements. YMMV with Opera or Safari.
As somebody said before HTML5 is really about web applications with all of its extensions to AJAX requests, new web forms, dedicated tags, offline storage, etc.
But it’s really nothing wrong with this as HTML4 wasn’t created to describe web applications but static web pages, so something new like HTML5 is definitely needed. One will be able to create the same static or semi-static pages with HTML5 as with HTML4 so really nothing will change there. Plus browsers will still support HTML4 in the coming 20 years so there’s really nothing to worry about.
From my perspective I found HTML5 features really interesting as WebKit, Gecko and Presto rendering engines already catched up with the drafts but there’s a serious problem with lack of HTML5 features in IE8 and a serious need for yet another set of hacks.
Recently I rewrote “my website”:http://edge.jakubpawlowicz.com/ with a couple of HTML5 technologies inside and so far I’m very happy with the overall effect.
@Jakub: That somebody was me. And let me clarify a bit more. HTML is (the name says it all) a MarkUp Language. As such, HTML401 was lacking in some respect in doing a good job of that, but all in all it at least tried to keep itself HTML.
HTML5 is heralded as the new HTML. I say no. Because when you look purely at the Markup side of this new spec, you will see that HTML5 gives us very little more and very little improvement over HTML4.
On the other hand, it does give us a lot of things that are not Markup. One may argue that these non-markup things are an improvement; at the very least they are fun. But what are they? Not markup. In fact, they are more like scripts built into the browser.
So HTML5 is only partly HTML, and that part is seriously lacking in good improvements as far as I can tell. HTML5 should have been called HTML4.5 and the non markup stuff should have been called DOM4 and WebApp1 resp.
When I want a meter on my site or graphic abilities, I’ll use existing technologies like JavaScript, Ruby or -if worse come to worse- even Flash. And when I want accurate date formatting or logical separation of my content I’ll use PHP and MySQL.
Look, I don’t want to rant or put the whole thing down. It’s fine. I just think that all these people who were working on this spec have done a great job, that has cost a lot of effort, energy, money and creativity that could have been used more productively in my personal opinion.
Html 5 is fun, great and I guess ‘wow’, but also very superfluous for us daily web workers. We are all but prisoners of IE and outdated CMS systems for many years to come. We only gaze in wonder to all this beautiful novelty from outside and hope in our dreams that once we will all be able to escape from IE-Alcatraz. Oh, beautiful, senseless progress. Thank you for the addictive sense of probably nothing more than false hope. But hope must be. So write on guru people! Infuse us with your dangerous naive believes in better times and smooth techniques. For the walls of our prison are digital and our terabyte memory is packed with thousands of paradise promising examples of supercode. Hell yes, we are always ready for a new dose! We are all addicts. More, more!
Fantastic article David, thanks a million for that – i must bookmark this page and have a right good read of this when I have more time.
This article seems to insinuate that Canvas is a “replacement” for SVG. It is not. I wrote about the http://nimbupani.com/blog/bit-of-svg-and-canvas.html
This article also does not mention the lack of accessibility of the Canvas element. http://is.gd/373vb
You would have thought that editing and maintaining a webpage would have become, much, much easier with the 5th incarnation of HTML.
Well, look at the examples in this article, if that doesn’t put you off to ever venture into the websphere I don’t know what would! IT has become less and less human over time, and IT professionals should be ashamed of the mess they put us up with. SVG or canvas, really, COME ON! It should be as easy as drawing a circle in OmniGraphle.
So far, HTML5 leaves me very cold, except for better form handling and validation (thank you!) and easier embedding of multimedia content, but the missed opportunities outnumber the nerdy innovations and that’s a shame.
This is a good article. It’s been very interesting to see the response to the HTML5 proposal. It has really split web developers/designers. Some are excited and desperately want to start implementing this technology, others are very hesitant and critical.
The fact is, the days of static web pages are numbered. A vast number of web developers/designers have been happily churning out static HTML web sites that are easy to produce. The push towards HTML5 means that clients are increasingly aware of new, more interactive technologies and so it means the developers/designers need to step up to the mark.
Web apps are increasingly becoming the standard across the web, and the consumer browser experience is changing. No longer do companies simply have a static business card website, but they have an immersive site where social media can connect and the user has control over the format, style and even choice of information received.
The answer to ‘making a website’ has changed dramatically over the past 10 years and HTML5 is a great step forward to the web app environment that is so desperately needed. This will, however, mean that the web community will need to learn HTML5 and step up their game.
Thanks for this. I’ve been a bit remiss in coming up to speed with HTML 5.
Thanks also for the server MIME tip; this is the kind of thing that promises to make you crazy if you didn’t know it was necessary. 🙂
WOW HTML5, cool, exciting *snore*.
By 2022 IE7 may have just about been laid to rest, if were lucky IE6 will be gone (or I’ll have made it a personal mission to hunt IE6 users with a machine gun). If were lucky IE 9/10 will be CSS3 compatible and will be able to parse XHTML 1.0 + XHTML5 (+html5).
Of course we can all laden our pages with large JavaScript libraries that will sit there and re-parse our html5 into html at the expense of memory and processing, rendering time, the additional strain placed on the JavaScript engine and of course the inevitable reduction in browser speed as the JS engines fail to handle >80% of the garbage collection… we could do that, or we could carry on building web pages with xhtml and javascript for progressive enhancement.
I’m all for development but the HTML5 buzz is just bloody ridiculously over promoting its existence before a decent specs even been pushed out. People rushing to build their sites in HTML5 just because Zeldman thinks its fantastic (note his page is xhtml & transitional at that, and wordpress too).
Play with it, test it, and see what’s happening with it but remember that even when the spec is out and its up and running in 2022, it will be up to a decade after before the specs used properly, and that’s assuming people bother to use it!.
I’m glad that a lot of web standards are being incorporated into CSS (it certainly cuts down on a lot of graphic work needed to achieve the same functionality), but at times I find it useless when most people are still using Internet Explorer, and IE is so behind in the times as well as having random compatibility issues.
I’d love the day when I don’t have to code fixes for Internet Explorer, but when I look at my browser statistics, I’m not sure when that will be.
Definitely looking forward to XHTML 5. I know that there are ways to do things in other languages that HTML5 now gives us the capability to do, but the point is that HTML5 will make it easier for us. Embedding SVG alone will make me a happy camper. Style and markup will still be separate despite what others say. More importantly the form validation should definitely be a part of the attributes in the input tag, not in another script. The submit scripts should only be used in handling, delivering, and or manipulating the data. Not to mention this will save me quite a bit of time with ifs, empty()’s, &&, XOR, ><, ||, etc.. etc.. Thanks for the inspiring article. Can't wait to start playing with it.
What I’d like to see is some things that were put forward in XHTML 2.0.
The href attribute turning any element into a link and src tuning any element into an image. Lovely navigation list with only two (
) tags and three attributes (id, src, and href) per link instead of five tags (
) and four attributes (id, src, alt, and href), here I come.
The element. Yes, I’d love to see just a generic header element when I want a header for something that does NOT fit into a normal outline.
I have my doubts about html5, its being pushed as a flash killer and it doesnt enable you do everything flash does even though it solves a good percentage of it, there is still going to have to be solutions there. If its used with Javascript constantly your going to have tons of code and conflicts. Not only that but it will be many years before the spec is even complete and in use and adopted by all browsers meaning it will be useless until it is. They do some things right but it has a LONGGG way to go and while it may solve some problems, it sounds like it will create new ones.
I have gone trough both HTML 3 and table design and its really time to start some new standards to serve website visitors a much more interesting interactive experience. I have also tried HTML5 and its not as difficult as i thought, new components due to an easier way to use it and faster development situation.
Media implementation should be very good so it will be competitive to the SEO useless Flash technology.
I am looking forward to be more technical complicated in order to serve nicer and better experiences…
Clevelick Flash isnt actually useless to SEO, Google catalogues flash if its built right.
While it’s true that HTML5 in the desktop/laptop realm is not an implementation option at present, in the mobile space it is ready for prime time. AFAIK, >90% of the smart phone browsers understand HTML5 and this is a significant and fast growing segment of users. Many IT departments are beginning to realize that a mobile-optimized website is something that they need and are reaching out to developers for this service, and the solution is going to incorporate HTML5. Yes, corporate IT departments who don’t want to upgrade their desktop browsers from IE6 are not going away anytime soon (although IE9 promises as robust an HTML5 experience as the best of them), but those same folks who use Blackberries WILL be able to see HTML5 mobile-optimized sites, not to mention the millions of iPhone, Android, Palm and iPad users out there. So maybe the importance of the mobile web will accelerate these critical changes in the more traditional browser realm? Here’s to hoping!
All these new features are interesting – but is there any compelling reason to upgrade an existing website to HTML5?