Yes, You Can Use HTML 5

Published on July 8, 2008 (↻ February 5, 2024), filed under Development (RSS feed for all categories).

This and many other posts are also available as a pretty, well-behaved ebook: On Web Development.

You can already use HTML 5: Just use <!DOCTYPE html> as your HTML documents’ document type.

This works even though you will not yet benefit from new elements and attributes (except for formerly proprietary things like autocomplete). Neither could you use the XHTML serialization (an incentive to use real HTML, as many authors do unknowingly).

A safe thing to do is the “new” way of specifying the document encoding by using the charset attribute, however, as in <meta charset="utf-8">. (Feel reminded of the HTML 5 version of the infamous best HTML template.) Try it. Do not forget to check the transformation result with the HTML 5 validator.

As an HTML Working Group member who prefers to stay in the background I hope this adds a little to the excitement about HTML 5. Yes, we can! 😊 [I somewhat regret this pop reference.]

About Me

Jens Oliver Meiert, on November 9, 2024.

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)

Comments (Closed)

On July 8, 2008, 15:14 CEST, Somecallmejosh said:
Hello Jens,

I’m really excited about HTML 5. Is it safe to assume that older browsers like IE6 can handle HTML 5? Would you personally use this version on client websites, or would you still lean towards XHTML?
On July 8, 2008, 21:23 CEST, Jens Oliver Meiert said:
Josh (is that right?):

Is it safe to assume that older browsers like IE6 can handle HTML 5?

Yes, it is, it does not seem to switch into quirks mode, and my own test cases did not indicate any problems.

Would you personally use this version on client websites,

Yes, and I already use HTML 5 on several sites (just recently also on example.ms).

or would you still lean towards XHTML?

Actually, I moved (back) to HTML in several projects (due to several reasons, including performance optimization), and the only reason I stick with XHTML on remaining sites, including this one, is cost of problem.
On July 9, 2008, 20:23 CEST, John Foliot said:
Jens (and all),
While an emergent standard such as HTML 5 is indeed an exciting idea, casual readers and others not fully following some of the machinations behind the scenes might be surprised to hear of some of the sillier regressions that HTML 5 is suggesting, such as making the ALT attribute optional, the deprecation of accessibility enhancements such as @longdesc, @summary, and the headers/id construct for complex tables. There are quite a few web accessibility advocates who are expressing concerns that the process is dumping the baby out with the bath water, and that the edge-case scenarios that some of these attributes address are not being re-factored into the new spec.

So while experimentation with the new spec may be an interesting exercise, in the interest of accessibility I would caution all to not assume that HTML 5 is currently the “best” choice for universal access or compliance to other standards or guidelines such as WCAG 1, WCAG 2(Draft) or Section 508, as it may not actually allow you to achieve compliance to these requirements.
JF
On July 10, 2008, 16:49 CEST, Jens Oliver Meiert said:
John, thanks for swinging by. Concerning accessibility considerations I guess we might very well wait and see how the spec evolves as some things are still subject to change. And even when @alt ends up being optional, this may not mean much as the need to provide appropriate alternatives will not change. Also, raising awareness for accessibility is still our main concern, I guess, which means that decent web developers are needed in general, not just for HTML 5.
On July 10, 2008, 20:35 CEST, John Foliot said:
Jens,

Concerning accessibility considerations I guess we might very well wait and see how the spec evolves as some things are definitely subject to change.

Leaving aside the very contentious @alt discussion for a second, the major flaw with HTML 5 today is that it has stripped away other usable and needed (if underused) constructs such as @summary and @longdesc.

@longdesc is extremely useful when it is used (and needed). Not every image needs an @longdesc, but when one does, @longdesc is the tool to use. The current crop of screen reading tools support and expose @longdesc to their users, and there is a nice Firefox plug-in that also allows any user to query and read the long description with the click of a mouse. Progressive and forward looking developers, those that care about moving the spec forward *AND* about ensuring accessibility have just had a useful, if specialized, tool removed from their toolbox - not because it does not do what it is supposed to do, but rather that it is not used enough today to “justify” keeping it in the spec. This is wrong IMHO. HTML 5 almost deliberately ignores edge-case needs and uses, impacting on users who *are* those edge-cases. (It should also be noted that natively, none of the current browsers really [properly] support @longdesc anyway, which ends up being a further dis-incentive to caring developers)

