The schism is the same as we’ve long had on desktop. It’s simply: do you make your target audience as wide as possible, or do you only design for people who use the same technology as you do?

The nations’s favourite social-media based conference organiser thingy, Lanyrd, launched its mobile version two days ago. I don’t own an iThing, but I assume it’s great there, and it looks and works excellently on Opera Mini and Opera Mobile on Android.

Jake Archibald, JavaScript developer at Lanyrd, said

“Although we’re employing some ‘new and shiny’ browser features, we’ve taken the righteous path of progressive enhancement and been liberal with our testing and support. While most mobile offerings are targeted at particular devices or WebKit, our support includes quirky devices like the old Blackberry 9000 (yes, it still haunts people’s pockets), the Kindle, and even basic feature-phones if they can run Opera Mini. The site works as expected without JavaScript.

Compare this with the 37Signals’ blogpost yesterday, provocatively entitled Developing for old browsers is (almost) a thing of the past:

It used to be one of the biggest pains of web development. Juggling different browser versions and wasting endless hours coming up with workarounds and hacks. Thankfully, those troubles are now largely optional for many developers of the web.

What is this fabulous remedy that 37signals have found? Simply, ignoring users of browsers that you don’t want to support. “Supporting your browser is hard – let’s go shopping”, as Barbie says, or Regressive Ken-hancement in strict Computer Science terminology.

Compare this with Jake Archibald’s comment:

All it took was *not* doing everything wildly different to how you should develop a standard website.

Summarising this dichotomy is an excellent article Did we lose track of the big picture?:

It seems to me that we are slowly switching from publishing content for the Web, to making content accessible to Screen-Readers (SR) – from targeting users, to focusing on devices and modern browsers.

We write about new techniques without considering fall back mechanisms, we use ARIA “hacks” that look like anti-patterns and we use frameworks that have chosen to ignore oldIE.

If you read no other high-level articles this month, read that one.

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

Not all of them, of course. Think of HTML elements; you can nest <div>s inside <nav>s and <nav>s within <header>s, but you can’t put an <a> inside an <input> or put an <input> inside another <input> – they just wouldn’t make sense.

In ARIA, it’s perfectly fine to have role=article inside role=main (which is completely analogous to an HTML5 <article> inside a <div id=”main”>.

It’s also fine (as far as I know) to have roles like main inside a <table role=”presentation”>. Although the table is presentational only (it’s an old-fashioned layout table), it doesn’t mean that all the contents are presentational – one cell could contain the entire main content of a site and therefore quite legitimately have a role="main".

The rule of thumb I use is: if your nesting feels right, it probably is right.

Note also that the HTML5 validator also validates ARIA. Even if your content isn’t HTML5, it’s still worth running it through the validator.

Note, I’m not an ARIA expert. Please, if I’ve made a mistake, let me know!

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!

I’ve nailed my colours to the mast – most lately in The Pastry Box:

The Web is about communication. It connects many people who previously were isolated such as those with disabilities or those in oppressive regimes. It’s a World-Wide Web, not a Wealthy Western Web. If your super-clever site only works with a mouse and monitor, on the latest $2000 super-spec laptop, with a fat broadband connection, you’re missing the point.

The ideal of universality is fundamental to the Web. Some bloke called Tim said

The principles of universality of access irrespective of hardware or software platform, network infrastructure, language, culture, geographical location, or physical or mental impairment are core values in Web design.

One of the most worrying trends we see at the moment is the erosion of this idea. In a survey, Peter-Paul Koch asked "Do you hope that WebKit will become the only rendering engine, and that the others will gradually disappear?". Shockingly, 32% have replied “yes” (at time of writing). You read that correctly! 32% actively wish for a monoculture. Because, y’know, cross-browser development is hard – so let’s go shopping! Who cares about the users? Who cares about the future? We’ve been here before with IE6- the darling of developers at the time – and look how well that went.

It’s pretty obvious that this is a case of a group of developers that believes that everyone should be just like them and should use the same devices and browsers. After all, despite all their genuflecting to Safari on their iPhones, it appears from December’s mobile statisitics (as written up by PPK) that

Opera once more overtakes Safari. It’s clear now that Android’s untrammeled growth has ended, and that the race for first position will continue to be between Opera and Safari.

(If you’d like to start testing your sites in the number one mobile browser, there are plenty of Opera testing tools available. Note: Opera is my employer, but this is my personal opinion.)

Stephanie Rieger writes in A plea for progressive enhancement

we have to start building sites using solid, future friendly principles such as progressive enhancement…not just when it’s handy or simple, but all the time.

and goes on to show a Barack Obama re-election site in which it was impossible to navigate in many devices, even some new high-spec devices. In a news report about this, the journalist quotes my three incredibly ground-breaking, never-before-heard rules:

• Code to standards, not to browsers
• use progressive enhancement
• remember that you are not your user.

Yes, I know! Utterly new concepts.

However, we’re approaching a monoculture on mobile. This is not the work of an evil organisation, but it’s developer-constructed. Few people are stupid enough to use Olde-Skool browser sniffing and blocking, but we’re seeing lots of people breaking cross-browser compatibility by neglect rather than design.

One way this happens is developers using only one vendor’s CSS vendor prefix even when other vendors support the same properties. Of course, for experimental things only implemented by one rendering engine, that’s fine. That’s what vendor prefixes are for.

The trouble comes about when people do something like -webkit-transition for widely-supported properties, without the corresponding -o- for Opera, -ms- for Microsoft and -moz- for Mozilla.

Last week, Mozilla developer Boris Zbarsky wrote

People never aim to create content that’s cross-browser compatible per se, with a tiny minority of exceptions. People aim to create content that reaches users. What that means is that right now people are busy authoring webkit-only websites on the open web because they think that webkit is the only UA that will ever matter on mobile. And if you point out this assumption to these people, they will tell you right to your face that it’s a perfectly justified assumption. The problem is bad enough that both Trident and Gecko have seriously considered implementing support for some subset of -webkit CSS properties.[my emphasis]

Three years ago, David Baron (also of Mozilla) wrote Should implementors copy vendor prefixes from each other?, and in 2010 Microsoft announced that it would support -webkit- prefixes, but eventually decided against it.

Since then, we’ve had many more debates about the merits of vendor prefixes (see previous reading list), and even the co-chair of the CSS Working Group, Daniel Glazman, wrote

The rule should be this one: if the CSS parser encounters a prefixed property for another browser, honour that property as if it were prefixed for us UNLESS an unprefixed or prefixed for us valid declaration for that property was already set. That would drastically reduce the problems on the Web.

I believe vendor prefixes were a good idea, and remain so if used in a cross-browser, future-proof way. But because so many people only use the -webkit- one, I’m starting to wonder too if vendor prefixes should be considered harmful…

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.