Yes, You Can Use HTML 5
Post from July 8, 2008 (↻ September 11, 2017), filed under Web Development.
This and many other posts are also available as a pretty, well-behaved e-book: 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 or attributes (except for formerly proprietary things like
autocomplete). Neither could you use the XHTML serialization (an incentive to use real HTML as most authors do involuntarily, or 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 validate the transformation results through the HTML 5 validator.
As a 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! 😊
About the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.
On July 8, 2008, 15:14 CEST, Somecallmejosh said:
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 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.
On July 10, 2008, 20:35 CEST, John Foliot said:
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!”
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?
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 25, 2008, 14:19 CEST, david said:
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
scripttags, 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-equivnotation 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
charsetattribute. What do you think about that?
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
bodystart tags give the code some structure while the respective end tags are really useless; as well as the
ddend 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
>, especially when replacing strings automatically. So I want to ask you, Jens: Which style do you prefer here?
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…
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 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?
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
/>, so it’s easy to convert wordpress (and other blogging engines/CMSs) templates from XHTML to HTML5.
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.