Journal tags: html5

57

sparkline

Clarity

Two good things have happened.

WHATWG

Firstly, as I hoped, the WHATWG have updated the name of their work to simply be HTML. This is something they tried to do a year ago, and I kicked up a stink. I was wrong. Having a version number attached to an always-evolving standard just doesn’t make sense. As Hixie put it:

…the technology is not versioned and instead we just have a living document that defines the technology as it evolves.

This change means that the whole confusing 2022 business that was misunderstood by so many people is now history:

Now that we’ve moved to a more incremental model without macro-level milestones, the 2022 date is no longer relevant.

The spec is currently labeled as a “Living Standard”. Personally, I find the “Living Standard” strapline a bit cheesy. I’d much rather the document title was simply “HTML” followed by the date of the last update.

Note that this change only applies to the WHATWG. The W3C will continue to pursue the “snapshot” model of development so the spec there definitely retains the number 5 and will follow the usual path of Working Draft, Last Call, Proposed Recommendation, and so on.

I think this difference makes it clearer what each group is doing. It was a pretty confusing situation to have two groups working on two specs, both called HTML5. Now it’s clear that the WHATWG is working more like how browsers do: constantly evolving and implementing features rather than entire specifications. Meanwhile the W3C are working on having a development milestone of those features set in stone and labelled as the fifth revision to the HTML language …and I think that is also an important and worthy goal.

W3C

The second piece of good news is that the W3C have backtracked on their “embrace and extend” attitude towards buzzwordism. When they launched the new HTML5 logo a few days ago, the W3C Communications Team initially said that HTML5 included CSS, SVG and WOFF‽ As Tantek said:

Fire the W3C Communications person that led this new messaging around HTML5 because it is one of the worst messages (if not the worst) about a technology to ever come out of W3C.

Following the unsurprising outbreak of confusion and disappointment that this falsehood caused, the W3C have now backtracked. HTML5 means HTML5. The updated FAQ makes it very clear that CSS3 is not part of HTML5.

Hallelujah!

I really wasn’t looking forward to starting every HTML5 workshop, presentation or article with the words, “Despite what the W3C says, HTML5 is not a meaningless buzzword…” Now I can safely say that the term “HTML5” refers to a technical specification, published at the W3C, called HTML5. Also, I can use that nice logo with a clear conscience.

Over time though, I’ll probably follow the WHATWG’s lead and simply talk about “what’s new in HTML.” As Remy points out, there are pedagogical advantages to untethering version numbers:

I don’t have to answer “Is HTML ready to be used?” ‘cos that’s a really daft question!

Marklar Malkovich Smurf

  • Webmonkey: HTML5 Gains Logo, Loses Meaning

    It doesn’t really matter if the New York Times thinks CSS 3 or SVG are HTML5, but we’d like to think that at least the organization in charge of describing what is, and is not, HTML5 would make some effort to distinguish between tools. Lumping everything together is as silly as a carpenter referring to every tool in their toolkit as “a hammer.”

  • CNET News: W3C’s new logo promotes HTML5—and more

    Curiously, though, the standards group—the very people one might expect to have the narrowest interpretation of what exactly HTML5 means—instead say it stands for a swath of new Web technologies extending well beyond the next version of Hypertext Markup Language.

  • GigaOM: The Truth Behind HTML5′s New Logo Fiasco

    It’s as if the government suddenly announced that from today, all vegetables will be called potatoes, just because some vegetables are potatoes.

  • The Register: W3C tackles HTML5 confusion with, um, more confusion

    And much like Apple, Google, and Microsoft before it, the organization that oversees HTML5 has confused it with all sorts of other web standards.

  • The Web Standards Project: HTML5 logo: be proud, but don’t muddy the waters!

    Now the W3C has come out and essentially condoned the branding of everything from CSS to actual HTML5 to WOFF as “HTML5”. We can’t imagine a single action that will cause more confusion than this misguided decision (and the W3C has produced some pretty impenetrable specs in its time)

  • Roger Johansson: HTML5 now includes CSS3, SVG and WOFF?

    This move from the W3C will not help people differentiate between very different technologies.

  • CSS Squirrel: HTML5 Super Friends Assemble!

    The logo is pretty, but the intentional use of HTML5 as a blanket term for other modern web technologies is a crock. Newspapers making merry with the term is one thing, but a web standards organization?

Bye, bye 5

One year ago, I objected strenuously when the WHAT WG temporarily changed the name of their spec from “HTML5” to plain ol’ “HTML”:

Accurate as that designation may be, I became very concerned about the potential confusion it would cause.

I understand why the WHATWG need to transition from using the term HTML5 to simply using the term HTML to describe their all-encompassing ongoing work, but flipping that switch too soon could cause a lot pain and confusion.

Now that term the “HTML5” has become completely meaningless—even according to the WC3—I think it’s time to rip off the bandaid and flip that switch.

I was wrong. Hixie was right. The spec should be called HTML.

If you need an all-encompassing term for every front-end technology under the sun, go ahead and use the term “HTML5.” Although personally, I quite like “the Web.”

Update: The WHATWG have duly updated the name of the spec.

Badge of shame

