Paul Irish

Making the www great

The Fundamentals, Primitives and History of HTML5

Just gave this talk at W3Conf about some of the innerworkings of HTML5. Lots of did-you-know and cool insight into how browsers work. 37 minutes long,

The Primitives of the HTML5 Foundation - Slides

I do discuss optional start and end tags as well as not quoting your attributes. I concede that these ideas scare the shit out of people. In fact, when I first heard Jens Meiert propose the idea in 2009 my brain rejected it.

comic by Jens Meiert

Still, I think many of the markup parsing curiosities that can be frightening only need to be understood by HTML minifiers. Always leave it up to tools to make your frontend payload smaller; you just want the most comfortable and maintainable authoring environment possible.

I shared them in this talk because 1) it can lead to writing more beautiful HTML that is easier to maintain. Leaving off </li>’s is a good example. 2) I just want people to consider browsers less of a black box of uncertainty. There are rules and specs that define behavior, so once understood you can feel confident relying on a consistent behavior. We certainly don’t have that consistency across all the web platform, but for these examples you do.

In summary, I’m not advocating you write more spartan markup if you don’t want to. But if it makes you feel good, by all means, go at it; you know now how the browsers work.

ps. the monkey HTML shirt I wore is from a store in tokyo; solo location. but they also sell on this delightfully overwhelming site

Semantics in Practice and Mapping Semantic Value to Its Consumers

Divya Manian kicked off a good bout of discussion of HTML semantics with her post Our pointless pursuit of semantic value. It called into question the amount of time we spend on identifying the Right and Best ways of marking up our content while highlighting details of some of the consumers of semantics like assistive technology (AT). Jeremy Keith responded in Pursing Semantic Value. I wanted to chime in on Jeremy’s post so, I’ve published below my comment from the original post:


Thanks Jeremy for raising a practical example. This discussion is a tough one as much of HTML5 has clear semantics (nav/header/footer), but then parts have underdeveloped semantic meaning or add confusion to authors.

Jeremy’s gist is a great example, in fact, of a poor time investment in semantics. It ascribes value to the new method of document outlining, which recently sees different styling for h1’s depending on section nesting. Recent browsers do indeed style the h1’s different; but if you actually structure your document as such, you do it to the detriment of your screenreader users: they will either get these h1’s all as top level headlines or a mishmash of heading nesting levels that don’t match any expected behavior (As an aside, this is completely unrelated but if anyone’s curious what CSS it takes to make that new h1 styling work across browsers… feast your eyes on this beauty)

Additionally, <hgroup> is on the chopping block and is not supported by JAWS. Suffice it to say, Now is not a smart time to invest your time understanding the unwieldy document outlining algorithm. Luke’s comment digs in deeper to the messy semantic state of the outlining algorithm.

The practicalities of making accessible web content are messy, but important. The fact that we seem to spend more time on div vs article vs. section than on learning ARIA is a crime. (Furthermore, learning ARIA isn’t complete unless you’re listening to the results in a screenreader.)

My recommendation: follow the work of Steve Faulkner and Jason Kiss. These two guys are publishing the only data that illuminates what’s actually happening at the AT level in response to our work. Steve’s comment on this post does a solid job of unraveling this complex topic by showing all the many layers involved: specs, editors, authoring experience, aria, browser impl, screenreader compliance.

Also if you’d like to investigate what’s happening under the covers, I recommend:

In summary, I think it’s best to ground our efforts in pursuing semantic value by identifying precisely what the results will be. A fair rule of thumb: when it comes to semantics, if it’s confusing enough for you to ask a question about it, chances are the answer won’t make a realistic difference. Let’s build incredible stuff on this impressive platform and avoid getting mired in semantic inconsequentialities. There’s also room for more author engagement and screen-reader involvement in the standards process regarding these issues; but that’s a large topic I’ll have to save for another day.

What Feature Would Improve the Web?

Yehuda Katz and I recently asked this question on Twitter.

We’re very interested in seeing web browsers advance and implement the interests of web developers.

We got a great response (230+ responses). After a triage of the responses, we narrowed down things to a hitlist that jumped out as having no immediate solution and would be great for the platform:

  • flash capturing keyboard events, cursor
  • WYSIWYG form element
  • inset text shadow
  • css blend modes
    • usecase: image i want to tint on hover
  • Why CORS requires a preflight with cookies disabled
  • being able to verify the content sent was the content delivered. Probably via headers & apis useful when deploying for mobile/roaming use or in corporate networks when behind proxies.
  • Text Flow or caret(Position/Range)FromPoint
  • A unified and publicized set of selectors for styling the shadow dom of input/select/etc. elements
  • a way to manipulate asset request urls with js on the client before they go out (for serving responsive imgs, etc).
    • or media query attributes on image tags
  • UIKit for Javascript.
    • Native UI bindings to JS that remove overhead and layers of HTML+DOM in the way. Sony’s Trilithium did this by binding HW accelerated scene graph, ala Core Animation. see also playstation webapp
  • render a DOM element to canvas, webgl
  • DirectWrite in all browsers on all platforms.
  • simulate keyboard and CLICK events
  • a base tag for CSS
  • Filesystem API limitation: IDE cant save files back to disk in original location
  • XHR2
  • fragment.innerHTML


There are a lot more where that came from. A few people wanted to see all the responses… So.. here you are. :)