Here are the most common questions we’re asked, with non-technical answers. Journos – you’re welcome to use these answers (a citation would be nice but isn’t required).

We’ll add new questions and answers as they are asked.

What is HTML5?

Depends what you mean. There are 3 different uses of the phrase "HTML5":

The HTML5 specification

The most accurate meaning of HTML5 is the specification that is developed by two groups, the W3C and WHATWG, together. There are different versions of the core HTML5 specification.

It is a much-needed evolution of the language that web pages are written in, and is designed for writing Web applications (dynamic interactive web pages that do something). Its predecessor, HTML4, dating from the late 1990s, was written for Web Pages (static, hyperlinked documents of text, images, forms).

Key facts:

• It’s designed to make web pages interoperable across browsers. These days, people use multiple browsers (For example, IE at work, Safari/ Opera on their phone, Opera/ Firefox at home) and it’s stupid and annoying if a website doesn’t work everywhere.
• All the browser manufacturers – Opera, Mozilla (Firefox), Apple (Safari), Microsoft (Internet Explorer), Google (Chrome) – are working together, along with loads of other individuals and organisations: Netflix, Adobe, IBM, HP, BBC etc.
• It’s designed to extend the capabilities of the current web, without breaking existing web pages
• It competes with plugins like Microsoft Silverlight and Adobe Flash (which themselves were developed to plug the holes in fossilized HTML4 standard)

HTML5 and close friends

In addition to the core HTML5 specification, the WHATWG developed other specifications such as Web Workers, Web Sockets, Web Database. These add more features useful in applications, games and the like.

(Many of these have been part of the core spec at some point, but moved out for procedural/ organisational reasons. They are all grouped together in a specification called Web Applications 1.0).

New, Exciting Web Technologies

When most non-developers (and many less-informed developers) say “HTML5″ they are referring to a whole slew of technologies: Core HTML5, its friends and others entirely unrelated technologies, such as Geolocation (the ability for your browser to “know” its location), Device Orientation, Touch Events, CSS3 animations (that can replace very simple Flash animations), SVG (a way of describing graphics that look crisp and unpixellated at any screensize) and, the new kid on the block, WebGL, a port of a popular 3D graphics library to the Web that allows 3D graphics and games in the browser.

Many of these are developed by the W3C; WebGL is developed by Khronos Group.

It’s also important to note that many so-called "HTML5" demos are nothing to do with HTML5 at all; many Google Doodles, for example, use DHTML – an HTML 4 technology from the turn of the millennium.

Why has HTML5 been invented?

HTML 4 was creaking at the seams for the new breed of applications. Some things were impossible and needed plugins like Adobe Flash or Microsoft Silverlight; other things required elaborate hacks on undocumented features, which wasn’t a robust foundation for websites that make money for their owners.

How many HTML5-compliant browsers are there?

It depends on your definition. Because HTML5 extends HTML4, by definition all browsers have some HTML5 features.

If, on the other hand, you want to know which browsers include all Core HTML5 features, none of them do. They are all implementing pieces of the specification (which is 700+ pages long) but none implement all.

Disregarding all the hype, the modern versions of the browsers are all around the same level of implementation (although different browsers implement different features at different times, depending on the needs of their customers).

Who’s driving HTML5?

It began in Opera, in 2004, edited by Ian Hickson. Gradually all the other browser manufacturers joined. Hickson left Opera and joined Google, where he continues to edit the spec.

It’s fairest to say that browser manufacturers collaboratively drive the spec, with the W3C and many other organisations and individuals. Ultimately, it’s driven by the needs of Web developers.

Who’s using HTML5?

Lots of people – not just tech companies: Boston Globe Newspaper; Nationwide Building Society, Yell.com and hundreds more. HTML5gallery.com showcases many HTML5 sites.

When will HTML5 be ready?

Perhaps 2012. Perhaps 2022. It doesn’t matter; what matters is that a lot of it is implemented in browsers now, so it can be used now.

Saying that we can’t use HTML5 because it isn’t finished is like saying we can’t speak English because it isn’t finished.

Is HTML5 incompatible with Internet Explorer?

Nope. IE9 has good support. Support for some APIs can be patched into older browsers with a technique called polyfilling with JavaScript, or with plugins like Flash and Silverlight. Support for <canvas> can be faked in IE<9. It’s generally the slow JavaScript engines in older browsers that cause problems. Video content can use a Flash fallback in older versions of all browsers.