The W3C have unveiled a logo for HTML5. I’m not sure the world needs such a logo, but I think it looks pretty good. It reminds me of some of the promotional materials used by the Web Standards Project back in the day—simple bold lines that work well at small sizes, with a whiff of Russian constructivism.

But I take issue with the scope of what this logo is supposed to represent. From the Frequently Asked Questions:

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

What. A. Crock.

What we have here is a deliberate attempt to further blur the lines between separate technologies that have already become intertwingled in media reports.

Don’t get me wrong; I don’t mind if marketers and journalists use HTML5 to mean everything under the sun, but I expect working web developers to be able to keep specs separate in their mind. If Apple or Google were pushing this kind of fuzziness, I wouldn’t mind …but this is coming straight from the horse’s mouth (or, in this case, straight from the horse’s ass).

“But,” cry the cheerleaders of ambiguity, “we need some kind of term to refer to HTML5 plus CSS3!”

Citation needed.

We never needed a term to refer to “XHTML 1.0 plus CSS2.1” or “HTML4.01 plus JavaScript” or “any combination of front-end technologies.” Why this sudden all-conquering need for a term that covers so many different technologies as to be completely meaningless? As I said before:

Clarifying what is and isn’t in HTML5 isn’t pedantry for pedantry’s sake. It’s about communication and clarity, the cornerstones of language.

But I guess I’ve lost that battle. Now even the W3C are intent on blurring the distinction between different technologies to the extent that using a particular font file format qualifies as HTML5.

So now what do I do when I want to give a description of a workshop, or a talk, or a book that’s actually about HTML5? If I just say “It’s about HTML5,” that will soon be as meaningful as saying “It’s about Web 2.0,” or “It’s about leveraging the synergies of disruptive transmedia paradigms.” The term HTML5 has, with the support of the W3C, been pushed into the linguistic sewer of buzzwordland. Instead, I will try using phrases:

  • “HTML5, no really”,
  • “The parts of HTML5 that are documented in the specification labelled HTML5”,
  • “Actual HTML5”

But I think the term that’s going to be most accurate is:

  • “HTML”

Update: The W3C have changed their mind. Yay!

The design of datalist

One of the many form enhancements provided by HTML5 is the datalist element. It allows you to turn a regular input field into a .

Using the list attribute on an input, you can connect it to a datalist with the corresponding ID. The datalist itself contains a series of option elements.

<input list="suggestions">
<datalist id="suggestions">
    <option value="foo"></option>
    <option value="bar"></option>
    <option value="baz"></option>
</datalist>

I can imagine a number of use cases for this:

  • “Share this” forms, like the one on Last.fm, that allow you to either select from your contacts on the site, or enter email addresses, separated by commas. Using input type="email" with a multiple attribute, in combination with a datalist would work nicely.
  • Entering the details for an event, where you can either select from a list of venues or, if the venue is not listed, create a new one.
  • Just about any form that has a selection of choices, of which the last choice is “other”, followed by “If other, please specify…”

You can take something like this:

<label for="source">How did you hear about us?</label>
<select name="source">
    <option>please choose...</option>
    <option value="television">Television</option>
    <option value="radio">Radio</option>
    <option value="newspaper">Newspaper</option>
    <option>Other</option>
</select>
If other, please specify:
<input id="source" name="source">

And replace it with this:

<label for="source">How did you hear about us?</label>
<datalist id="sources">
    <option value="television"></option>
    <option value="radio"></option>
    <option value="newspaper"></option>
</datalist>
<input id="source" name="source" list="sources">

The datalist element has been designed according to one of the design principles driving HTML5—Degrade Gracefully:

On the World Wide Web, authors are often reluctant to use new language features that cause problems in older user agents, or that do not provide some sort of graceful fallback. HTML 5 document conformance requirements should be designed so that Web content can degrade gracefully in older or less capable user agents, even when making use of new elements, attributes, APIs and content models.

Because the datalist element contains a series of option elements with value attributes, it is effectively invisible to user-agents that don’t support the datalist element. That means you can use the datalist element without worrying it “breaking” in older browsers.

If you wanted, you could include a message for non-supporting browsers:

<datalist id="sources">
    Your browser doesn't support datalist!
    <option value="television"></option>
    <option value="radio"></option>
    <option value="newspaper"></option>
</datalist>

That message—“Your browser doesn’t support datalist!”—will be visible in older browsers, but browsers that support datalist know not to show anything that’s not an option. But displaying a message like this for older browsers is fairly pointless; I certainly wouldn’t consider it graceful degradation.

In my opinion, one of the best aspects of the design of the datalist element is that you can continue to do things the old-fashioned way—using a select and an input—and at the same time start using datalist. There’s no violation of either; you can use the same option elements for the select and the datalist:

<label for="source">How did you hear about us?</label>
<datalist id="sources">
    <select name="source">
        <option>please choose...</option>
        <option value="television">Television</option>
        <option value="radio">Radio</option>
        <option value="newspaper">Newspaper</option>
        <option>Other</option>
    </select>
    If other, please specify:
</datalist>
<input id="source" name="source" list="sources">

Browsers that support datalist will display the label “How did you hear about us?” followed by a combo-box text field that allows the user to select an option, or enter some free text.

