A great post by Stuart on the prospect of DRM-by-any-other-name in HTML.
The argument has been made that if the web doesn’t embrace this stuff, people won’t stop watching videos: they’ll just go somewhere other than the web to get them, and that is a correct argument. But what is the point in bringing people to the web to watch their videos, if in order to do so the web becomes platform-specific and unopen and balkanised?
A really nice explanation by Todd Kloots of Twitter’s use of progressive enhancement with Ajax and the HTML5 History API. There’s even a shout for Hijax in there.
Bruce’s thoughts on the proposed inclusion of a “content” or “maincontent” element in HTML5.
Personally, I don’t think there’s much point in adding a new element when there’s an existing attribute (role=”main”) that does exactly the same thing.
Also, I don’t see much point in adding an element that can only be used once and only once in a document. However, if a “content” or “maincontent” element could be used inside any sectioning content (section, article, nav, aside), then I could see it being far more useful.
Bruce writes about a worrying trend in standards work:
Tossing a specification that you’ve written in-house, in secret and already implemented onto a table at W3C, saying “here, standardise this” as you saunter past isn’t a Get Out of Jail Free card for proprietary misdemeanours. And it isn’t standardisation.
This looks like a handy resource with a shitty, shitty name. Count the number of items that are in HTML (or JavaScript or APIs). Now count the number of items that are in CSS.
This is a great response to my recent post about semantics in HTML. Steve explores the accessibility implications. I heartily concur with his rallying cry at the end:
I never expected to see a cross between responsive design and AR, but here ya go:
A silly mashup of HTML5 technologies: We use the canvas to capture the contents of a video element. The canvas then identifies the blue markers and overlays an iframe on top of it. The iframe contains our website (upperdog.se) which has a responsive design.
A real-world anecdote from Jonathan illustrates some of the misconceptions around using HTML instead of going native. A lot of people don’t realise that web apps can store data offline.
This just launched at the Breaking Development conference: another site that uses the term HTML5 to include CSS and Ajax. Still, despite its inaccurate nomenclature, it’s a useful compatibility table of device support in mobile browsers.
Nicole provides a step-by-step explanation of why it will probably benefit you to add classes to your headings to ensure consistent styling without writing overly-verbose CSS.
A brave attempt to explain the new outline algorithm in HTML (although it inaccurately states that no browsers have support for it—Firefox shipped with it a while back).
You can safely skip the comments: most of them are discouraging, ignorant, and frankly, just plain stupid.
A fascinating examination by Hixie of web technologies that may have technically been “better” than HTML, but still found themselves subsumed into the simpler, more straightforward, good ol’ hypertext markup language.
The follow-on comments are definitely worth a read too.
I really like the thinking that’s gone into the design of Github, as shown in this presentation. It’s not really about responsive design as we commonly know it, but boy, is it a great deep dive into the importance of URLs and performance.
An excellent explanation from Richard of the bdi element (bi-directional isolate) for handling a mixture of left to right and right to left languages in HTML5.
I’m getting behind Oli’s proposal to allow non-quoted footers within blockquotes in HTML. Here’s where I quote the design principles to support his case.
A handy mobile-friendly list from Mike Stenhouse of which fish are currently having their stocks depleted. It uses offline storage so once you’ve visited once, you’ll be able to pull it up anywhere.
This dovetails nicely with my recent post about the spirit of distributed collaboration. Here’s a great little bit of near-history spelunking from Paul, all about styling new HTML5 elements in pesky older versions of Internet Explorer.
A rather vicious evaluation of browser support for the audio element and the audio API. It is divided up into:
Browsers From Companies That Actually Care About HTML5 Audio
Browsers From Companies That Hate the Web Enough to Not Support Ogg/Vorbis, but do Have an Audio Tag So They Can Say They Have an Audio Tag (Seriously, Fuck You)
Browsers That Say They Support HTML5 Audio But Actually Don’t Support HTML5 Audio
A beautifully readable subset of the HTML spec, with an emphasis on writing web apps (and with information intended for browser makers has been removed). Very handy indeed!
Tantek is as disappointed as I am with the buzzword-compliant definition of HTML5 being pushed by the W3C.
Instead of providing precision and clarity, they’ve muddied the definition of HTML5 further with yet another “here’s our bucket of things we like which we’re going to call ‘HTML5’” message.
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.
A nifty interactive video for Arcade Fire's "We Used To Wait." It claims to be built in HTML5 but actually uses XHTML 1.0 and HTML 4.01 doctypes throughout. *sigh*
Well, well, well. It looks like h264 is not going to be torpedoing us with any submarine patents anytime soon ...but this only applies to end users, not browser makers. Sigh.
Cute illustration of different content types in HTML (though, personally, I would put sectioning content — section, article, nav, aside — into their own group).