It’s worth noting that many of the features in HTML5 (like contenteditable, the Drag and Drop API) were invented by Microsoft and were included in IE5.

Is HTML5 just about mobile?

Absolutely not. Behind HTML5 are some Design Principles, one of which states that it’s about universal access:

Features should be designed for universal access…Features should, when possible, work across different platforms, devices, and media.

That said, there are several features that are useful on Mobile. If you’re looking at "real" HTML5, then the ability to continue to interact with a website even when offline via Application Cache (“Appcache”) is a useful one.

The fact that you can use HTML5 <canvas> for animations on devices that, by choice or necessity, can’t use Adobe Flash can be advantageous.

In the broader "New Exciting Web Techologies" definition of HTML5, Geolocation is a huge feature.

Will HTML5 kill Adobe Flash?

No – or we hope not. For years Flash was the only way to add video to a page; now there is HTML5. This competition means both are getting better, which is great for developers.

Apple decided not to allow Flash on their iOS devices, which is what gave HTML5 video a great boost. It’s important to note that HTML5 multimedia on iOS is hardly a perfect platform:

• HTML5 video issues on the iPad and how to solve them
• Unsolved HTML5 video issues on iOS
• Audio Sprites (and fixes for iOS)

For video that uses adaptive bit-rate streaming, or Digital Rights Management (DRM), Flash remains a useful cross-browser tool.

It’s also necessary to realise that Flash does more than simply video. Some its basic functions like simple gaming have been usurped by HTML5 <canvas>, and the kind of trivial animations that it used to be used for (things spinning on hover, for example) are moved into CSS 3. However, for ease of authoring sophisticated animated content like games and cartoons, it’s much easier for authors to write in Flash as Adobe’s authoring environment has many tools (tweening, timelines) that make it easy for visual developers. This will change as companies develop pleasant authoring environments for <canvas>, but it isn’t there yet.

(Adobe recently released a preview of a timeline-driven authoring environment for non-Flash animations called Adobe Edge. Ignore its claims to be "HTML5"; in its current early incarnation, it’s simply flying HTML 4<div>s around with JavaScript.)

Will HTML5 kill mobile Apps?

HTML5 (in the broadest sense of "New Exciting Web Technologies") significantly enhance the capabilities of the Web. Two years ago, to access the Global Positioning System on the phone, you had to write a native app in C++ or Java or.NET or Objective C depending on platform. If you wanted to target all platforms, you write the same app multiple times. Now, you can access Geolocation data from JavaScript on every platform (and on laptops too!), by the user visiting a URL rather than downloading an app.

Open web technologies are providing access to the device’s camera and orientation, the system contact book, peer-to-peer in-browser video conferencing, the devices’ file system, and many more. JavaScript engines are becoming almost as fast as native code, so the technical niche for native applications on high-end smartphones still exists, but is becoming smaller. On less sophisticated devices that can’t run fast JavaScript or a full web browser, native apps are still an important product.

There are non-technical reasons for apps, too. Operators like them very much: they can control distribution and therefore extract money from both purchasers and vendors. Whereas many people dislike the idea of a monolithic appstore and app approval process, some consumers value it. Appstores offer curation – consumers feel that the apps are vetted and therefore won’t wreck their phones, steal their identities or (shudder) expose them to Internet smut.

Apps built for one specific device can be highly integrated with the User Interface and User Experience conventions of that device. Some people see this as a compelling advantage. However, uptake of the Web doesn’t seem to have suffered because authors make one single website rather than different websites for Linux, Mac and Windows.

Any further questions?

If you have any further questions, you can ask the doctor, or analysts/ accredited journalists can ask your author for a briefing.

HTML5: briefing notes for journalists and analysts originally appeared on HTML5 Doctor on September 20, 2011.

Yay.

Jeremy Keith snapped five doctors together at our booth at the Web Directions/ @media conference. Left to right you can see Mike Robinson, Jack Osborne, Rich Clark and Remy Sharp with Bruce in the foreground. Missing are Tom Leadbetter, Oli Studholme and Brandan Lennox.

We also got a nice pic with two of the Ubelly team—back-end specialist Dr Andrew Spooner and Ms Alex Ball.

Thanks Ubelly! And, from Bruce, thanks to Opera for letting me sneak some doctoring in during work time.