Browsers that don’t support datalist will display the the label “How did you hear about us?” followed by a drop-down list of of options (the last of which is “other”), followed by the text “If other, please specifiy”, followed by a text field.

Take a look at this example in Opera to see datalist in operation. Take a look at it in any other browser to see the fallback. The source is on Github if you’d like to play around with it.

WebKit’s mistake

If you try that example in any browser, you’ll get something that works; either through datalist support or through the select fallback …unless the browser is using WebKit.

It took me a while to figure out why this would be the case. I didn’t think that Safari or Chrome supported datalist and a little digging around with object detection in JavaScript confirmed this. So why don’t those browsers follow the standard behaviour and simply ignore the element they don’t understand and render what’s inside it instead.

Here’s the problem: line 539 of WebKit’s default CSS:

datalist {
    display: none;
}

This is pretty much the worst possible behaviour for a browser to implement. An element should either be recognised—like p, h1 or img—and parsed accordingly, or an element is unrecognised—like foo or bar—and ignored. WebKit does not support the datalist element (even in the current nightly build), so the element should be ignored.

Fortunately the problem is easily rectified by adding something like this to your own stylesheet:

datalist {
    display: inline-block;
}

I’ve submitted a bug report on the WebKit Bugzilla.

Update: That Webkit bug has now been fixed so the extra CSS is no longer necessary.

Landmark roles

David made a comment on Twitter about some markup he was working on:

Feels dirty setting id’s on main HTML5 page header and footer, but overriding inheritance they cause seems needlessly laborious.

I know the feeling. I don’t like using IDs at all, unless I want part of a document to be addressable through the fragment identifier portion of the URL. While I think it’s desirable to use the id attribute to create in-document permalinks, I don’t think it’s desirable to use the id attribute just as a styling hook. Its high specificity may seem a blessing but, in my experience, it quickly leads to duplicated CSS. IDs are often used as a substitute for understanding the cascade.

Nicole feels the same way about ID selectors, and she knows a thing or two about writing efficient CSS.

Back to David’s dilemma. Let’s say you’re targetting header and footer elements used throughout your document in sections, articles, etc. All you need to use is an element selector:

header {
// regular header styles
}

But what about the document-level header and footer? They’re probably styled very differently from the headings of sections and articles.

You could try using a child selector:

body > header

But there’s no guarantee that the document header will be a direct child of the body element. Hence the use of the id attribute—header id="ID":

header#ID {
// page header styles
}

There is another way. In HTML5 you can, for the first time, use ARIA roles and still have a valid document. ARIA landmark roles add an extra layer of semantics onto your document, distinguishing them as navigational landmarks for assistive technology.

Some of these landmark roles—like IDs—are to be used just once per document:

Within any document or application, the author SHOULD mark no more than one element with

That’s useful for two reasons. One, the existence of role="main" means it is not necessary for HTML5 to provide an element whose only semantic is to say “this is the main content of the document.”

A lot of people have asked for such an element in HTML5. “We’ve got header, footer and aside,” they say. “Why not maincontent too?”

But whereas header, footer and aside can and should be used multiple times per document, a maincontent element would, by necessity, only be used once per document. There are very few elements in HTML that are like that: the html element itself, the title element, head and body (contrary to popular opinion—likely spread by SEO witch-doctors—the h1 element can be used more than once per document).

Now the desired functionality of semantically expressing “this is the main content of the document” can be achieved, not with an element, but with an attribute value: role="main".

The rough skeleton of your document might look like this:

<header role="banner"></header>
<div role="main"></div>
<footer role="contentinfo"></footer>

Now you can see the second advantage of these one-off role values. You can use an attribute selector in your CSS to target those specific elements:

header[role="banner"] {
// page header styles
}

Voila! You can over-ride the default styling of headers and footers without resorting to the heavy-handed specificity of the ID selector.

And, of course, you get the accessibility benefits too. ARIA roles are supported in JAWS, NVDA and Voiceover

The URI is the thing

Here’s what’s on my desk at work: an iMac (with keyboard, mouse and USB cup warmer), some paper, pens, a few books and an A4-sized copy of Paul Downey’s The URI Is The Thing—an intricately-detailed Boschian map of all things RESTful. It’s released under a Creative Commons license, so feel free to download the PDF from archive.org, print it out and keep it on your own desk.

I love good URL design. I found myself nodding vigorously in agreement with just about every point in this great piece on URL design:

URLs are universal. They work in Firefox, Chrome, Safari, Internet Explorer, cURL, wget, your iPhone, Android and even written down on sticky notes. They are the one universal syntax of the web. Don’t take that for granted.

That’s why I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness, but it’s related to what Ben said in his comment to Nicholas’s article on how many users have JavaScript disabled:

The truth is that if site content doesn’t load through curl it’s broken.

Or, as Simon put it:

The Web for me is still URLs and HTML. I don’t want a Web which can only be understood by running a JavaScript interpreter against it.

If I copy and paste the URL of that tweet, I get http://twitter.com/#!/simonw/status/25696723761 …which requires a JavaScript interpreter to resolve.

