An introduction to HTML5

It seems like everyone is talking about HTML5 now, but the discussion is spread out and seldom gives the background, explanation what HTML5 really is and if/when it’s usable.

Therefore, my ambition here is to:

  • Give you a little history
  • Go into what HTML5 is and what it covers
  • Show code examples
  • Target the question whether you can start using it or not


The HTML5 work stems from the WHATWG (Web Hypertext Application Technology Working Group), and their focus is the development of HTML and APIs for web applications. The reason it came to life back in 2004, founded by people from Apple, Mozilla and Opera, was a worry about the direction W3C were taking with XHTML, and no focus on HTML or the real-life needs for web developers.

It got really interesting in July of 2009, when W3C announced that XHTML2 would be cancelled in favor of HTML. This means that the only future development of HTML and XHTML is in the form of HTML5 – HTML5 is the future, whatever you think about it.

I should also mention right away that HTML5 is spelled just that, with no space between the the L and 5 – read more in Spelling HTML5.

What is HTML5

So what is HTML5, really? Basically, it’s about extending HTML/XHTML with new more semantically rich elements, deprecating attributes, introducing new attributes and altering how some element and attributes are allowed to be used. Hand in hand with that is the possibility to use attributes for WAI-ARIA to make a web page more accessible, such as with landmark roles.

It also introduces a number of APIs for making it easier to create web applications:

  • 2D drawing API with the canvas element.
  • API for playing of video and audio with the video and audio elements.
  • API that enables offline Web applications.
  • API that allows a Web application to register itself for certain protocols or media types.
  • Editing API in combination with a new global contenteditable attribute.
  • Drag & drop API in combination with a draggable attribute.
  • API that exposes the history and allows pages to add to it to prevent breaking the back button.
  • Cross-document messaging with postMessage.

Other things that initially was in the specification, but broken out into separate specifications are:

  • API for Geolocation
  • Web Storage.
  • Web Workers.
  • querySelectorAll.

All in all, a lot of nice new things and technology to help us shape the future of the web. As you can see, some of the above things are in the actual HTML5 specification, some others are broken out into their own specifications. Think of it as with AJAX: when that term and hype hit the world, anything that was even remotely related to JavaScript in any way was thought to be AJAX.

Pretty much goes with HTML5: for most people, that’s generally the term you need to imply that you are using new state-of-the-art technologies to create a web site; in reality, that might be “just” HTML with some new semantic enhancements, or it might be an extravaganza with the new APIs in conjunction with JavaScript.

I think the best document to read to grasp the changes are HTML5 differences from HTML4, which will cover:

  • Open Issues
  • Backwards Compatible
  • Development Model
  • Impact on Web Architecture
  • Character Encoding
  • MathML and SVG
  • New Elements
  • New Attributes
  • Changed Elements
  • Changed attributes
  • Absent Elements
  • Absent Attributes
  • Extensions to HTMLDocument
  • Extensions to HTMLElement

Backwards compatibility & progressive enhancement

I think one of the main reasons behind the adoption of HTML5 is that it sets out to be backwards compatible and work with the web browsers there already are in the market, and have been for some time, too. This is done through new elements which, generally, have no particular look or behavior attached to them, but rather offering more semantic richness and then up to you style them via CSS according to your liking.

The other parts are new elements that have been implemented in some web browsers, and not in others, where the progressive enhancement approach that has been preached for a long time comes into play. Meaning, use the new elements which will give a richer experience in some web browsers, whereas it will fall back to default content in others.

Example in question: a cascade of new input element types:

  • tel
  • search
  • url
  • email
  • datetime
  • date
  • month
  • week
  • time
  • datetime-local
  • number
  • range
  • color

So far, WebKit and Opera have been the most busy rendering engine to implement some of these, especially in relation with Opera’s work with WebForms 2.0 support, but in other web browsers it will fall back to a regular input type="text". That means, for instance, that input type="search" will will give subtle, but better user experience, in Safari and Google Chrome, but will be a fully functional for all others.

The beauty of progressive enhancement. 🙂

HTML5 code introduction

Let’s get down to some code introduction and what you need to be aware of when you start coding HTML5.

Syntax options

The doctype for HTML5 looks like this:

<!DOCTYPE html>

No versioning, no redundant information. All progressive enhancement on a feature-level, as opposed to complete releases that need to be implemented.

And, to be a bit more pragmatic than before, HTML5 will allow both quick-closing of empty tags (such as input, link etc), but you can use those elements just as well without quick-closing them. Quotes for attributes are also optional, and you know what? You can even use upper-case letters for your element names of you will!

