As before, you can put anything you like between the opening and closing tags – that’s the human-readable bit. The machine-readable bit is contained within a datetime attribute. Dates are expressed YYYY-MM-DD.

Previously, you could only mark up precise dates. So, 13 November 1905 could be expressed in HTML <time datetime="1905-11-13"> but November 1905 couldn’t be. This is a problem for historians where sometimes the precise date isn’t known.

Now, “fuzzy dates” are possible:

• <time datetime="1905"> means the year 1905
• <time datetime="1905-11"> means November 1905
• <time datetime="11-13"> means 13 November (any year)
• <time datetime="1905-W21"> means week 21 of 1905

As before, times are expressed using the 24 hour clock. Now, you can separate the date and time with a space rather than a “T” (but you don’t have to). So both of these are valid:

• <time datetime="1905-11-13T09:00">
• <time datetime="1905-11-13 09:00">

You can localise times, as before. Appending “Z” to the timezone indicates UTC (a way of saying “GMT” without it being comprehensible to normal people). Otherwise, use an offset:

• <datetime="09:00Z"> is 9am, UTC.
• <datetime="09:00-05"> is 9am in the timezone 5 hours behind UTC.
• <datetime="09:00+05:45"> is 9am in Nepal, which is UTC + 5 hours and 45 minutes.

Durations

In New! Improved! HTML5 <time>, you can represent durations, with the prefix “P” for “period”. This uses “W” (or “w”) for weeks, “D” for days, “H” for hours, “M” for minutes and “XQ” for seconds. Just kidding – that’s “S”.

You can separate them with spaces (but you don’t have to). So <time datetime="P4W3D5H"> is a duration of 4 weeks, 3 days and 5 hours, as is <time datetime="P4W 3D 5H">. A duration of 3 hours, 2 minutes and 23.005 seconds is <time datetime="P3H2M23.005S"> or <time datetime="P3H 2M 23.005S">.

This can be boiled down by a machine to a precise number of seconds. Because of this, you can’t specify a duration in terms of months, because a month isn’t a precise number of seconds; a month can last from 28 to 31 days. Similarly, a year isn’t a precise number of seconds; it’s 12 months and February sometimes has an extra day.

You still can’t represent dates before the Christian era, as years can’t be negative.

pubdate