Fortunately, those fragile Twitter URLs will be replaced with proper robust identifiers if this demo by Twitter engineer Ben Cherry is anything to go by. It’s an illustration of saner HTML5 history management using the history.pushState method.

Spacelift

My sojourn up the western seaboard of the United States has come to an end. It began in San Diego with the final An Event Apart of the year, which was superb as always. From there, I travelled up to San Francisco for Cindy and Matt’s wedding celebration, followed by a few days in Seattle. The whole trip was rounded out back in California at the wonderfully titled Institute For The Future in Palo Alto. For that was the location of Science Hack Day San Francisco.

It was an amazing event. Ariel did a fantastic job—she put so much effort into making sure that everything was just right. I suspected it was going to be a lot of fun, but once again, I was blown away by the levels of ingenuity, enthusiasm and sheer brilliance on display.

In just 24 hours, the ingenious science hackers had created particle wind chime which converts particle collisions into music that Brian Eno would be proud of, grassroots aerial mapping with balloons which produced astonishing results (including an iPad app), as well as robots and LEDs a-plenty. The list of hacks is on the wiki.

Science Hack Day San Francisco Science Hack Day San Francisco Science Hack Day San Francisco Science Hack Day San Francisco

My own hack was modest in scope. Initially, I wanted to build a visualisation based on Matt’s brilliant idea, but I found it far too daunting to try to find data in a usable format and come up with a way of drawing a customisable geocentric starmap of our corner of the galaxy. So I put that idea on the back burner and decided to build something around my favourite piece of not-yet-existing technology: the .

The idea

Spacelift compares the cost efficiency of getting payloads into geosynchronous orbit using a space elevator compared to traditional rocketry. Basically, it’s a table. But I’ve tried to make it a pretty table with a bit of data visualisation to show at a glance how much more efficient a space elevator would be.

The payloads I’ve chosen are spacecraft. Beginning with the modest Voyager 1, it gets more and more ambitious with craft like an X-Wing or the Millennium Falcon before getting crazy with the USS Enterprise and the Battlestar Galactica.

So, for example, while you could get a TIE-fighter into the Clarke belt using a single , two , or three , it would cost considerably more than using a space elevator, where you’re basically just paying for the electricity.

If you click on the dollar amount for each transport mechanism, you’ll see the price calculated as a tower of pennies. Using a , for example, will cost you a tower of pennies 22 times larger than a space elevator, assuming a space elevator is at least 38,000 kilometres tall/long. Using a space elevator, on the other hand, requires spending a tower of pennies about the same height as itself. I don’t even bother trying to visualise the relative height differences for getting anything bigger than the Tantive IV into orbit as it would require close to infinite scrolling.

I’m fairly confident of the cost-per-kilogram values for the rockets while the is necessarily fuzzy, given that the mechanism doesn’t exist yet. But by far the trickiest info to track down was the mass of fictional spacecraft. There’s plenty of information on dimensions, speed and armaments, but very little on weight. Mathias saved the day with some diligent research that uncovered the motherlode.

Having such smart, helpful people around made the whole exercise a joy. It was quite a pleasure to walk over to a group of hackers, ask Is anyone here a rocket scientist? and have at least one person raise their hand. The constant presence of Cosmos playing on a loop just added to the atmosphere of exploration and fun.

Implementation

I’ve put the code on GitHub, ‘cause that’s what a real hacker would do. It’s my first GitHub repository. Be gentle with me.

There’s CSS3 and HTML5 a-plenty. I deliberately don’t use the IE shim to enable styling of HTML5 structural elements in lesser versions of Internet Explorer; there wouldn’t be much point delivering RGBa, opacity and text-shadow styles to a browser that can’t handle ‘em.

The background colour changes depending on the payload. I’m using a variation of the MD5 colour encoding popularised by Dopplr and documented by Brian in his excellent new book, Designing With Data.

I’m using League Gothic by The League Of Movable Type for the type—ya gotta have a condensed font for data visualisations, right?

There’s also a google-o-meter image from the Google chart API.

Needless to say, the layout is responsive and adapts to different viewing environments …including print.

Spacelift, printed

Using CSS transforms, each page of table of price comparisons becomes a handy page to print out and stick on the office wall to remind yourself why the human race needs a space elevator.

Speaking and moving

I was in Amsterdam at the end of last week for the Fronteers conference. It was a good conference but the fact that Jake Archibald was on the bill meant that my presentation paled in comparison—he remains one of the finest and most entertaining speakers I have ever seen.

I gave a talk on The Design of HTML5: much the same talk as I gave at Drupalcon. You can download the slides if you want, and the video is already online.

The presentation is licensed under a Creative Commons attribution license so feel free to download the video and do with it as you will. I’d love to get the presentation transcribed. If six or seven people are willing to transcribe about ten minutes of audio, we can get this done fairly easily. Get in touch if you don’t mind spending some time on it and I’ll try to co-ordinate the efforts. I can’t offer any financial reward, but of course your efforts will be credited and you’ll be helping to make the information more findable.

If video isn’t your thing, you might enjoy listening to an interview I did recently for the Einstein and Sock Monkey podcast.