All of these examples are valid HTML5:

<DIV>A monkey</DIV>
<p id=john>John's P</p>	

<input type=text>
<input type="text">
<input type="text" />

This might be scary to some people, and I agree with the concerns the HTML5 Super Friends presented, where they want a way to, in a more stricter way, be able to validate the consistency of the code. However, with all different people’s coding styles and our legacy, allowing this freedom was probably the only pragmatic option to get people along, instead of fighting battles that will never be won.

It should also be noted that it is not needed to specify the type attribute for style or scriptelements; it is automatically assumed to be CSS respectively JavaScript.

And, a great thing is that you can now wrap entire blocks with an a element to make that entire block a link to somewhere!


I should also mention that there are two options to serve HTML5 content: as HTML or XHTML. The somewhat confusingly named XHTML5 differs a bit from HTML5, though:

  • No doctype is needed, just an XML prolog.
  • It must have a namespace: <html xmlns="">
  • It must be served with either of these MIME types: application/xhtml+xml or application/xml.
  • The noscript element can not be used.

New elements

Lot’s of the research behind HTML5 has been how people name their elements, with IDs and classes, and part of the result are new elements named/inspired by those. There are a lot of new elements in HTML5, where these are probably the most interesting as you can use them right away in any web browser.

Mark up parts of the content that is independent, for instance blog post, article etc.
Used to mark up relevant additional information, like a sidebar.
Used for natively including audio in a web page.
The counter-part to header; could be used for any footer section per context.
Used for headers in its context. Note: not just for the header of a page, but also for each header part in section, article and similar.
Used for grouping several headers, for instance, a main heading and a sub-heading.
Used for marking up main navigation.
Mark up a generic document section. Easily confused with article, and on top of that you nest either of them, in any order, with the other.
Used to mark up a time or date.
Used for natively including video in a web page – lots of interesting work is coming along here in terms of web browser support.

HTML5 examples

Let’s get down to some actual code and see what an HTML5-coded web page could look like. I have put together a simple HTML5 example with new elements and WAI-ARIA landmark roles as part of my HTML5 demos page (quite sparse now, I know, but I will incrementally add examples to it).

This is the complete source code of that web page:

<!DOCTYPE html>
	<meta charset="utf-8">
	<title>HTML5 example with new elements and WAI-ARIA landmark roles</title>
	<link rel="stylesheet" href="css/base.css" type="text/css" media="screen">
	<!--[if lte IE 8]>
	<script src="js/html5.js"></script>

<body id="index-page">

	<div id="container">
		<header role="banner">
			<h1>HTML5 example with new elements and WAI-ARIA landmark roles</h1>
			<p>This page has valid simple HTML5 markup complemented with WAI-ARIA landmark roles for accessibility</p>

		<nav id="demo-top-nav">
			<li><a href="">HTML5 demos and samples' start page</a></li>
			<li><a href="">Robert's talk</a></li>
			<li><a href="">JavaScript compatibility tests</a></li>

		<div id="demo-main" role="main">
			<section id="demo-main-content">
						<h2>A title</h2>
						<h3>Subtitle to the above title</h3>
					<p>Some content, created <time datetime="2009-10-14">October 14th 2009</time></p>
					<p>Some more content - i guess you get the drift by now</p>

						<h2>The HTML code for this page</h2>


			<aside id="demo-aside-content" role="complementary">
				This is just a demo page to see HTML5 markup and WAI-ARIA landmark roles in action in a simple context

		<footer id="page-footer" role="contentinfo">
			Created by <a href="">Robert Nyman</a>


As you can see, it looks more or less than every other HTML web page you have ever seen, but with just a few new HTML elements being used and the role attribute with landmark roles for WAI-ARIA to make it more accessible.

If you want a more real-world example, just view the source code of I have now rewritten it as HTML5! 🙂

Can I use it today?

I would say yes!

There was some wild speculation about the date 2022, because one of the main men behind the work with HTML5 and the specification was asked in in an interview about HTML5 and its timeline, and the date 2022 was mentioned. Then everyone assumed that HTML5 wouldn’t be ready until 2022, which is not was addressed, but rather when web browsers would have two releases with completely full support for HTML5 (compare that to CSS 2.1 support etc and the time it has taken, and you will probably get a more sane reaction). Read more about in 2022, or when will HTML 5 be ready? if you want to know more.