It is good to encourage developers to experiment with an emergent spec, but it is not yet a standard, and as such it is a tricky and slippery exercise. The point that I am hoping to make is that due to as-yet unresolved accessibility issues, HTML 5 is not yet ready for production class development, and suggesting otherwise does a dis-service to some, including the disabled. For while you may be able to craft an HTML 5 document that passes the HTML 5 validator, it may very well not meet other, established or emergent standards - and this should be a major concern (or at least consideration) to anyone doing production level development.

I agree that there remains an overwhelming need to continue to raise awareness within the developer community re: accessible web design, but to my mind taking away existing tools at the same time is a huge step backwards. So while your closing comment of “Yes we can!” may be encouraging, it is more accurately “Yes we almost can!”

Respectfully,
JF
On July 13, 2008, 22:04 CEST, Somecallmejosh said:
Thanks for your reply Jens. And yes, the name is Josh… for some, anyway 😊.

the sillier regressions that HTML 5 is suggesting, such as making the ALT attribute optional

John, I understand your points, but would you agree that the lack of an ALT attribute is better than an empty one? The SEO pundits argue that they (alt’s) should be used for keyword stuffing (although they never phrase it this way), and the accessibility evangelists suggest using the other extreme of including it but leaving it null, alt="", on images that are purely decorational.

I guess my point is that neither approach “seems” like the right answer. Why force an alt attribute on a non-illustrative image, or stuff it with keywords that don’t support the image?

Does it seem logical that someone with a screen reader, or a image disabled browser, could easily determine that an image without an alt attribute is meaningless in the context of the content? Hopefully the smart people developing HTML 5 are attempting to remove a step that is of little benefit to both the visitor and the developer?
On July 15, 2008, 15:05 CEST, Plissee said:
If you use HTML 5 older Browsers p.e. the IE 6 have many Problems with it. But many people us also the IE6 why can´t i say
On July 17, 2008, 23:45 CEST, Jens Oliver Meiert said:
John, thank you again, and apologies for the delay. I can only point to two things, namely that I prefer in-document explanations over @longdesc (short version), and that I trust Ian and the Working Group to ship a final version of HTML that responds to all questions and concerns.

Josh, good question, but as I intentionally abstained from the alt discussion before I do not necessarily want to really dig into that right now. However, one might argue that the entire issue boils down to one thing: Authors are responsible for appropriate alternatives to multimedia contents. That is the case right now, and that won’t change with HTML 5, not even when @alt really becomes optional.

Plissee, I cannot quite follow? HTML 5 documents following what I outlined above very well “work” in IE 6, too.
On July 25, 2008, 14:19 CEST, david said:
Hello Jens,

after years of being sort of XHTML fanboy, I recently also decided to move back to HTML as this seems to be the only “correct” choice for now, especially considering you still cannot really use XHTML with an appropriate Content-Type thanks to IE. People like you motivated me to take this decision eventually.

Usually, I also write HTML5 now. While leaving out truly superfluous things like the type attribute on link and script tags, I do not omit optional tags yet as I currently find my code more readable with them. This is just my personal opinion, indeed.

However, I would not call using the compact document encoding notation <meta charset="UTF-8"> a “safe thing” as it is unfortunately still not recognized by the “popular” Lynx console browser. I find that disappointing, too, because the http-equiv notation is way too verbose. But as I am of the opinion that an HTML document should always be self-descriptive since mistakes with HTTP headers can quickly happen when you e.g. move a file to a different directory or server, I am of the opinion that the HTML4-like notation should be the recommended one until Lynx (and probabely other user agents?) support the charset attribute. What do you think about that?

-david
On July 26, 2008, 1:14 CEST, david said:
Update: I have once again given thought to optional tags as well as to quotation marks around attributes, but this time I was a bit more open-minded.

Regarding the former: I have played around a while and came to the conclusion that the html, head and body start tags give the code some structure while the respective end tags are really useless; as well as the p, li, dt and dd end tags usually are. This page shows how I finally want it to look like.

Pertaining the quotation marks, I am still unsure. While I find <html lang=en-US> perfectly okay; especially in URLs, it can quickly happen that one misses a forbidden character like = or >, especially when replacing strings automatically. So I want to ask you, Jens: Which style do you prefer here?

-david
On July 28, 2008, 14:03 CEST, Jens Oliver Meiert said:
Hi David. Agreeing that there is some room for personal preferences:

I am of the opinion that the HTML4-like notation should be the recommended one until Lynx (and probabely other user agents?) support the charset attribute. What do you think about that?