Einstein & Sock Monkey — Episode 4: HTML5 Madness!! on Huffduffer

My next speaking trip will be to California. I’m off to San Diego for the final leg of this year’s An Event Apart. If you didn’t make it to An Event Apart this year, don’t fret: tickets are now on sale for next year’s six shows, and I’m proud to be speaking at all six.

I’ll be heading out to San Diego at the very end of October. That means I’m not going to be in Brighton for this year’s Crawl of the Dead, which is a real shame.

After San Diego, I’ll be heading up to San Francisco. It’s been far too long since I was last there. I’m really happy that I’ll be there for Science Hack Day San Francisco that Ariel is organising at The Institute for the Future in Palo Alto on November 13th and 14th. It’s going to be an excellent event and I highly recommend that you sign up if you can make it.

While my flight to the States is already booked, I haven’t yet sorted out my travel from San Diego to San Francisco. On the off-chance that anyone out there from San Francisco is planning on travelling to An Event Apart San Diego by car, let me know if you fancy a travelling companion for the ride back. I hear it’s a beautiful scenic drive.

Delivering Sorrow

Hot on the heels of the work for St. Paul’s School, I’ve been tweaking the media queries for the Salter Cane website. I was switching the site over to using HTML5 structural elements anyway, so I figured I’d meddle with the CSS while I was at it.

Once again, the fact that the site was already using percentages made the process very straightforward. Depending on the viewport width, the layout changes from three columns to two columns to one column.

Salter Cane (1440) Salter Cane (1024) Salter Cane (760) Salter Cane (480)

And once again, I didn’t remove any content for small screen devices. The natural language navigation at the top of the page—now correctly ensconced in a nav element—really comes into its own in the linearised layout, allowing for quick access to different sections of the document.

The timing of all this optimisation is fortuitous. The second Salter Cane album has just been released: it’s called Sorrow.

It already has some fans. Shaun said:

The Truth Is Nothing sounds like Leonard Cohen, Johnny Cash and Arcade Fire had a musical transporter accident. can’t stop listening to it.

Lachlan is equally enthusiastic. If you like what you hear, you can buy the physical album from CD Baby or buy the digital album from iTunes. It will be available on Spotify and Amazon soon.

All the songs are licensed under a Creative Commons attribution license which means that they are . I’m looking forward to seeing where they end up.

You can listen to the whole album on the Salter Cane site using a Flash MP3 player. The documentation for Audio Player reads:

To insert a player on the page, place an HTML element and give it a unique ID. This element will be replaced with a player. If the browser doesn’t support Audio Player, the element will not be replaced so use it to show alternative content (maybe a message telling the user to download Flash).

The example code looks like this:

<p id="audioplayer_1">Alternative content</p>
<script type="text/javascript">
AudioPlayer.embed("audioplayer_1", {soundFile: "file.mp3"});
</script>

But rather than using a P element, I used the HTML5 audio element:

<audio id="audioplayer_1" src="file.mp3" controls="controls" preload="none">
</audio>  
<script>  
AudioPlayer.embed("audioplayer_1", {soundFile: "file.mp3"});  
</script>

That way, browsers with Flash installed get the plugin while other devices—like, say, the iPhone, iPod and iPad—get the native audio player.

Audio

Whatever device you’re using, enjoy listening to Sorrow by Salter Cane.

Scandinavian sojourn

I’ve been on a little trip to Copenhagen. Usually when I go to Denmark, it’s for Reboot but alas, there is no Reboot this year. Instead, I was there for Drupalcon.

I have to admit, it was quite a surprise to be asked to speak at a Drupal event. After all, I don’t use the Drupal framework. To be fair, I don’t use any framework—though I did dabble with Django once. Clearleft is a backend-agnostic company: we do UX, IA, front-end, but we’ve deliberately avoided committing to one particular server-side solution.

Anyway, I was kinda nervous about addressing a large group of programmers devoted to a PHP framework that I’m not that familiar with. I needn’t have worried. Everyone was incredibly welcoming and I got a very warm reception.

I had been asked along to speak about HTML5 but rather than just run through a whole bunch of features in the spec, I thought it would be more interesting to talk about why features have been added to HTML5. So I concentrated on the design principles driving the development of the specification.

I’m pretty pleased with how it turned out. The whole thing was streamed live and it’s all been recorded and posted online.

The Drupal community is clearly very vibrant: the 1000+ people gathered in Copenhagen were very enthusiastic about their chosen platform. That said, I did sense some frustration from the theming community—it isn’t always the easiest to change the markup and CSS that’s output by Drupal. This is something that Dries acknowledged in his keynote and people like Jen Simmons are fighting the good fight to improve Drupal’s front-end output.

The Drupal community also know how to party. This was the first conference I’ve been to that had its own beer; the rather excellent Awesomesauce from the world-renowned Mikkeller.

All in all, it was a thoroughly enjoyable experience. And I had enough time before my flight back to Blighty to nip across to Malmö in Sweden, where Emil showed me the sights.

Then it was time to catch a ludicrously comfy train across a remarkable bridge, past a stunning wind farm to the snazilly-designed airport to catch my flight home.

Clarification

HTML5.

You keep using that word.