But let’s go through the pros and cons, and I will explain why HTML5 is ready to be used.


Major players using it
To begin with, a lot of major players have already started implementing it. already have the HTML5 doctype (although they should really improve the markup accordingly), the new hyped Google Wave is revolving a lot around HTML5 and related APIs (which ironically uses a HTML4 Strict doctype…) and there is also a YouTube HTML5 demo page.
Strict rendering
The HTML5 doctype will trigger the strictest rendering in all web browsers. No Almost Standards Mode, no quirks; strict all the way, which is the way we want, and the way it should be.
Progressive enhancement
You can start today just by changing the doctype. Then gradually move onto exchanging some structure elements, sprinkle it with some WAI-ARIA etc and before you know it, you have a fantastic HTML5 page!
Validation available
Now even the W3C Validator supports HTML5. Just use the Firefox Web Developer Extension to validate your HTML against it. The HTML Validator extension unfortunately doesn’t support it yet, but I know there are at least plans to include this – if you have any ides or input, please help him out.
It probably doesn’t matter much right now, but in the future, I think that web sites that are marked up in a much more rich fashion with new HTML5 elements to give them the multitude they need, will benefit a lot from this.


Ah, right, drawbacks. There are always some, isn’t there? 🙂

Internet Explorer

It probably doesn’t come as a shock to you, but Internet Explorer, all current versions (yes, including IE8 as well) has a little issue: it won’t apply any CSS to an unknown element (e.g. nav, section etc).

However, Sjoerd Visscher found out that with an HTML5 Shiv, sort of an electrical shock for IE to start rendering things at least a little bit more properly, you can address that problem.

The gist of it is that you need to call document.createElement with the name of each new HTML5 element you use in the page. You don’t need to use it to append or place those element, just call it to make IE aware of them. Remy Sharp has written a little HTML5 enabling script for Internet Explorer, version 6 to 8 which works in all possible cases.

People eager for HTML5 has argued that we will need script dependency for IE to render styling for those elements, otherwise it will render unstyled, but with the content still fully accessible. While I agree in theory, I think it is, at times, an unnecessary requirement for using HTML5.

Another option is the content negotiation approach, where we on the server exchange the new elements for old ones just for Internet Explorer. It’s simple: just have a regular expression to replace all block elements (header, footer, section etc) with div elements, and the inline ones (time, mark etc) with span elements.

Together with that, always style you elements through their id attribute or class value, and you are good to go! All modern web browsers + screen readers + search engines will get rich HTML5 markup; IE will get plain old HTML.

The drawback of the first option is script dependency to get correct styling for the new HTML5 elements; the drawback with the other approach could be duplicating CSS and JavaScript code. Therefore, consider the options and choose the approach you deem most suitable.

Specification discussions

There are still some discussions about some elements in HTML5 and how they should be specified, what existing options/combinations there are that will work in existing user agents (which is a must; it can’t break things). Overall, though, I’d say use the new parts everyone agrees about and that will work, and hold on with the bells and whistles until it’s ready.

The last call for the HTML5 working draft is in October this year. The future is already here. 🙂

Where we are today on the web

I for one is really happy that this is finally becoming true and usable. Sure, as always there are a number of issues and things to discuss, but overall we really need this as web developers. We need new elements, APIs and options to create dazzling web sites, and we have been waiting so long for something new at all.

I also think this is vital for the climate of the web, to have open standards to code after, and to compete with the ever-growing closed-in and proprietary technologies that try to claim the web as their own.

Have me do a presentation

If you found all this to be immensely interesting, and would like to discuss it in real life or hear more, please contact me if you want me to talk at a conference, your company or similar!

Related reading