The pubdate attribute (a boolean that indicates that this particular date is the publication date of the parent <article> (or, if there is none, the whole document) is currently missing from the W3C version of the spec, but is still current in the WHATWG version. Its status is unclear to me (but I’m still using it).

Unnamed sources tell me that, as the Mayans nearly predicted, 2012 will be the year when misusing vendor prefixes will no longer be tolerated and manufacturers bastardising CSS Media Queries to do UA-sniffing will not go unnoticed.

Don’t believe me? Here is an artist’s impression of an actual photo of Tim Berners-Lee summoning his standards-avenging attack ninjas.

Tremble, proprietary-lovin’ developers!

Me

• I’m interviewed on the Sitepoint podcast.
• Opera’s TV emulator is released, so you can check your HTML5 and CE-HTML apps

HTML

• App manifests, an anthology – on thge multiple manifest formats that attempt to lock in users. (Similar to my June post Installable web apps and interoperability.)
• Adding Islamic calendar support in HTML5 – a request from IBM to add new types of HTML <input> to cater for the three Islamic calendars. I agree with Lars and Lachlans’ comments that this is a browser enhancement and not an addition to the language.
• Shadow dom spec (very draft)

CSS

• CSS pre-processors and why you need to be careful with them.
• Dispelling the Android CSS animation myths – Feature detection only works if browsers tell the truth.

JavaScript

• EcmaScript 6 versioning. Dutch Specmeister Anne van Kesteren writes “this still strikes me as a slippery slope towards the mess Internet Explorer is dealing with (and Word has in the past). Not very webby, ECMAScript”
• Backbone.js mini-book by Addy Osmani, who says "any contributions welcome. Plan to keep adding more everyday".

Multimedia

• HTML Canvas 2D Context Extensions, draft spec to add accessibility features for caret and selection management, for setting the caret blink rate, for returning the vertical offset of a text anchor point, and for drawing a focus ring around the current path. Also see a change proposal Modify existing Canvas 2D API to expose text baseline and facilitate drawing of focus rings.
• Two competing Audio APIs. (I like the MediaStream Processing API better; Philip Jägenstedt explains why it’s better.
• webcam streaming only using JavaScript
• An all-you-can eat historical and technical look at web video. What’s up with HTML5 and these competing codecs?
• GigaOM reports 80% of video is h.264 and iPad ready without re-encoding. Only 2% is webM. ORLY? The stats don’t seem to match up.

Data

• I will convert your Excel data into one of several web-friendly formats, including HTML, JSON and XML.
• When is my bus due? Geolocation plus real-tme open data for a mobile win
• Anne van Kesteren’s latest spec has the ambitious goal to unify encoding handling across user agents for the web so legacy pages can be interpreted "correctly" (background)

Mobile

• Mobile health apps provide health access to potentially 18million people in Kenya

Kerrrazy Shit!

• <b> is for Block: “B means “block” and I means “inline”.” So I’d better update my presentation Leveraging HTML 5.0: Super-hot HTML 5.0 tag elements to increase your buisness’es social mindshare accordingly.

• Notes on Designing Websites for the Asian Market by Yours Truly.
• MPEG-DASH is the first International Standard for dynamic adaptive streaming of multimedia content over HTTP. It will be interesting to see what the royalty/ licensing situation will be.
• I don’t agree with everything Faruk says in The Threat Against the Web, but wholeheartedly applaud “The web will only thrive as long as the web is not owned by any one entity; not owned, not controlled, and not defined”.
• On the subject of the constantly-embattled Open Web, Google offered patches to allow their super-whizzo! invented-in-secret Dart language to be in WebKit. Oliver Hunt of Apple objected: “As the 90s demonstrated such “features” are bad for developers, and bad for the open web. This may not be apparent to people who have not spent years working in the environment but random additions frequently cause significant pain down the road” and adding adding “it fragments the web” and risks “turn[ing] webkit into the engine that everyone hates because of all its unique “features” that break the open web, a la certain browsers in the late 90s”.
• W3C: Open Web Platform Weekly Summary – 2011-12-05 – 2011-12-11 (worth an RSS subscription)
• Shapecatcher lets you draw a shape and tries to match it to any of 10,877 unicode characters.
• Still life: Bent objects – The secret life of everyday things

Having images scaling down presents a problem though, if you’re a performance-minded sort of chap(ette). Why send a 300K 400 x 800 image that would look lovely on tablet device attached to wifi, but which takes ages to download on a 3G phone, and which gets resized by the browser to fit a 320px wide screen? Not only are you wasting your user’s bandwidth and time, but not every browser is created equal and not every resize algorithm makes pleasing end results. The CSS 4(!) image-rendering property can help with this but it only hints to the browser.

Sending the right-sized image to devices without wasting bandwidth is one of the knottiest problems in cross-device and responsive design at the moment. In the 24ways advent calendar series of articles, the subject has been discussed twice in eight articles (by Matt Wilcox and Jake Archibald). There are numerous other techniques, as well, such as tinySrc and the Filament Group’s Responsive Images.

All these are very clever, different solutions to solve the same problem, and they all rely on scripts, or cookies, or server-side cleverness or (in the case of Jake’s ideas) dirty hacks and spacer GIFs. I’m reminded of Image Replacement techniques from more than 6 years ago, which were over-engineered solutions to the problem better solved by CSS web fonts.

Let’s recap. We have several images, of different sizes, and want to send only the most appropriately-sized image to the browser. The circumstances differ. The canonical use case is to send smaller, lower-resolution images to smaller screen-sizes on the assumption that connection speed is slow and they have low-resolution displays. This isn’t the case, though. Some people are using retina displays on fast wifi networks. SO, while currently CSS Media Queries allow us to detect screen width and pixel density, we need new media features such as network speed/ bandwidth.

The DAP is working on a Network Information API, there’s a Phonegap version for native apps, and a Modernizr detect, but using script for this seems much harder than being able to access it via Media Queries, and if you just want to rearrange CSS layout, CSS is the place to detect it. (Purists may argue that network connection isn’t a characteristic of device, but in your face, purists!)

Once you have a media query, you can swap images in and out using the CSS content property:

<img id=thingy src=picture.png alt="a mankini">
…
@media all and (max-width:600px) {
 #thingy {content: url(medium-res.png);}
 }

@media all and (max-width:320px) {
 #thingy {content: url(low-res.png);}
 }

@media all and (network-speed:3g) {
 #thingy {content: attr(alt);}
 }

A browser that doesn’t support Media Queries, or doesn’t report “true” for any of the Media Queries shows the picture.png, which is the src of the img. A browser that is less than 600px replaces picture.png with medium-res.png. A 320px or narrower browser replaces picture.png with low-res.png. A browser that is only connected via 3g replaces the image with its alt text.

I first researched this technique in 2008 as a way of doing image replacement without extra markup (ironically enough). The first two media queries only works in Opera and Chrome at the moment, as they’re the only browsers that fully support content without :before or :after. (The network-speed media query works nowhere as I just made it up).

Recently, Nicolas Gallagher experimented with generated content for responsive images, and unfortunately discovered that there are no advantages to the technique because browsers always download picture.png, even if they never show it because they immediately replace it. Perhaps this could be optimised away by browsers, but there would still be the double-download problem with current browsers.

My mind turned to HTML5 video. Here we have an element that has the ability to specify multiple sources (because of different codecs) and can also switch sources according to media characteristics. It borrows syntax from Media Queries but puts them in the HTML:

<video>
<source src=high-res.webm media="min-width:800px">
<source src=low-res.webm>
<!-- fallback content -->
</video>

I firmly believe that if something as new-fangled as video can be responsive in a declarative manner (without needing script, APIs, cookies or server magic) then responsive images should be similarly simple.

Previously, on the mailing list, a new <picture> element was proposed. I mashed up that idea with the already-proven video code above and came up with a strawman:

<picture alt="angry pirate">
<source src=hires.png media="min-width:800px">
<source src=midres.png media="network-speed:3g">
<source src=lores.png>
   <!-- fallback for browsers without support -->
   <img src=midres.png alt="angry pirate">
</picture>

This would show a different source image for different situations. Old (=current) browsers get the fallback img element. As I said, this is a strawman; it ain’t pretty. But it would work. (It’s discussed in my recent Smashing Magazine article HTML5 Semantics.)

I prefer the media queries to be in the HTML for two reasons: you don’t need to have ids or complex selectors to target a particular image, and (more importantly) many content authors use a CMS and have no ability to edit the CSS. (Although the nasty <style scoped> could solve this.)

On the other hand, I might be over-engineering the whole problem. I chatted informally with my colleague Anne van Kesteren, glamorous Dutch WHATWG inner circle member. There’s a school of thought that says everything will be 300ppi and networks will be fast enough, so this is really an intermediate problem until everyone starts using highres graphics and all displays go from 150 to 300. Standards are long term, and by the time we have a standardised version, the problem might have gone away.

What do you think?

(Matt Machell pithily pointed out “if only browsers hadn’t forgotten the old school lowsrc attribute for images“.)

Looks like our chums at WHATWG are discussing this too.

HTML5, markup

• Project-based cross-device development tutorial: Love your devices: adaptive web design with media queries, viewport and more
• My colleague Divya wrote a piece on semantics (which I disagree with) called Our Pointless Pursuit Of Semantic Value. Jeremy Keith also disagreed, as did John Foliot in his ironically unsemantically-titled My Thing About the Thing That Thing Wrote About Thing.
• Co-incidentally, I had been asked by Smashing Magazine to write up my Fronteers talk into an article on HTML5 Semantics and why they do matter.
• If you’d rather see me talk about HTML5 with pink hair, here’s an Opera tech break:

• Accessibility: Roger Hudson proposes a scoring system to measure *real* accessibility of a site called Accessibility Barrier Scores.
• The Trials and Tribulations of HTML Video in the Post-Flash Era (with discussion of DRM)
• The DRM graveyard: A brief history of digital rights management in music
• Web pages are getting more bloated, and here’s why. “Over the past year, web pages have on average become 25% bigger.”

Groovy webdev stuff

• Mike Tayor has the low-down on HTML5 Custom Protocol and Content Handlers
• 25 Secrets of the Browser Developer Tools
• ‘The Developer Briefcase’ and other neat Opera extensions for developers

CSS

• Department of Unnecessary bling: Flash-style hover effects replicated in CSS!
• Flexbox will kick your dog and pee on your rug

Vendor prefixes

• Vendor Prefixes Are Hurting the Web says Henri Sivonen
• WTF? zomg! says Daniel Glazman,co-chair of the CSS Working Group in his answer to Henri Sivonen
• Vendor prefixes have failed, what’s next? asks Lea Verou
• Vendor Prefixes Are A Rousing Success declaims Alex Russell. I tend to agree with Alex here, but think that Robert O’Callahan makes an excellent point that Alex’s perspective isn’t neutral; it benefits WebKit (and thus his employer, Google).
• PrefixFree: Break free from CSS prefix hell – Lea’s script parses CSS on the client and adds only the vendor prefixes that the browser requires. A sort of Modernizr for CSS, but note it adds a dependency on JavaScript.
• Prefixr: Cross-Browser CSS in Seconds! -copy your prefixless CSS, hit the button o get prefixes added, paste the result back into your CSS.

Misc

• An 86 year old’s comic about the Web (hopefully genuine!)
• Lesbians who look like Justin Bieber