Paul Irish

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.

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

Paul Irish front-end development

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:

• HTML to Platform Accessibility APIs Implementation Guide – Understand how HTML elements and attributes map to accessibility APIs
• HTML5, ARIA Roles, and Screen Readers in March 2011 – Implementation of HTML5 elements in screenreaders isn’t perfect yet.
• HTML5 and the myth of WAI-ARIA redundance – Will HTML5 make the use of WAI-ARIA in HTML redundant? Definitely not.
• JAWS Support for ARIA – Originally published by Freedom Scientific as a MS Word document. *facepalm*
• html5accessibility.com – Also from Steve Faulkner; this research is hugely comprehensive and backs up the examples Divya provided
• delicious.com/paul.irish/aria – My own bookmarks on semantics, aria and accessibility.

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.

Paul Irish front-end development

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. :)

Read more…

Paul Irish front-end development

You may soon be developing for 76 browsers.

(╯°□°）╯︵ ┻━┻

Lemme take a step back… So it's fair to say that for most of us, IE6 has gone the way of the dodo. Good! Now in IE7, we have less CSS issues, working PNGs, but pretty much the exact same JavaScript engine (though faster). IE8 gives a few more goodies (localStorage, postMessage, hashchange event) that'll be nice to use when we retire IE7, but IE8 will be with us for a while.

Since Windows XP still accounts for 46.6% of Windows users, IE9+ adoption has a significant upper bound. More: How Microsoft is handicapping its own web browser and IE9 adoption is painfully slow. Google to the rescue?

IE6 has been a source of pain for… I'd say four years. IE8 will be a source of pain for the next 9, it appears. You're clearly aware that IE9 (and IE10…) are not available on Windows XP, even though Firefox and Chrome continue to ship versions for that operating system (still 40% of the Windows market), so unless the whole world shells out $79 for an upgraded OS, they won't get an upgraded browser, without switching. That's terrible, clearly. But this isn't the worst part. No, no…

How many browsers would you like to support?

Personally, I'm totally happy supporting the latest version of each of the five browsers. IE10 will be a very impressive browser, and the latest releases of Chrome, Firefox, Safari, and Opera are all incredible as well. Supporting the legacy versions is not exactly my idea of a good time, but ya know.. With IE6,7,8,9.. I'm used to it.

It's about to get worse

IE looks to be on a yearly release cycle. Great! IE10 out in March-ish.. IE11 a mere 52 weeks after that. (Mind you, Firefox and Chrome are shipping every 6 weeks these days). But what's far more important than shipping frequency, is the browser half-life.

Products like Windows and Office have a lifecycle policy that typically runs 10+ years because that’s what these organizations need. As part of Windows, IE honors that 10+ year commitment.

~Dean Hachamovitch, IE Corporate VP

IE9 and IE10 are both scheduled to be sunset (as far as official Microsoft support) in 2020. Since IE8 shipped with Windows 7, we can expect the same death date for it. Yes, IE8's death date is 9 years from now. Meanwhile, you won't have to worry about supporting Firefox 6 or Chrome 13 in November.

Extrapolating this, if they maintain the same policy, IE17 be released in 2019, before IE8, 9 and 10 finally die. So in a few years from now, you'll be supporting one version of Chrome, one version of Firefox, one of Opera, (probably) one of Safari, and ten versions of IE.

Did I say 10 versions of IE? I meant to say 72.

72 versions of IE on the wall, 72 versions of IE… Maybe drinking beer at this point in the post would be a smart move.

So you're aware that IE ships with multiple document modes. IE essentially ships with legacy versions of the renderer so that you can upgrade your browser but still see content that was terribly coded and cannot withstand the reality of web development, therefore it needs to be locked into a single version. I worded this differently a bit ago.

We seem to be using this term of “intranet apps” or “internal corporate apps” just as a euphemism for poorly written code.
Consumer facing apps have been handling new and unknown browser versions day in and day out for years. Like Kroc said, “Corporate users should be testing their applications against standards, not browser version numbers.”

So IE9 contains IE8, IE7, and IE5 modes. IE10 contains modes for IE9 and on down the line.

The problem percolates when you come to terms with the fact that many of these modes are not the same as the original browser. For example:

• IE8's IE7 mode: adds sessionStorage & localStorage, false positives on a feature test for the hashchange event, mishandles rowspan, and some other event and attribute differences.
• IE9's IE8 mode: intermittently false positives on a feature test for inline SVG. Renders CSS differently than true IE8, and is crashier than the real one.

These are not browsers with reliable replicated browser versions embedded, these are frankenstein versions that behave unpredictably. (To better understand the internals, the new JScript engine (these days it's called Chakra) is used in the compatibility modes, but IE engineers remove features and add bugs to make them "match" earlier behavior. Luckily they run at their modern speed, but run with a whitelist of bugs being put in place. MSFT has all reason to keep these compat modes as identical as possible, so we should expect fewer issues in IE10+'s compat modes.)

Of course, there is the matter of what % of market share it takes for you to "support" a browser (test against during dev / QA against / customize your experience for).. It's possible some of these IE versions won't have enough numbers for us to care. Kind of like how we support Firefox 3.6 and 6, but not 4 or 5. (btw, Mozilla will soon pull the lever to prompt 3.6 users to upgrade).

Where, from here? Do we have solutions?

All this news isn't the best, certainly. What are our options?

Asking your users to upgrade their IE version to the latest? We've been naively doing this for a while now, but we've only been shooting ourselves in the foot. Without an upgrade policy for IE that takes the web seriously, you can't responsibly ask your users to upgrade to the latest IE (the future's boat-anchor browser.)

boat-anchor browser (noun): the browser with enough users and not enough capability, holding back the potential of the web. ^[via]

IE version pigpile. Chrome's silent auto-updates (charts via arstechnica)

Microsoft's move. Maybe the IE team will introduce a way to upgrade their users well and also serve their business audience that are interested in a snapsnot of the web that doesn't change. Maybe they'll also introduce a better solution for testing in their browsers than running four (soon five) unique Windows OS images.

Chrome Frame gives us a solid option for handling this situation. (Also, if you haven't read these three posts by Alex Russell… do so.)
At the very least, Chrome Frame will automatically update and has the user-perceived benefit of being "just a plugin" (that all users can install) instead of switching to a whole new browser.

I'm almost done, I swear

Clearly, having your users on a browser that not only iterates quickly but appreciates developers by guaranteeing a short browser half-life is a boon to you and the success of the experiences you can deliver. All the browsers are racing to deliver features and speed to you and your users (including IE).

Seriously, all browser engineers are doing incredible, fantastic work. But without a strategy for how this turns out in the long term, this IE situation will become a complete mess—costing you enormous time in designing how scale your design to 76+ browsers, testing it, QA'ing it, and maintaining it.

The IE team is incredibly talented and wise; I think they have a great opportunity here to make the right move (like when they reversed policy on X-UA-Compatible). Perhaps with Win8 and Metro we'll see a more aggressive approach towards bringing the full potential to the web to all its users.

Paul Irish chrome, front-end development

… or … On "the site must look the same across all browsers"

I think we're all pretty well convinced that our sites can look different across browsers. Sometimes, though, our team or our clients don't totally understand that.

Lemme take a stab at convincing them that each browser gets an experience that is customized to that browsers's capabilities.

Paul Boag actually created a small booklet for your clients on why this is good. Take a look below and download the PDF to share.

Paul lays out these arguments for things looking and acting differently:

• More time for what matters
• Develop for your growth audience
• Improve site performance by letting the experience scale
• Better search engine rankings through faster sites
• Your work will be more future proof
• … and more maintainable
• Wider and more impressive design possibilities
• Users don't open your site in two browsers

(Andy Clarke's book Hardboiled Web Design also covers this ground well)

The TAFEE approach

Taking a TAFEE approach is critical if you expect to deliver worthwhile experiences to your clients while continuing to support the legacy browsers that tend to linger around. Lemme give this guy a definition:

TAFEE (pronounced: taffy): tiered, adaptive front-end experiences. Customizing the experience to the unique capabilities of each browser, prioritizing a fast and good UX over consistency.

It's also worth bringing up a term I mentioned a bit ago:

oldIE (pronounced: oldie): Internet Explorer 6, 7 & 8. aka, the three browsers often getting the low-res experience.

Your alternative to a TAFEE approach, of course, is taking a 'same' approach, wherein things are visually and functionally consistent across all your target browsers. In my experience, this takes much more time to develop and QA—not to mention you've set the baseline experience very low.

One of the best metaphors for scaling the frontend experience comes from Nicholas Zakas I'll let his slides do the talking:

Zakas's TAFEE vs 'same' TV analogy

speedy site > consistent site

Now, it's worth pointing out that javascript runs at incredibly different speeds in the various iterations of Internet Explorer…

Given that, it's up to you to guarantee a performant and responsive experience for ALL your users. That means making it easier for oldIE to chug on your pages, serving them a lighter weight experience, in order to keep it quick.

Why should you keep your site as fast as it can be? Read up on The Performance Business Pitch by Stoyan Stefanov who lays it out best. Suffice it to say that highly performant experiences are KEY to your site

None of your users open your site in multiple browsers, so if you're actively trying to make things look the same for that false goal, then you're slowing down the page for your users on older browsers. You're loading them up with images that mimic border-radius and box-shadow, piling on scripts to maintain visual consistency when you should be focusing on making something that looks good enough and is fast. Louis Lazaris touched in this in The browser performance pickle where he identified that our goal of speed conflicts with our ability to polyfill nearly all features. (There are best practices for this, specifically… stay tuned as Divya Manian and I have something coming for this… ;)

delivering multiple versions

Consider what Google has done with the Google doodles: show off cool <canvas> or bouncing balls with just HTML+JS in "good" browsers and just keeping it the same old Google logo for slow browsers. You heard anybody complaining that they don't get the bouncy balls in IE6?

Facebook, Google, Yahoo all embrace a TAFEE approach to show different browsers different things. It'd likely be wise for you to, as well.

It might make sense for you to segment your experiences into HD (high-def), SD (standard-def) and LR (low-res) tiers. Then you might move to clarify exactly which features are required for each to identify which features are required for your HD tier and so on. IE7 and IE8 may get the LR tier, and if you've punted supporting IE6 completely, I'd recommend prompting to install Chrome Frame. It's what we're now doing in HTML5 Boilerplate 2.0, in fact.

You have some choices to make in how you scale the front-end experience, and I hope you'll have a better idea of how you'll do it and how to communicate this plan to your team and client.

Thank you to Divya Manian, who helped me tremendously with crafting this. Also she just got a sweet interview on Mozilla Hacks.

Paul Irish front-end development