HTML5 Specification
The specification for HTML5.
A good FAQ about WHATWG and general answers to questions about HTML5 and peoples’ wishes.
HTML5 differences from HTML4
Great introduction to the differences between HTML4 and HTML5.
Dive Into HTML5
Mark Pilgrim has started writing an online book about HTML5. Only a a couple of chapters available right now, but already an interesting read.
HTML5 pocket book
Jeremy Keith has a handy little map over HTML5 elements and what they are supposed to be used for.
HTML5 Doctor
Great posts about general issues and ways to solve them, and also discusses flaws in the specification and alternatives.
Designing a blog with html5
Good introduction to how you would mark up a blog with HTML5.
HTML5 Super Friends
Well-known web names exclaim their support for HTML5, but also bring up issues they would like to see resolved.


  • Andreas says:

    About the

    <input type=text>
    <input type=”text”>
    <input type=”text” />

    stuff. what do you think of some kind of being able to specify what coding style the developer prefers in the doctype or with some meta tag? the good thing with being able to mix is i can use frameworks that used to generate xhtml ( with /> ) and still being able to use the style I prefer with my hand coded html ( <input type=”text”> ). I read the other day that the double qoutes should be droped though, with the argument that they never really has been used… ehm.

    Also I think you specify the charset in html5 with <meta charset=”utf-8″>

  • Neovov says:

    Hi Robert,

    I partially agree. We can use some parts of HTML5.
    But, what is the added-value? Do Google already understand the section or article tag? What for?

    Despite these questions, there are great questions. Especially about screen readers. Will an HTML5 page break it? Will it understand the page’s plan (which, if my memory is correct, change the content model ; the heading are reseted in each new section, article, etc.)?

    There is still some anoying issues with browsers (all of them): You can’t style a legend tag…

    I’m happy, though, to see the community waking-up about HTML5 :).

    P.S. : Sorry for my english, it is late and I had a tuff day.

  • Very good stuff Robert, thanks for the writeup.

    Lot’s of very useful information, I guess I’d better get started using HTML5 then 🙂

  • Robert Nyman says:


    Generally, I don’t think having a targeted doctype or meta tag is a good thing for code style preferences. I would rather see development and validation tools to improve, so one can set up whether quotes should be necessary etc. And about double quotes: I’m sure support for it will be around for a long time, and anything else would be preposterous.

    About the meta tag in the example, you can actually use either one, but I like the newly introduced shorter version, and it’s the one I’m using; the code sample in this article had the old one, but I have replaced it to be more consistent.


    About added-value, I would say semantically richer pages, less superfluous elements with no meaning (i.e. div-itis etc) and when it comes to the APIs, a better experience if the support is available, otherwise a good fallback. And I am certain Google already index new HTML5 elements, and that in a foreseeable future, it will make it easier for Google to index content properly.

    In terms of screen readers, JAWS and others already have a pretty decent base support for WAI-ARIA, and when it comes to headings, I think they will just parse them as regular headings. In the end, though, it’s a matter of testing to be really sure.

    About some web browsers and styling certain elements, absolutely, there are still issues. But that’s the thing, you can choose what works now, and then postpone such problem factors until we have a solid approach with them.


    Thank you!
    At least I would advise to start playing around with, get a feel of what you can and can’t do, and to evaluate the wonderful new options we have been given. 🙂

  • zcorpan says:

    Actually, geolocation and web workers were never actually in the HTML5 spec, and querySelectorAll was only an "XXX" marker. There are a number of other things that were and have been split off, though: microdata vocabs, web database, server-sent events, web sockets API, web sockets protocol, XHR, content-type processing model, URLs.

    Not that it matters in which document things are specified, though. 🙂 It's certainly easier to group all new stuff under the "HTML5" brand.

    Using content negotiation between section and div seems a bit pointless to me. I would probably continue using divs if I cared about IE without script.

    Neovov, figure and details don't use legend anymore.

    I think the HTML5 features Google are excited about are not the article tag, but things like canvas, video, workers, offline apps. If you have 42 minutes to spare I'd recommend watching this video. 🙂

  • Robert Nyman says:


    Ah, thanks, I was under the impression that geolocation and web workers were in there too. But yes, I agree, it doesn't really matter which specification, using HTML5 as the name for new emerging technologies and possibilities is probably better.

    About content negotiation, I would like to think that for more competent web browsers, devices and search engines, it will also matter if I use <code>section</code>, <code>article</code> etc, instead of meaningless <code>div</code> elements. Besides, as a coder, it becomes much richer to use a wide scope of elements instead of just <code>div</code>s all over, and developer joy should never be underestimated. 🙂

    I know about <code>dt</code> and <code>dd</code> instead of <code>legend</code>, but then we have the problems unearthed with that in dd-details wrong again. I think we need to find a more solid approach, or even introduce new elements, if the need arises, to make people feel safe about using that.

    And naturally, Google are of course more interested as a service provider in those new shiny features, but I am certain more semantically rich HTML will in turn help the improve, and get even better matches, with their search result algorithms. And, the video is interesting, albeit long. 🙂

  • choen says:

    element time not valid if using date?

  • telga says:

    "Strict rendering

    The HTML5 doctype will trigger the strictest rendering in all web browsers. No Almost Standards Mode, no quirks; strict all the way, which is the way we want, and the way it should be"

    What on earth is left of strict rendering or standards mode or web standards if, as you point out in your example, every kind of sloppy mark-up is valid html5 right down to not using

    double quotes, which can be dropped because they "weren't used much anyway"????

    When paving cow paths, that seems to include a lot of bullshit.

  • Robert Nyman says:


    No, the <code>time</code> element could also be used for just time as well.


    I think it's a valid point, although they are slightly different things. Strict rendering is about how elements will be laid out on the page, how the box model is handled, spacing in tables etc – in such regards, one wants the most strict and consistent way.

    I for one would definitely love to see quotes to be mandatory, only lower-case tags etc, but I believe WHATWG came to a crossroads – if they want mass-adoption of HTML5, it will need to adapt to some legacy code approaches and not make the decision about just one ultimate approach. However, I would really like to see validation tools offering more strict syntax validation, and perhaps in conjunction with some advice about well-formed code.

    And about paving cow paths, let's just say that there are a number of opinions how that term is used… 🙂

  • […] Ausführlicher Blick auf die Zukunft von HTML: An introduction to HTML5 […]

  • […] An Introduction to HTML5 covers a lot of ground […]

  • I think it's important to make a distinction between pretty and parsable when comes to stuff like whether an attribute value is wrapped in quotes or not, or upper or lower case.

    The renderer doesn't care as long as you don't stray outside the spec, so the end result will look exactly the same regardless of which style you choose.

    If the renderer behaves exactly the same either way it boils down to what looks prettiest when you view the source, which really doesn't matter as far as the standard is concerned.

    If prettiness and consistency is paramount to you or your organization, you can always formulate a coding standard for the HTML you produce. This is common in programming in order to help consistency and legibility, see the PEAR coding standard for an example. There are tools that validate PHP code against the PEAR coding standard, and similar tools could be created for a stricter HTML standard, e.g. "HTML5 Soup Nazi Strict".

  • Robert Nyman says:


    That's a great comment!

    We should not confuse our preferred style with what how it is actually rendered in a web browser – just do "View partial source" in a web browser, and you will see very varying results of how they actually interpret it.

    Coding standards are great, but I would also really like to see the validator, in the future, offer at least a few more options in how strict it should validate.

  • […] du intresserad av en längre sammanfattning av HTML5 har Robert Nyman skrivit en bra artikel om HTML5 (på engelska). Detta inlägg är skriven av Jens Wedin om Interaktionsdesign, Utbildningar och […]

  • nemeseri says:

    @Robert Nyman

    As I mentioned in a reply to your tweet, wrap a block element with an inline element couses strange behavior in Firefox (3.5-). For me it's a real game changer.

    Start here:

    Eric Meyer:

    "What I didn’t want, though, was the randomized layout weirdness that resulted once I started styling the descendants of the link. Sometimes everything would lay out properly, and other times the bits and pieces were all over the place. I could (randomly) flip back and forth between the two just by repeatedly hitting reload. I thought maybe it was the heading elements that were causing problems, so I converted them all to classed paragraphs. Nope, same problems. So I converted them all to classed spans and that solved the problem. The layout became steady and stable."

    "So it’s a bit late now, but I believe this is caused by an issue in Firefox where the parsing of blocks-in-inlines is dependent on TCP/IP packet boundaries (which is why it changes on reloads)." by Philip Taylor.

    I will setup a test page shortly.

  • Robert Nyman says:


    Yes, and I replied to that on Twitter (not sure if you saw that), that that's very unfortunate. Personally, though, I haven't stumbled across such problems, but I would love to see a good example page to see what one should refrain from using.

  • nemeseri says:

    @Robert Nyman

    I have set up a simple test page:

    You can see that the 4th list item falling apart in firefox (tested up to 3.6b1 canidate).

    When you look at the markup, you can see, that every <a> element closed properly.

    When you open up firebug and look at the buggy element, you can see that there is a lot of <a> elements in the generated DOM.

    When you reload the page, the bug may go away. This is because it depends on the TCP/IP package borders. As mentioned by Philip Taylor ( ), and examined by Ian Hixie ( ).

  • nemeseri says:

    uhh the <a> tags in the text disappeared 🙂


    "When you look at the markup, you can see, that every <a> element closed properly.

    When you open up firebug and look at the buggy element, you can see that there is a lot of <a> elements in the generated DOM."

  • Robert Nyman says:


    Great, thank you for the example! Very interesting to see it in action, and to be able to look at generated code myself.

    Have you found any logic to when it breaks, and possible approaches to avoid having it break in Firefox?

  • nemeseri says:

    @Robert Nyman

    Ian Hixie has a great explanation whats going on ( It's quite complicated to describe it here. 🙂

    You can avoid this behavior if you wrap the block elements inside an extra <span> element:

    <span> …. </span>

    But note, that this is invalid in HTML5. So i don't know any good solution now.

    Because I didn't find any bug related to this issue in the firefox bugzilla, I have filled one. Maybe we will get more information about it there:

  • nemeseri says:

    @Robert Nyman

    David Baron (mozilla) pointed out, that in firefox, the HTML5 parser is turned off by default. When you turn it on, the bug goes away (about:config).

    It's a bit dissapointing for me, that it's not turned on by default even in the nightlies. Based on this, I think I won't use HTML5 for any projects. 😉

    Robert, I hope, that I didn't robbed your time too much. Thank you for your answers.

  • Robert Nyman says:


    Yes, I was hoping for some consistent solution and something that is valid. 🙂

    Great filing the bug, as soon as this can be sorted out, the better! I saw his comment about the parser, but my hope is that it is sorted/enabled by Firefox 3.6. Otherwise, well, I guess just using lots of links as we did before is the option for now, unfortunately.

    And you're not robbing my time; on the contrary! Great input, and I really appreciate your efforts!

  • […] Introducción a HTML5 2009 octubre 26 0 comentarios The HTML5 work stems from the WHATWG (Web Hypertext Application Technology Working Group), and their focus is the development of HTML and APIs for web applications. The reason it came to life back in 2004, founded by people from Apple, Mozilla and Opera, was a worry about the direction W3C were taking with XHTML, and no focus on HTML or the real-life needs for web developers.An introduction to HTML5 – Robert’s talk […]

  • Andy Halford says:

    Nice article. You may wish to know that my Total Validator Tool now supports HTML5 validation as well. It's available as an online service like W3C, a desktop tool for use behind firewalls (and files still on your disk) and there's a Firefox extension as well.

  • Robert Nyman says:


    Thank you!

    And thanks for the tip, I will try it out!

  • […] An Introduction to HTML5 Posted in Developing, HTML5/HTML/XHTML, Technology | Share your thoughts […]

  • […] nice if there was an introduction to HTML5 somewhere. It turns out that Robert Nyman has written an Introduction to HTML5. It’s detailed enough to get you started, but not so detailed that you get lost, (like the […]

  • […] short introduction to HTML5 (mostly just covering the new semantic […]

  • […] I mentioned in my post An Introduction to HTML5, in previous versions of Internet Explorer you needed a HTML5 Shiv, i.e. a JavaScript, to trigger […]

  • […] An Introduction To HTML5 […]

  • […] Introduction to HTML5 by Robert’s Talk […]

  • […] An Introduction to HTML5 (by Robert Nyman) A great overview of basic markup changes in HTML5 (over HTML4) and the relevant pros and cons. […]

  • […] to be almost entirely compatible by the end of the year. For those of you in the dark about HTML 5, here’s a great overview that’s worth a […]

  • […] to be almost entirely compatible by the end of the year. For those of you in the dark about HTML 5, here’s a great overview that’s worth a […]

  • […] if you want to work with web front-end in the future, this should probably be your area of focus. Introduction to HTML5 gives, as the title suggest, an introduction to HTML5. It tells the story about how HTML5 came to […]

  • […] research HTML5 in general, and if it’s viable for an IE6 world.Basic HTML5 Introduction ArticlesRobert Nyman’s Into to HTML5A List Apart’s Preview of HTML5W3C’s HTML5 IntroHTML5 DoctorDive Into HTML5Zeldman on […]

  • Very good article. HTML5 as we know it is very revolutionary compared to the previous html version. One of the benefits that we feel is we can build applications for mobile by using HTML5 and CSS3. Thanks Robert for a very interesting article from you.

  • […] An Introduction to HTML5 […]

  • […] until version 8) is still incapable of correctly displaying HTML5 elements. Nevertheless, there are currently some existing coding projects looking to overcome this problem, which makes HTML5’s positive future a lot brighter and […]

  • Syntaxxx says:

    This is such a good primer for HTML5. I’ve had it bookmarked for a couple of years and still come back and check it from time to time. Thanks Robert

  • Robert Nyman says:


    Thank you!

Leave a Reply to Neovov Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.