If you have an award or large quantities of banknotes to give us, just get in touch.

The Doctors win a Critter award originally appeared on HTML5 Doctor on May 30, 2011.

For the last couple of years, it’s been fashionable to have “fat footers” in websites. Take, for example, Jeffrey Zeldman’s footer:

We see an area with a svelte black background, containing a super-glammo set of six images, each of which has a caption and links to other sites that Zeldman has an interest in: conferences, books, articles, podcasts. Below those images is a copyright notice, some more conventional footer links (contact, subscribe, style switcher) and a blue stripe:

Being HTML5 ninjas, we know that we’ll wrap each image and its attendant caption within <figure> and <figcaption> elements – but what will we wrap the whole group of external links in?

Choose from the answers below please. Make sure you show your working out. Escape your HTML, please, or we’ll put a severed unicorn head in your bed.

A:

Figures as direct children of the <footer> element:

<footer>
<figure>…</figure>
…
<p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p>
</footer>

B:

The figures in an <aside> element nested in the <footer>:

<footer>
<aside>
<figure>…</figure>
…
</aside>
<p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p>
</footer>

C:

The images in a <nav> element inside the <footer>:

<footer>
<nav>
<figure>…</figure>
…
</nav>
<p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p>
</footer>

D:

Images in a <div> element immediately before the <footer>:

<div>
<figure>…</figure>
…
</div>
<footer>
<p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p>
</footer>

E:

Images in an <aside> element immediately before the <footer>:

<aside>
<figure>…</figure>
…
</aside>
<footer>
<p><small>Copyright © 1995–2011 L. Jeffrey Zeldman.</small></p>
</footer>

Your answers below, please, with your rationale, by Friday 12th March.

HTML5 Simplequiz 6: Zeldman’s fat footer originally appeared on HTML5 Doctor on March 4, 2011.

The facts

Ian Hickson, editor of the HTML5 specification, announced that HTML is the new HTML5, meaning that the WHATWG will drop the numeral "5" and just call their spec "HTML". HTML will be a "living standard", with a mixture of widely-implemented features like <canvas> or <video> and wildly experimental features like <device>. The W3C produces a spec called "HTML5". Ian Hickson (currently) edits both of them. They are different. The W3C creates a version of this technology which is under the W3C Royalty Free Patent Policy to give a better guarantee for developers against patents. This specification has the version number 5. (There's an interesting conversation to be had about the WHATWG, patent policy, and licensing, but that's not for today.)

TL;DR: nothing much changes (by Bruce Lawson)

So what does this mean? What changes for us developers? In practice: very little for most of us. Browsers process what they can process regardless of what mode they're in, what "version" of HTML is current, or what a document's DOCTYPE claims.

Take for example a document containing a <video> element, using WebM, Ogg, and MP4 <source> elements, with scripted controls using the media elements API, input type=range, and CSS3 opacity and transitions. With an HTML2 (yes, HTML2!) DOCTYPE, it's a fine example of HTML2 video.

If you're using a modern browser, everything will work fine. Your browser knows how to show those HTML5 goodies, so it does, regardless of what the DOCTYPE claims. What would be the point of a browser looking up what elements are part of HTML2 and refusing to show the video since <video> isn't part of that list? Such switching logic would take longer to process, delaying rendering for no practical benefit at all.

The only function of a DOCTYPE is to keep the browser out of Quirks Mode. The HTML5 DOCTYPE <!DOCTYPE HTML> is the shortest string that does this reliably. And note that there's no version number on that.

If version-less HTML surprises you, it shouldn't. It's what CSS has used all along. We happily use some CSS 3 modules without vendor prefixes (border-radius, for example) while we avoid some CSS 2 features because they have no support. So the version number has no practical use and we don't sweat it at all.

Here's an extract from a 2008 interview by xhtml.com with Bert Bos, who co-created CSS with Håkon Wium Lie (one of the core WHATWG members):

xhtml.com: I suspect many people haven't noticed that CSS has no version identifier….What drove the original decision not to include a version identifier and how has this affected the evolution of the CSS spec?

Bos: The working group has recognized since a long time that version numbers for document formats (as opposed to software) are a fallacy. HTML has version numbers (inside the DOCTYPE), but implementations either ignore them or use them for something else ("quirksmode").