In a comment on one of Jeffrey’s blog posts, Tantek wrote:

We as a community that is learning/relearning/teaching all this stuff need to vigilantly clarify what’s what rather than calling things “HTML5″ that are not actually HTML5 (e.g. CSS3, Geolocation, etc. etc.), and correct the marketing messages being shouted from various rooftops so we can better understand and reliably build HTML5 websites and web applications that use HTML5.

Jeff Croft argues just the opposite:

Sometimes we just need a word to rally behind. And put in job descriptions. And claim we “support” (another word that is mostly meaningless). It’s a language thing and a human psychology thing.

For the most part, I think what Jeff is saying is fine …assuming we’re talking about managers, marketers, and other people who aren’t making websites for a living. For the rest of us down in the trenches, I think it is important to understand what is in which spec. As Jeff later clarifies:

That “HTML5” means something different to marketers than it does to web developer is an annoyance, no doubt — but I don’t think it hinders us any real way, and I don’t know that we need to, as Tantek suggests, “vigilantly clarify” the matter.

Fair enough. If someone in middle management wants to use the term HTML5 where they previously used, say, “Web 2.0”, that’s fine. But here’s the problem…

A couple of weeks ago, I got a got phone call out of the blue from a local web developer. My mobile number is listed right here—anyone is free to call me whenever they want. He had a reasonable enquiry. He wanted to know if he could pop ‘round to the Clearleft office and buy a copy of my new book directly from me rather than ordering it online.

Alas no, I said. That’s my personal stash, not for resale.

But while he had me on the phone, he asked a couple of questions about what’s in the book. I started talking about semantics and forms. He asked Does it cover CSS?

No. Nope. Definitely not. The book is very specifically about HTML5, not CSS3.

And then he said But CSS3 is part of HTML5, isn’t it?

He’s not in management. He’s not in marketing. He builds websites. And the scary thing is, I think he’s probably fairly representative of many working web developers.

Don’t get me wrong: I honestly don’t care that much about whether something like geolocation is technically part of HTML5 or not: that’s a fairly trifling matter. But CSS3? C’mon! In what universe is it in any way acceptable that a web developer wanting to learn about web fonts begins by Googling for HTML5?

Still, it could be worse. At least, to the best of my knowledge, no working web developers are quite as misinformed as the New Media Age journalist who listed some HTML5 Key Facts such as:

  • Supports sophisticated typography…
  • Supports social content and sharing…
  • Key features are part of CSS3…

Clarifying what is and isn’t in HTML5 isn’t pedantry for pedantry’s sake. It’s about communication and clarity, the cornerstones of language.

In Politics and the English Language, George Orwell wrote:

A bad usage can spread by tradition and imitation even among people who should and do know better.

Unboxing Apart

Writing a book is hard. Ask someone who’s writing a book right now how it’s going and chances are you’ll catch them at a bad moment.

But there are good moments. Writing the final words of a book: that’s a good moment. Having conversations with a kick-ass editor: those are good moments. Hearing that the book has been sent to the printer: that’s a really good moment.

The best moment of all is when you finally have the physical book in your hands.

HTML5 For Web Designers was delivered to the Clearleft office last week. The moment had arrived.

Joe once told me that the thing to do when you finally have a copy of your own book in your hands is to open it a random page and immediately find a typo. I’m happy to report that that little test returned no results.

Instead, I opened up the book at a random point, pressed my nose into it and breathed deeply. Ah, that new book smell!

It looks as good as it smells, which is hardly surprising given the care and attention that Jason poured into the design. Clearly I’m not alone in that appraisal. As the book gets delivered to discerning readers across the globe, Flickr is filling up with pictures of HTML5 For Web Designers fresh out of the box. I’ve added my own unboxing set to the mix.

Front cover Back cover HTML5 For Web Designers HTML5 For Web Designers Cath reading HTML5 For Web Designers Shannon reading HTML5 For Web Designers

Twitter is also abuzz with reports of the book’s arrival, although it’s also filled with an oft-repeated question: when will HTML5 For Web Designers be available in digital format?

It is with great pleasure that I give you… HTML5 For Web Designers on the iPad:

HTML5 For Web Designers on the iPad

Seriously though, there will be an ePub version available at some point, but we want to make sure that it’s top quality. In the meantime, get yourself the fragrant dead-tree version and enjoy the physical feel of it. You may even want to take a picture.

2010-06-25

On Friday, June 25th, three things will happen:

  1. Clearleft will spend the day having some lomography fun around Brighton with Lomokev.
  2. Salter Cane will play a rocking concert with Caramel Jack upstairs at The Prince Albert pub on Trafalgar Street.
  3. HTML5 For Web Designers will begin shipping—the book written by me, edited by Mandy, designed by Jason and published by Zeldman.

HTML5 For Web Designers

Awe Dee Oh

You may have noticed a lot of HTML5 vs. Flash talk lately. Substitute HTML5 for HTML5 video.

Frankly, I’m a little baffled by this supposed dichotomy because you don’t have to choose. The way that video works, according to the spec, is for fallback content to be placed between the opening and closing<video> tags. So you can go ahead and use object or embed or whatever you need to put your Flash video in your markup. Browsers that understand the video element will use that while less capable browsers will play the Flash movie in the object element (and because of the way the object element works, you can put yet another layer of fallback content between the opening and closing <object> tags).

