Adaptive images are the next unsolved mystery of Responsive Web Design. Do you send large high-res images suitable for retina dispays, which are scaled down on smaller, lower res devices and which therefore waste bandwidth? Or do you send low-res images, whch look grotty when scaled up to large screens or high-res displays? Authors have had to rely on elaborate hacks to send different content images (that is <img> in HTML rather than CSS background images) to different types of devices.

By November 2011, I was so frustrated that no specification body was considering the problem that I proposed a strawman <picture> element that re-used the mechanism of HTML5 <video> with its media queries to swap in different source files:

<picture alt="angry pirate">
   <source src=hires.png media="min-width:800px">
   <source src=midres.png media="min-width:480px">
   <source src=lores.png>
      <!-- fallback for browsers without support -->
      <img src=midres.png alt="angry pirate">
</picture>

Around the same time, others independently came to the same idea and were advised to set up a W3C community group to discuss it which they did. However, in January, the HTML5 editor, Ian Hickson, had said

What’s the use case for doing it for images in <img> elements? Typically <img> elements are for content images, where you don’t usually want to adapt anything.

Those web authors in the W3C Resposive Images Community Group soldiered on in frustration that they were they being ignored because the problem itself wasn’t seen as a problem. Then this week, Edward O’Connor of Apple suggested another method, using a new srcset attribute on the <img> element. This complemented a similar suggestion of his from February for img-set in CSS that is already being added to WebKit:

<img src="foo-lores.jpg"
     srcset="foo-hires.jpg 2x, foo-superduperhires.jpg 6.5x"
     alt="decent alt text for foo.">

The numbers “2″ and “6.5x” tell the browser the relative resolutions; foo-hires.jpg is 2x the resolution of foo-lores.jpg.

Only a few days later, a variant of Apple’s suggestion was added to the spec.

There are two major differences between <picture> and srcset. The most obvious is that srcset uses the <img> element, which is great because that’s the natural place for images, adaptive or not. (You can’t re-use the <video> + <source> pattern with <img> because it is an empty element so can’t have child elements. O’Connor’s solution uses attributes, which are fine.)

The other major difference is that it doesn’t use Media Queries. With Media Queries, the author is reponsible for thinking up every permuations of viewport size, orientation, dpi, colour depth, aspect ratio and the like, deciding how to cater for them (if at all), identifing the breakpoints and coding them up. This requires a lot of consideration by the author, and makes for verbose code; a page with 20 pictures, each with 5 Media Queries on 5 <source> elements quickly becomes a lot of code.

O’Connor wrote

Why provide a scale factor and not a media query? Well, media queries are claims about UA state, whereas here we’re asserting something about the relationship between the image assets. Also, User Agents should be free to use whichever asset they deem best suited to their current situation, taking into account not just “media-queriable things” like device resolution but also any scaling applied to the <img> with CSS, its width=”" and height=”" attributes, or even things like the current page zoom level.

I have a lot of sympathy with allowing the browser to make decisions about what it knows of the environment (network speed, latency, pixel density, orientation) to choose the best image for the job. The idea is that the author shouldn’t be expected to anticipate and cater for all those variables. What she can do is describe the things she knows about -the images, their size and pixel density- and the browser will make its choice.

That way, when we’re all living in space and looking a 3D holograms, the proximity to a black hole can be detected by the iDroid3000 device (black holes notoriously cause Web hologram negative timespace inversions) and the right image chosen; we don’t need to invent new media queries for event horizon proximity and retrospectively add it to our websites.

There are two problems with the srcset suggestion. The first is highly subjective, but many feel the same: as it exists in the current, first draft of the spec, the syntax is revolting:

<img src="face-600-200-at-1.jpeg" alt=""
srcset="face-600-200-at-1.jpeg 600w 200h 1x,
face-600-200-at-2.jpeg 600w 200h 2x,
face-icon.png 200w 200h">

Of course, this can be improved, and must be. This isn’t just about aesthetics. If the syntax is too weird, it will be used wrongly. As Dr Remy wrote, “Good to see authors have another microsyntax to learn. It’s not like they had any trouble with vendor-prefixes.”

The second problem is that authors don’t want to relinquish control. There are questions of art direction (see the section headed Do I care about art direction?), and many remain unconvinced that the Apple suggestion addresses that; proponents of srcset are convinced that it does address those use cases.

Debate continues, with a full and frank exchange of views. There are understandably hurt feelings, too, because some of those who laboured in the Community Group feel that their wishes and work have been ignored.

As one of those who proposed <picture>, I have a degree of attachment to it. That’s ego. (In fact, I’d be delighted if it were called the <yayBruce> element, but I’m resigned to the unfairness of life.) But I don’t really care which syntax makes the spec, as long as it addresses the majority of use cases and it is usable by authors. I’m just glad we’re discussing the adaptive image problem at all.