Formats may evolve and be extended, as HTML and CSS are, but implementations won't provide different parsers for the different versions. They only implement the current version. The new version better be backwards compatible, or disaster will ensue. You might think that putting in a version number will cause old implementations to refuse documents that are too new, but it doesn't. None of the browsers written in the days of HTML2 will refuse to handle an HTML4 DOCTYPE. And none of the current HTML4 browsers will refuse an HTML5 document once HTML5 becomes a standard. No browser wants to admit it can't understand something and users don't want to use new features if that causes the whole file to fail.

The basic problem is that old and new software and old and new content have to coexist. It isn't possible to pick a day and switch all content and all software in the world over to the new version. And on the Web, some software, and especially some content, have very long life spans.

Sounds familiar, doesn't it?

(It's not the whole story. As I've mentioned above, all browsers use DOCTYPE to switch between parsing modes. Quirks mode is triggered by a line in the HTML, but it doesn't alter HTML parsing — it switches CSS parsing between IE5's broken box model or the W3C box model. Internet Explorer also has its compatibility mode which allows IE to mimic old, buggy versions. Note that these are switches to trigger buggy implementations; they are not switches between implementations of different versions of CSS or HTML. I may be splitting semantic hairs here.)

So HTML versioning will be the same as CSS versioning. With CSS, as it's only styling and not content or functionality, it doesn't matter much if something fails silently. With HTML5, we don't have vendor prefixes like CSS does, but most (if not all) new features can be feature-detected and poly-filled with JavaScript. It might not be beautiful, but it's the way of the world, and version numbers won't change that.

Ultimately, the presence or absence of a version number is less important than the fact that we have a spec that extends HTML without breaking backwards compatibility. That's what I celebrate in my Geek Song Living Standard.

Versioning isn't for browsers. It's for authors. (By John Foliot)

The main issue, as I see it, is that W3C Standards ("Recommendations" in their parlance) are not "snapshots". They're engravings, which implies a whole other level of stability and commitment. Engravings, for example, are used to print our paper currency.

The last standardized commit to HTML was over a decade ago with HTML 4.01 (Dec., 1999) (and/or the XML serialization of XHTML in January 2000, revised 1 August 2002), and HTML5 (the markup language), once finalized, will likely continue to be the benchmark a decade from now. While most would concede that HTML 4.01/XHTML 1.1 are somewhat dated today, you could (if you wanted) continue to build a site using <frames>, and it would work, and all user agents would know what to do with that code. Team members could work on that code in a shared environment, using different types of editing tools (including WYSIWYG tools). That work could span cultures and geographies as the specification has been translated into numerous world languages and teaching curricula. It is that kind of permanence and stability that comes with an actual Standard.

Just look at <hgroup>. Where are we with that today? Next week? April 2011? Who knows? (I sort of know. There's a bug filed, and it will likely be escalated to an actual issue in the Last Call process. <hgroup>'s future is under debate at this time, but with no firm timeline. The point is, you need to be on top of this stuff continuously, a task that many larger groups simply do not have the time or resources to do.) Then there is the accessibility of <canvas> and <video> — points I don't need to belabor, but issues that remain non-trivial today. Much of the current new "goodness" in the Draft HTML5 Specification has very little browser support. Look at the lack of complete support for Web Forms or many of the other newly introduced elements. It's gotten so bad that some of the less-informed think that the solution today is that all of the browsers should just move to WebKit and the problems will be solved — a suggestion so far-removed from any kind of reality as to be laughable. The answer is not to move to one rendering engine for stability, but rather for all to agree on one firm specification that works across all browsers.

My larger objection is around perception of the spec: developers who think that just because it's spec'ed at WHATWG this week that it's good to go, bring it on, to heck with permanence and legacy! It's a continued "fix-it-in-the-mix" attitude far-removed from the real world of large corporations and government. In the contest to be cool and cutting-edge, some developers forget that there is a world of commerce and actual Just-Like-Mom users out there who think that the latest advancement of the internet is Farmville on their cell phone.

I think the recent release of Drupal 7 is a great example. After nearly three years of intense community collaboration by nearly a thousand contributors, the latest version of this high-profile Open Source CMS was launched simultaneously with numerous plug-in modules re-factored for this next-generation build. Standards conformance was a huge driver for this version (as was accessibility support), so this large group of developers required an extremely stable benchmark to work towards. They couldn't rely on spec that changes monthly. Nobody wants to go back and re-write code they shipped four months ago simply because the current Draft Specification has changed the way things are done. Thus, the bulk of Drupal 7 sites I've seen to date (including those with custom themes) proudly sport the following under the hood:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN"
  "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