I think that this decision depends on the number of Lynx users accessing the site in question (assuming that Lynx really doesn’t support @charset, something I actually wasn’t aware of), and if there are “fallback” measures in place, like configuring your server to set the encoding (e.g., via AddCharset) anyway. I don’t see any problems using @charset when doing the latter, knowing about potential problems.

Pertaining the quotation marks, I am still unsure. While I find <html lang=en-US> perfectly okay; especially in URLs, it can quickly happen that one misses a forbidden character like = or >, especially when replacing strings automatically. So I want to ask you, Jens: Which style do you prefer here?

Regarding quotation marks I’d recommend to keep them, at least for consistency reasons (as e.g., @class values should be used with quotation marks). Skipping them seems only advisable to me once there are no options left anymore, as I described in my post on when validation becomes unimportant.
On August 8, 2008, 1:00 CEST, Anonymous said:
…but would you agree that the lack of an ALT attribute is better than an empty one? … and the accessibility evangelists suggest using the other extreme of including it but leaving it null, alt=”", on images that are purely decorational.

No! Josh, do you *really* know why we (accessibility specialists) suggest that? Earlier versions of screen readers, if not given empty alt values, read aloud the file name of the image… which would you rather hear, ” ” (nothing), or “spacer dot gif”? so part of the reasoning is based on legacy issues.

Does it seem logical that someone with a screen reader, or a image disabled browser, could easily determine that an image without an alt attribute is meaningless in the context of the content?

How do you determine that Josh? With no data your guess has a 50% chance of being wrong - is this (fictitious) image meaningless or meaningful: <img src=”./images/ty673so.jpg” />? I agree that alt=”" alone does little to truly address the real issue, but completely dropping the alt attribute does nothing to convey the value or importance (or lack thereof) of an image.

Essentially there are 2 reasons why an image would not have an alt value: it really does not need one (spacer.gif), or the content author did not or could not supply one. We need a notation method that imparts that kind of information, and to date the HTML 5 Working Group have not addressed this real need, instead simply giving up and suggesting that under certain circumstances having no value at all is somehow “better”. It isn’t, it never will be, and the current thinking is still flawed.

…I prefer in-document explanations over @longdesc…

As do I most of the time: this however is *not* a reason to deprecate @longdesc - it has value that currently is under-used, but value none-the-less. As collectively the web moves to smaller mobile devices (iPhone anyone?), onscreen real estate will have a higher and higher premium, and tools such as @longdesc may prove to be extremely useful in those types of scenarios, not only for the visually impaired but for all users of small screen devices. Good forward planning leaves doors open, poor forward planning closes doors without thinking things through…
On August 24, 2008, 11:08 CEST, Kroc Camen said:
Start learning and writing HTML5 now.
There’s millions of iPhone users browsing with nothing but a fully capable standards-machine. IE is irrelevant to HTML5. Users are ready to download Firefox as soon as you tell them it’s needed.
On September 17, 2008, 16:21 CEST, Johan De Silva said:
On the whole I am happy with HTML. John Foliot mention table headers have been removed but this is not true only the attribute of “header” inside the td tag has been removed. No one seemed to notice that the acronym tag has been removed, that is the only mistake imo.
On December 1, 2008, 2:58 CET, John said:
I’m looking for some examples of live HTML 5 sites, do you know any?
On December 1, 2008, 10:05 CET, Jens Oliver Meiert said:
John, sure—a selection of some static sites:
On March 1, 2009, 21:41 CET, Leon Paternoster said:
The “normal” validator now accepts HTML5 (e.g. one of my wp theme’s demo site validates)—apologies if this is old hat.

BTW - HTML5 seems to accept both > and />, so it’s easy to convert wordpress (and other blogging engines/CMSs) templates from XHTML to HTML5.
On August 4, 2009, 20:31 CEST, Michael Hamilton said:
I develop a CMS and read some discussion about the optional ALT tags. Spacer.gif is a good example of something you should try to avoid, but also a good example of an image which typically needs no alt tag.

There is another context in which ALT tags are silly, however. Client managed content. I use the FCKEditor (soon upgrading to the CKEditor) and it puts in empty alt tags when clients don’t enter a description, but ultimately that’s a solid waste of 6 characters give or take. If the web developer is not responsible for the specific content of a website and the client does not supply image descriptions it seems silly to require them. I have no way of knowing what a valid alt tag will be for some of this stuff, and it’s tough enough to train clients not to simply resize images within the editor without actually modifying the size of the image let alone provide alt tag descriptions.

Anyway, HTML5 -can- be used in IE6, IE7, and IE8, but it requires some javascript to automatically insert the appropriate elements so that they can be styled via CSS.