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.

Me:

We’ll build the whole thing with HTML5 if that’s okay with you guys. One question though: do you know what percentage of your visitors use Internet Explorer without JavaScript to view your site?

Client:

Erm, I don’t really know, and I wouldn’t want to lose those visitors. Maybe we’d better not build it in HTML5 after all.

Me:

Whoa there! No need to be so hasty. We don’t have to use HTML5 exclusively, but we can still use it to develop specific parts of the site. How does that sound?

Client:

Great! Let’s do it!

After telling Remy about this conversation, he proposed that we cover this subject in an article, so here we are!

We’re treating this article a bit differently, like a Q & A with the authors, so let us know if you like this new style.

Which bits of HTML5 can I use right now?

Rich: Lots of them! Here’s a short list of cross-browser (including IE) compatible techniques that you can use today:

• Change your doctype
• Simplify your character set
• Simplify your <script> and <style> elements
• Use block level linking
• Get into the habit of using HTML5 class names in your HTML4 markup
• Use the new form input types, as they degrade gracefully
• Use elements such as <time> to add semantics that will be interpreted by leading browsers
• Use the <video> and <audio> elements, and then make them degrade gracefully (see our article on audio or Video for Everybody)

For a clearer idea of what is or isn’t cross-browser compatible, check out these sites from Molly Holzschlag and Alex Deveria.

Remy: Assess the technology and fit it to your project. If I have a lot of IE6 users, I avoid using PNGs. If I have a lot of IE users with JavaScript disabled, I give them reduced markup as Rich pointed out earlier (e.g., simplified doctype, <script>, and <style> elements) but avoid using new block-level elements like <section>. If they have a very interactive product that relies on JavaScript anyway, I don’t have any qualms using JavaScript to help IE style the new elements.

Also, I’m going to detect Web Forms 2.0 and other HTML5-type support using something like Modernizr, and then fall back on “traditional” JavaScript for things like date pickers if they’re not available natively.

What are the benefits of using HTML5 now?

Rich: Here are several, in no particular order:

• Cleaner markup
• Additional semantics of new elements like <header>, <nav>, and <time>
• New form input types and attributes that will (and in Opera’s case, do) take the hassle out of scripting forms
• Staying ahead of the curve before HTML5 becomes the mainstream markup language. Use this as a selling point when talking with your clients

What are the downsides to using HTML5 now?

Rich: Obviously, you make some trade-offs when using HTML5:

• The spec isn’t finished and is likely to change
• Not everything works in every browser (but you could say the same about CSS, right?)

Should I tell my clients I’m using HTML5?

Remy: No. When I go to buy a car, I don’t ask about the parts in the engine. I just want to know what it looks like, how much it costs, its level of quality, features, etc. Sure, some people are mechanics, but most aren’t.

Clients aren’t developers, so they shouldn’t influence your decision on what technology to use. When they ask What technology are you going to use? or Should we be using HTML5?, we, as developers, should tell them:

It depends on your product and your audience. Do you have any usage statistics that I can see?

Rich: Yes, you should. If a client doesn’t want to use HTML5 for a project, simply explain the benefits mentioned above. Point out that their site will be built using an up-to-date markup language, so it’s less likely to need updating in a few years. It’s “future-proofed”, and it will save them money in the long run.

What if my client mentions that “HTML5 won’t be finished until 2022″?

Rich: Politely inform them that it’ll be closer to 2012 (and some might argue even sooner). Tell them you’re building this site with an eye on the future and that it will help them in the long run. In my opinion, it’s only fair to inform your client that you’re using HTML5 (depending on their position and level of understanding), though in some cases it won’t matter because they’re only concerned with how the site looks in the browser they use.

Remy: My opinion is that you shouldn’t be discussing with the client which technology to use — only (perhaps) providing justification as to why you’ve used a particular technology. You can assure them that SEO and compatibility won’t suffer, but just as you don’t offer accessibility as an optional item on the menu (well, I certainly hope you don’t), you shouldn’t offer HTML4, XHTML, or HTML5 as a menu item either.

Will using HTML5 negatively affect my clients’ search engine rankings?

Rich: No. Google is properly indexing sites built with HTML5. Take our site for example — it’s doing just fine. ;)

Have you built any client sites with HTML5?

Rich & Remy: We’ve both started using things like the simplified doctype and reduced markup in our client work. We’ve also used HTML5 on a lot of professional projects where we’re our own clients, such as Speak the Web and the 2009 Full Frontal JavaScript Conference.

We haven’t used it as much for full-fledged HTML5 apps that use all the new markup and new APIs – but rest assured, there is work in the pipeline. :)

Rich: I’ve also recently released an events site for the agency I work for that uses new HTML5 elements.

So should I be using HTML5 in my projects right now?

Well, as with all projects, it depends on the client (are they marketing directors or IT directors? internal or external?), the budget, and the timescale, among many other things.

To wrap up, we’ll leave you with our checklist for building client sites with HTML5:

• Use the HTML5 doctype and character set.
• Use the simplified <script> and <style> elements.
• Use semantic class names that are representative of the new HTML5 elements. See @boblet‘s cheat sheet for more on this.
• Use block level links.
• Use the new form attributes and input types.
• Use the new <audio> and <video> media elements (but make sure they degrade gracefully).
• Plug the gaps with something like Modernizr.

If you think there’s anything more that we could be doing today, please let us know. I’m also keen to find out who is using HTML5 on client sites today. I’ve seen quite a few on the gallery, but it would be great to hear some arguments for and against building clients’ sites with HTML5 now.

How to use HTML5 in your client work right now originally appeared on HTML5 Doctor on March 30, 2010.

However those of us more accustomed to the world of Post-Its, sketches, and .psds – the designers – haven’t been so vocal. Perhaps we’ve been distracted by the bright lights of CSS3 and those surface thrills we’ve longed for. (Rounded corners! Gradients! Transparency!) Or, alternatively, we’ve been in the thrall of @font-face and looking forward to the coming age of passable web typography.

Understandable. But it’s time designers got excited about HTML5 too.

Partly, it’s just good practice. Whatever your flavour of design – visual, web, interaction, user experience – knowing the native technology makes you better at your job. Just as composers should understand the capabilities of the orchestra’s instruments, designers need to understand the language of the web.

But there’s more to HTML5 than simply keeping our skills sharp. It could make a big difference to the way we design for the web.

Semantic elements

Information architects (and, by extension, user experience designers) should be excited by the new HTML5 elements – <nav>, <header>, <aside> and so on. While they won’t immediately revolutionise today’s web, they’re an investment for the future. Doing useful stuff with information is the central theme of IA, and therefore its practitioners should be at the forefront of the new experiences that machine-readable semantics will offer. HTML5 allows us to mark text up in a more meaningful way than a sea of <div>s, meaning we’ll soon see applications appearing at a sub-page level. We’ve started to scratch the surface – think about the Operator toolbar or customisable UIs à la iGoogle – but we’ll need detailed design thinking to work out how to bring the benefits of semantic richness to the end user.

APIs and other extensions

While it’s clear that some of the HTML5 APIs are far from perfect right now, when they’re refined they will offer us intriguing new opportunities and challenges.

Designers of location-based services should of course find the geolocation API invaluable. The contentEditable attribute gives us further power to make the web truly read/write without resorting to JavaScript and custom interfaces. New input types (eg type="search") can provide extra visual cues about input function, although of course this depends on the solutions chosen by the browser manufacturers.

Until now, it’s been easy to consider our domain as bounded by the viewport and the web server. But HTML5 is another step toward seamlessness: the merging of desktop, offline and online. For instance, the drag and drop API could see the line between online and desktop experience blur further. Local storage could allow for a web-like experience in areas of poor connectivity. This convergence is clearly a good thing, but we must also design how to expose those hidden seams at the user’s request. Users should stay in control of how their locations are published and what data is synchronised to their machine.

<video>, <audio>, <canvas>

There is of course something of a reported schism between the standards world and the Flash world. Some see the advent of these new media elements (particularly <canvas>) as heralding the death of Adobe’s poster child.

I don’t think this is either likely or desirable. Neither technology is perfect. Flash is, of course, proprietary and thus subject to the whims of a third party that stands between browser and user. <canvas> has known accessibility problems. But the two can live in harmony, if we play to their respective strengths. Some current Flash applications might be better suited to <canvas>, particularly those based around dynamic visualisation: graphs, animations, infographics. Some applications will benefit from the powerful capabilities of Flash: games, heavily interactive widgets.

This aside, there’s clearly a user experience benefit in not having to rely on an external plugin to play rich media elements, and it will be interesting to see the uptake of the <video> and <audio> elements. Although it will initially be down to browser makers to define the interface elements involved, we will need to figure out how to integrate them into everyday web experiences. The good news is that they can be styled in the same way as any other HTML element. If your visual aesthetic relies on slanted images with box shadows, it’s trivial to apply this to video too.

That said, we can’t ignore the elephant in the room: the thorny codec issue. I’m sure we’d all agree that the sooner it’s resolved, the better.

What can designers do?

Only the most patient and detail-oriented designer will relish the idea of reading the spec in full and arguing the finer points on the WHATWG list. That’s just not the way designers roll.

But as a community it’s important that we start talking about HTML5. If you’re new to HTML, now’s a great time to learn. The articles on this site and A preview of HTML5 give useful guidance on the differences between HTML5 and its predecessors. Above all, designers should get chatting with their developer friends: there can’t be many left who no longer have an opinion on this technology. How do they see their practices changing? What can we do today to prepare our sites for the advent of HTML5? How can we build on its strong points to make the web a better place?

We don’t yet know what we’ll accomplish with HTML5, but then it’s not often that the vocabulary of the web changes this deeply. However, one thing is clear: if we prepare now, we have a great chance to bring innovation to our users’ online lives.

This article was jointly published on Ineffable, Cennydd’s personal website.

Why designers should care about HTML5 originally appeared on HTML5 Doctor on October 14, 2009.