WHATWG serves a useful function, no doubt. Like the Fashion Houses of Paris, New York and London, they create and explore and push the boundaries. But they also often remain far-removed from the world of F&F Clothing at Tesco — Tesco by the way being an "Official Sponsor of London Fashion Week". I truly believe that the web community needs to be reminded of this fact. An evolving spec serves the needs of browser vendors, but it is no friend to many commercial developers as it hurts larger entities who need to share authoring responsibilities.

Like that paper currency made from those engravings, I want to be sure I can take it to the bank.

About John Foliot:

John Foliot is a Web Accessibility Specialist with over a decade of experience in that field. He manages the Online Accessibility Program at Stanford University, and is a co-chair of the W3C's HTML5 Accessibility Task Force, where he is focused on accessibility of the new media elements. When not ranting on the web about web accessibility and web standards, he enjoys riding his motorcycle, listening to and collecting Blues music, and sampling fine Single Malts with fellow geek friends. You can follow him on twitter at @johnfoliot.

In summary

We've given two opposing views on this matter, and now we want to hear your thoughts. Are you for or against a living HTML standard?

HTML as a Living Standard — For and Against originally appeared on HTML5 Doctor on February 8, 2011.

I’ll be honest and up-front: this is a pretty negative review. I’ve been sitting on it for months, but decided to post it as people have asked our opinion of this book.

Firstly, it’s true that all books have errors. As well as typos, there are authoring brain-farts (the book I co-wrote with Remy claims there is a <heading> element, for example). There is also the risk, when writing on a moving target like HTML5, that the spec will change after the book has gone to press.

Have you read this book? What did you think of it? Let us know in the comments.

Reviewed by Bruce Lawson, Richard Clark, Oli Studholme and Tom Leadbetter.

Review: HTML5 Designing Rich Internet Applications originally appeared on HTML5 Doctor on January 28, 2011.

The logo is a general-purpose visual identity for a broad set of open web technologies, including HTML5, CSS, SVG, WOFF, and others.

We’re pretty much at ease with lumping specs that aren’t strictly HTML5 in to the buzzword. For example, Web Workers or Web Sockets were developed by the same people that specced HTML5 and, like many aspects of HTML5, are simple APIs that developers are adopting to facilitate development of Web Applications using Open Web technologies. Geolocation was nothing to do with the WHATWG but, because it’s a modern, simple, useful API, it’s philosophically satisfying to call it “HTML5″, although inaccurate.

But lumping technologies like CSS 3, WOFF (simply a font format) or SVG is too much jargon-creep. HTML is about semantics and structuring data, not about styling, fonts or graphics. It’s not just about purity of jargon—this stuff matters. The 2001-era memo about separation of content, style and behaviour is even more important now that “HTML5″/ real-HTML5 / HTML gives us so much more power. While we understand that clients and technical journalists will use “HTML5″ as a buzzword, the W3C as the official standards body should be promoting clarity, not blurring the distinctions.

There is also the danger that other Open Standards might suffer from being excluded from the “HTML5″ buzzword—for example, W3C Widgets, which PPK has already suggested we refer to as “HTML5 apps” because of this not-”HTML5″ exclusion principle.

What can be done?

It’s not done until it’s done; the W3C says

W3C introduced this logo in January 2011 with the goal of building community support. W3C has not yet taken it up in any official capacity.

Quite rightly, the W3C has opened it up for debate. We suggest that the W3C rethink slightly, and have separate-but-related logos. For example, the current logo can represent markup and APIs that we accept may be legitimately referred to as “HTML5″, another logo for graphics – for example, SVG, and a third logo for styling that brings together CSS, WOFF and the like. (We note in passing that using a “3″ to represent CSS will quickly date when work on CSS 4 begins.)

They should be collectively referred to by some name like the “Open Web”, which should be the umbrella brand, because it remains as important as ever to set Open technologies apart from proprietary tech. We applaud the W3C’s move to brand Open tech and raise awareness of it amongst developers and the wider tech world.

This is just a strawman taxonomy to get people thinking. Have you got any better ideas?