So, get involved. Read the discussions and say your piece. And once the dust has settled and the specification is looking stable, we Doctors will write up our diagnosis.

HTML5 adaptive images: end of round one originally appeared on HTML5 Doctor on May 16, 2012.

But what’s a middle-aged colour-blind bloke to do? I had early in the curtain procurement process decided against cutting a hole in the carpet in order that I may take a sample with me. (All other mistakes aside, this was a correct decision.)

So, in order to ensure that I would never again repeat the mistake, I set out to make an app that would allow me to capture the colour of an image straight from my camera. Of course, it had to be a web app rather than a native app, because we’re web angels, not proprietary devils.

 if (navigator.getUserMedia) {
  // do something cool
} else {
  // fallback code
}

<form enctype="multipart/form-data" method="post">
  <input type="file" accept="video/*;capture=camera" />
</form>

navigator.getUserMedia({audio: true, video: true}, success, error);

function success(stream) { 
  // ... use 'stream' ... 
} 

function error(){ 
  // display fallback content 
}

<video autoplay></video>
<script>
if (navigator.getUserMedia) {
  navigator.getUserMedia({audio: true, video: true}, success, error);
  function success(stream)
  { 
    // ... use 'stream' ...
    var video = document.getElementsByTagName('video')[0];
    video.src = stream; 
  }
  // ...
</script>

video = document.getElementById('video');

Doing Exciting Things with the Video Stream #

So far, we’re only echoing the video stream. But, as you’ll know from Tab Atkins’ guest article video + canvas = magic, if we copy the video into a canvas, we can manipulate it:

var video = document.querySelector('video');
var canvas = document.querySelector('canvas');
var ctx = canvas.getContext('2d');

ctx.drawImage(video, 0, 0, video.width, video.height,
  0, 0, canvas.width, canvas.height);

A common mistake is assuming that this somehow establishes a “live connection” between the video stream and the canvas. It doesn’t. It only grabs the current frame. So you need to grab the current frame repeatedly in order to replicate a video. The magical number is 15 times a second (or every 67 milliseconds), but a slower frame rate would probably be okay for this demo:

setInterval(function () { 
  ctx.drawImage(video, 0, 0, video.width, video.height,
  0, 0, canvas.width, canvas.height);
}, 1000 / 67);

See the working demo.

What I want to do now is to grab the dominant colour from the canvas. I’m stealing a demo by Shwetank Dixit (who borrowed from Lokesh Dhakar‘s Color Thief demo). We won’t look at how it determines the dominant colour (because that’s nothing to do with getUserMedia).

Try this in Opera Labs and Chrome Canary!

Unfortunately, this works splendidly in Opera but it occasionally fails in Chrome, and we’re not sure why. (We’ve emailed the Chrome team to ask them.) Apart from the rather anti-climactic end to an article, you shouldn’t be dismayed by this. getUserMedia is only available in experimental builds that have plenty of work to be done before they hit production.

Back to our demo. Once you’ve got the dominant colour, you could prompt the user for a name for that colour (“carpet”, for example) and store that in local storage using its name as a key. Then, when you find a pair of curtains in the shop, you can find their dominant colour and easily compare it with that stored against “carpet” from earlier.

And you can return home, confident of delighting the love of your life with your chromatically appropriate choice of soft furnishings. That’s HTML5: enriching marriages since 2004.

Harshing Your Mellow #

Things need refining before web apps with getUserMedia are on a par with native applications. At the moment, there is no way of controlling which camera is to be used (and no agreement that a developer should be able to). The camera’s flash mechanism isn’t programmatically controllable, which could harm the user experience. Most importantly are the privacy implications of web pages being able to access your camera. Opera has an experimental privacy UI, but Chrome has no UI yet.

More Demos #

See Paul Neave’s HTML5 Webcam Toy and the links at the foot of my Opera Labs article.

Thanks #

Thank for help and code are due to Robin Berjon, Shwetank Dixit, Daniel Davis, Lokesh Dhakar, Mike Taylor, Mike Robinson, and Rich Tibbett.

Addy Osmani’s Polyfill

Added 13 March 2012: Addy Osmani has published a getUserMedia polyfill called getUserMedia.js, which uses Flash if gUM isn’t available. It’s not ready for production yet, as IE is still being tested. Forkers may hit the ‘hub.

Related Posts:

• How to get all the browsers playing ball
• Using Modernizr to detect HTML5 features and provide fallbacks
• Introducing Web SQL Databases
• HTML5: briefing notes for journalists and analysts
• video + canvas = magic

It’s Curtains for Marital Strife Thanks to getUserMedia originally appeared on HTML5 Doctor on February 7, 2012.

]]>

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.