It’s the same with audio. So, on Huffduffer, for example, I can wrap <audio> tags around the object element that embeds the Flash player:

<audio controls src="file.mp3">
 <object data="flashplayer.swf?audio=file.mp3">
  <param name="movie" value="flashplayer.swf?audio=file.mp3">
  <a href="file.mp3">ah, just download it</a>
 </object>
</audio>

But there’s a problem. Firefox understands the audio element but refuses to implement support for MP3 as long as it is patent-encumbered. Firefox users don’t get the fallback content (because the browser does support audio) but they don’t get the MP3 either. They get a broken icon.

So it’s safer to just use the Flash player, right? There’s a problem with that too. Mobile Safari doesn’t support Flash …but it does support the audio element. How can I serve up Flash to desktop browsers and HTML5 audio to the iPhone and iPad without going down the dark path of browser sniffing?

Easy. Just flip the order of what constitutes fallback content:

<object data="flashplayer.swf?audio=file.mp3">
 <param name="movie" value="flashplayer.swf?audio=file.mp3">
  <audio controls src="file.mp3">
   <a href="file.mp3">ah, just download it</a>
  </audio>
</object>

That works in Firefox—and any other browser with Flash installed—and it also works on the i(Pad|Phone|Pod).

Huffduffer — landscape

A site for Science Hack Day

I spent the weekend immersing myself in HTML5 and CSS3.

I gave Principia Gastronomica a bit of a fine-tuning under the hood. I decided to ditch all the background images I was using to get rounded corners and drop shadows, and just use border-radius and box-shadow instead. Internet Explorer gets the same content with more pointy corners and without the illusion of depth.

I also launched a brand new site: ScienceHackDay.org. It’s a small little site designed to quickly dispense relevant information on the upcoming geektastic Science Hack Day in London on June 19th and 20th.

The front page is also a blog. I’ll be posting updates about the event there and I’ll also be highlighting science projects and hack ideas. Subscribe to the feed if you want get updates.

I couldn’t be bothered installing or writing blogging software for the site. It seemed like overkill for such a quick’n’nimble project so I’m just blogging in HTML using . It’s converted to Atom using Luke Arno’s handy service. I was going to use the transcoder on Microformatic.com but I think it uses which means it won’t work on the new HTML5 elements.

The underlying structure is a combination of microformats, HTML5 structural elements and ARIA roles. The styling is over-the-top CSS3. There’s border-radius, opacity and RGBa a-plenty. Setting colours using opacity and alpha transparency makes it a breeze to customise the colours on each page, so the schedule, location and not-so-FAQ pages all have a slightly different tint.

Internet Explorer doesn’t get any of this colourful or roundy goodness. It does however, get the typography and layout, much like the print stylesheet view. I wouldn’t do that for client work but I’m perfectly happy to do it for a weekend project.

Check out the site and if you decide that Science Hack Day looks like your kind of event, add your name on the wiki.

You can also follow @sciencehackday on Twitter to get bite-sized updates as they happen.

The Big Web Show 2: HTML5 Boogaloo

I had the pleasure of joining hosts Dan and Jeffrey for the second episode of The Big Web Show.

We talked about Pete Townsend and cats that look like Hitler but mostly we talked about HTML5. Specifically, we talked about what’s between the covers of .

The audio is available for your huffduffing pleasure so go ahead and huffduff it if you fancy an hour’s worth of three-way markup action.

The Big Web Show 2: HTML5 with Jeremy Keith on Huffduffer

The format of The Long Now

In 01992, Tim Berners-Lee wrote a document called HTML Tags.

In September 02001, I started keeping this online journal. Back then, I was storing my data in XML, using a format of my own invention. The XML was converted using PHP into (X)HTML, RSS, and potentially anything else …although the “anything else” part never really materialised.

In February 02006, I switched over to using a MySQL database to store my data as chunks of markup.

In February 02007, Tess wrote about data longevity

To me, being able to completely migrate my data — with minimal bit-rot — from system to system is the key in the never-ending and easily-lost fight to keep my data accessible over the entirety of my life.

She’s using non-binary, well-documented standards to store and structure her data: Atom, HTML and microformats.

Meanwhile, the HTML5 spec began defining error-handling for HTML documents. Ian Hickson wrote:

The original reason I got involved in this work is that I realised that the human race has written literally billions of electronic documents, but without ever actually saying how they should be processed.

I decided that for the sake of our future generations we should document exactly how to process today’s documents, so that when they look back, they can still reimplement HTML browsers and get our data back, even if they no longer have access to Microsoft Internet Explorer’s source code.

In August 2008, Ian Hickson mentioned in an interview that the timeline for HTML5 involves having two complete implementations by 02022. Many web developers were disgusted that such a seemingly far-off date was even being mentioned. My reaction was the opposite. I began to pay attention to HTML5.

HTML is starting to look like a relatively safe bet for data longevity and portability. I’m not sure the same can be said for any particular flavour of database. Sooner rather than later, I should remove the unnecessary layer of abstraction that I’m using to store my data.