Note, we haven’t addressed WHATWG’s recent change to using the name “HTML”. This is something that has been in the works for a long time, and better represents WHATWG’s actual process (and the process of implementers). We’ll cover this in a future post…

Addendum

Added just a few hours later:

The W3C have half-done the right thing by adding this clarification:

Is W3C saying that CSS3 is part of the HTML5 specification?
No. However, many HTML5 Web sites and applications do take advantage of CSS3 for styling and presentation.

But the CSS “styling” logo is still in the badge builder and the icon sets. It should be removed.

So two cheers for the clarification. Let’s see some commitment to complete clarity.

Two cheers for the W3C’s HTML5 logo originally appeared on HTML5 Doctor on January 21, 2011.

At the moment, Google indexes HTML5 microdata (more about microdata) but does not reward you for using the new HTML5 structural elements, but neither does it penalise you:

As HTML5 gains in popularity and as we recognize specific markup elements that provide value to our indexing system, this is likely to change, but at the moment I would not assume that you would have an advantage by using HTML5 instead of older variants….

Personally, I would recommend using HTML5 where you think that it already makes sense, perhaps reverting to HTML4 if you can determine that the browser won’t support the elements of HTML5 that you use properly. While this will not result in an advantage for your content in our search results, it generally wouldn’t be disadvantageous either.

But they will take account of HTML5 once it becomes widespread, and they seem to be encouraging experimentation:

Our general strategy is to wait to see how content is marked up on the web in practice and to adapt to that. If we find that more and more content uses HTML5 markup, that this markup can give us additional information, and that it doesn’t cause problems if webmasters incorrectly use it (which is always a problem in the beginning), then over time we’ll attempt to work that into our algorithms….

HTML5 is still very much a work in progress, so it’s great to see bleeding-edge sites making use of the new possibilities

The Doctors’ advice on SEO is to follow Google’s time-honoured guidelines: write valid, cross-browser, accessible HTML, don’t misuse markup or “cloak” with CSS, make a site with a clear hierarchy and text links, and write good content:

Create a useful, information-rich site, and write pages that clearly and accurately describe your content.

Happy New Year. May your hat remain white.

HTML5 microdata and schema.org

Added October 2011:

Schema.org is a consortium of Bing, Google and Yahoo!. On its website it says

[schema.org] provides a collection of schemas, i.e., html tags, that webmasters can use to markup their pages in ways recognized by major search providers. Search engines including Bing, Google and Yahoo! rely on this markup to improve the display of search results

schema.org uses HTML5 microdata with new elements like <time>. So, yes: in this special case (using these markup patterns) will ensure that this HTML5 will assist search engines to categorise your content (which is not the same as guaranteeing a higher ranking, of course).

Multiple <h1>s on a page

The new HTML5 outlining algorithm allows multiple <h1>s in a page. We get lots of questions about whether developers will be penalised by Google which, according to myth, disallowed this.

I say “myth” because Google has always allowed multiple <h1>s on a page, provided that it’s organic rather than trying to game the system, as this video shows:

However, don’t go too crazy with the <h1>-only approach as it removes any hierarchy from your pages in browsers that don’t implement the outline algorithm and screenreaders that sit on top of them.

HTML5 and Search Engine Optimisation (SEO) originally appeared on HTML5 Doctor on January 11, 2011.

How would you code the URL of a person leaving a comment (assuming they provided one)? Remember that there may be multiple comments on any one page. Also note that we’re not going to worry about what element wraps each comment this time. Choose from the five options below, and explain your rationale in the comments.

A:

<header>
Comment by <a href="http://www.myspace.com/timbo/">Tim 
Berners-Lee</a>
</header>
WTF! LOL! U SUCK! KTHXBAI!

B:

<header>
Comment by <cite><a href="http://www.myspace.com/timbo">Tim 
Berners-Lee</a></cite>
</header>
WTF! LOL! U SUCK! KTHXBAI!

C:

<header>
Comment by <a href="http://www.myspace.com/timbo"><cite>Tim 
Berners-Lee</cite></a>
</header>
WTF! LOL! U SUCK! KTHXBAI!

D:

<footer>
Comment by <address><a href="http://www.myspace.com/timbo">Tim 
Berners-Lee</a></address>
</footer>
WTF! LOL! U SUCK! KTHXBAI!

E:

<h1>
Comment by <a href="http://www.myspace.com/timbo"><address>Tim 
Berners-Lee</address></a>
</h1>
WTF! LOL! U SUCK! KTHXBAI!

Your answers below, please, and show your working out. We’ll close comments and give our opinions on Wednesday 22 December.

Rules: It is THE LAW that you read the preceding comments before adding your own. Note: please DON’T USE ANGLE BRACKETS in your comments. Escape them with &lt; and &gt; or just use [foo] – we’ll know what you mean.

HTML5 Simplequiz 5: URLs of commenters originally appeared on HTML5 Doctor on December 17, 2010.

With Dan’s blessing, we’re running an occasional series of HTML5 Simplequizzes.

HTML5 offers a way to associate a figure (which can be an image, a video, a graph, a table, a pull-quote) with a caption using the <figure> element. This is very common in print, but there has been no way to do this in HTML4, as there is no element that groups a figure and a caption (other than a semantically-empty <div>).

Our question this week is about alternate text for images that are captioned. I’ve gotten this wrong before (in print, embarrassingly), as have two highly-clueful friends of mine. The man who set us right will be your moderator and quizmaster this week, Steve Faulkner of The Paciello Group, possibly the most respected accessibility agency out there.

We have an image as a figure in a story simply about a dignitary opening a new branch of Mr Lidl’s marvelous emporium. The caption will be “Mayor of Casterbridge opens a new Lidl supermarket”.

What’s the best markup for this? Show your working out.

A:

 <figure>
 <img src=blah.png
  alt="A portly gent cuts a ribbon. He is with five small children, and is watched by two middle-aged woman, a very tall smiling man, and a small crowd">
  <figcaption>
  Mayor of Casterbridge opens a new Lidl supermarket.
  </figcaption>
 </figure>

B:

<figure role=img aria-labelledby=lidl>
<img src=blah.png alt="">
 <figcaption id=lidl>
  Mayor of Casterbridge opens a new Lidl supermarket.
 </figcaption>
</figure>

C:

<figure>
<img src=blah.png>
 <figcaption>
 Mayor of Casterbridge opens a new Lidl supermarket.
 </figcaption>
</figure>

D:

<figure>
<img src=blah.png alt="">
 <figcaption>
 <p>Mayor of Casterbridge opens a new Lidl supermarket.</p>
 </figcaption>
</figure>

E:

<figure>
<img src=blah.png alt="Mayor of Casterbridge opens a new Lidl supermarket.">
 <figcaption>
  Mayor of Casterbridge opens a new Lidl supermarket.
</figcaption>
</figure>

Steve will wrap up the quiz next Thursday.

HTML5 Simplequiz #4: figures, captions and alt text originally appeared on HTML5 Doctor on November 5, 2010.

This SimpleQuiz is a bit different to previous SimpleQuizzes, since we’d like to use the result of this quiz to inform a design decision in the HTML5 spec. The question concerns how to mute a video in markup, and how this should be reflected in the DOM.

The use case is wanting to have multiple videos playing at once, but with all but one being muted at a time. This can be done today by setting .muted = true with script, but it would be more convenient to be able to mute with markup.

The .muted IDL attribute reflects the user setting of muted for the video element — if the user clicks “mute” in the native video controls, then the value of .muted changes, and vice versa. It would make sense for the browser to remember the mute setting for individual video elements on page reload (or later visit), so that the user doesn’t have to re-mute them.

This is where it starts to get hairy if we introduce a content attribute for muting. (Note that code fragments below aren’t real code, just suggestions.)

We could introduce muted="" which is reflected by .muted (i.e. if one changes, so does the other), but this would cause the DOM to mutate during parsing if the remembered setting doesn’t match the markup, i.e. you would get muted="" to appear in the DOM if the video is muted by the user even though there was no such attribute in the markup, which could confuse your scripts or style sheets if it’s not what you expected to happen.

We could introduce defaultmuted="" which is reflected by .defaultMuted, and just let the user setting change .muted, but defaultmuted="" is a bit long and ugly in markup.

We could have muted="" which is reflected by .defaultMuted and let the user setting change .muted, but it might be confusing for some people. On the other hand it is consistent with <input value> and .defaultValue.

What do you think? Which is the best option? Is there another option that is better than any of the above?

HTML5 Simplequiz #3: how to mute a video originally appeared on HTML5 Doctor on October 15, 2010.