This would be my third migration of content. I will take care to head Mark Pilgrim’s advice on data fidelity:

Long-term data preservation is like long-term backup: a series of short-term formats, punctuated by a series of migrations. But migrating between data formats is not like copying raw data from one medium to another.

Fidelity is not a binary thing. Data can gradually degrade with each conversion until you’re left with crap. People think this only affects the analog world, like copying cassette tapes for several generations. But I think digital preservation is actually much harder, in part because people don’t even realize that it has the same issues.

He’s also betting on HTML:

HTML is not an output format. HTML is The Format. Not The Format Of Forever, but damn if it isn’t The Format Of The Now.

I don’t think that any format could ever be The Format Of The Long Now but HTML is the closest we’ve come thus far in the history of computing to having a somewhat stable, human- and machine-readable data format with a decent chance of real longevity.

Announcing HTML5 For Web Designers

For the third time in my life, I have written a book. HTML5 For Web Designers is available for pre-order now from A Book Apart.

That’s right—the same lovely people who brought you A List Apart are now delivering good ol’-fashioned dead tree publications.

The quality and craftsmanship of the resultant book is, as you would expect, stratospherically high. How could it not be given the team of superheroes who put it together:

Working with them has been an honour and a pleasure. I’m certain that is their generosity that spurred me on to deliver what is, in my opinion, the best thing I have ever written.

It’s not a long book. It’s about 16 kilowords long. That’s a feature, not a bug.

If I had more time, I would have written a shorter letter.

Whether that quote is attributable to Cicero, Twain or Pascal, it speaks to a real truth in writing. Omit needless words said William Strunk. Or, as Orwell wrote in Politics and the English Language:

If it is possible to cut a word out, always cut it out.

But that doesn’t mean that HTML5 for Web Designers is a mere exercise in brevity and information density. It’s also quite fun.

Fun isn’t a word that you often hear associated with technical subjects like markup languages but I knew that if I wanted to appeal to the right audience for this book, I had two watchwords:

  1. It has to be brief.
  2. It has to be entertaining.

That’s where the team behind A Book Apart really helped me.

I started with the first chapter and wrote it in my voice. This is usually the point at which a traditional publisher would respond with suggestions for improvements to the writing style to make itappeal to a wider audience …resulting in a watered-down bland shadow of the original.

Jeffrey, Mandy and Jason responded with so much enthusiasm and encouragement that I felt I could continue to just be myself when writing this book. The result is something I am truly proud of.

Given its brevity, HTML5 for Web Desigers is obviously not an exhaustive look at everything in HTML5. There is no mention of offline storage, drag’n’drop or any of the other advanced JavaScript APIs. Instead, I’ve focused on forms, rich media, and most importantly, semantics. The book is intended as a primer for web designers who are hearing a lot of conflicting and confusing things about this strange amalgamation of technologies called HTML5. I hope to bestow some measure of clarity and understanding.

The first hit is free. You can read chapter one, A Brief History of Markup, on A List Apart.

Jason describes the design process, Mandy tells of the business aspect and Jeffrey has written a very kind and flattering overview of the book. You can pre-order your copy now.

As excited and proud as I am of HTML5 for Web Designers, is it wrong that I am equally excited that the book is also an item on Gowalla?

Understanding

Every so often I’ll read something on the web that somebody else has written and I’ll think Yes! That! That’s what I’ve been trying to say!

I’ve already told of experiencing just that whilst reading Raiding Eternity. Now I’ve experienced it again. This time the culprit is Ben Ward, the talented bastard.

He reeled me in with the synopsis of his latest article. It’s called Understand The Web:

Perceptions of the web are changing. People are advocating that we treat the web like another application framework. An open, cross-platform, multi-device rival to Flash and Cocoa and everything else. I’m all for making the web richer, and exposing new functionality, but I value what makes the web weblike much, much more.

On the one hand, it’s a straightforward fact-check and slap-down for the factually-incorrect nonsense being spouted on Twitter and elsewhere by those who are reconstructing the history of the web as a work of fiction spun in the own minds to match their misunderstandings of how browsers and standards bodies work. As Ben puts it:

This is the short, perhaps selective memory that the internet suffers from. It is not acceptable to me that 21st century knowledge retention has become so short and shallow as to be overwritten by influential ranting on Twitter. A greater tool for the dissemination of misinformation has never been known.

But the real reason why you should read Ben’s piece is that it encourages all of us to take a step back and think about what the web really is. It’s not just a choice of platform for building applications (whatever that means), it’s so much more:

Want to know if your ‘HTML application’ is part of the web? Link me into it. Not just link me to it; link me into it. Not just to the black-box frontpage. Link me to a piece of content. Show me that it can be crawled, show me that we can draw strands of silk between the resources presented in your app. That is the web: The beautiful interconnection of navigable content. If your website locks content away in a container, outside the reach of hyperlinks, you’re not building any kind of ‘web’ app. You’re doing something else.

I could quote the whole thing, so perfectly does it map to my own feelings and thoughts on the web, but instead I urge you to go to Ben’s site, read what he has written and understand the web.