Archive for September, 2012

Reading List




I had a lovely week in Norway, where my Opera devrel colleagues and I illustrate how we open the Web.

members of Opera's devrel team pull open a large red letter 'O' Opera logo

Reading List

HTML5: Facebook’s “biggest mistake”

Facebook’s Mark Zuckerberg said “the biggest mistake that we made as a company is betting too much on HTML5 as opposed to native.” and much “HTML5 is rubbish” frenzy ensused, so few people notived that he continued

I’m actually, on long-term, really excited about [html5]. One of the things that’s interesting is we actually have more people on a daily basis using mobile Web Facebook than we have using our iOS or Android apps combined. So mobile Web is a big thing for us.

Dion Almaer pondered Was the strategy wrong, or the execution?, while Brian Leroux pithily noted

zuck should’ve built his mobile app in html rendered from php, with 40+ blocking script tags. oh wait, they did.

The Register has more analysis.



Development utilities



A cautionary song about social networking by @ourmaninjapan (lyrics):

What good is the web? Some numbers

The World Wide Web Foundation published its first Web Index last week, which it describes as “the world’s first multi-dimensional measure of the Web’s growth, utility and impact on people and nations.”

In its full report (PDF, oh! the irony), it writes

We believe that if access to the Web increases dramatically, there will be significant social development and greater political representation among the billions of people who currently have no voice.

I believe that too. But does the web actually bring about any tangible, measurable economic benefits?

While I was writing an article called Educating Bangladeshi schoolkids about the Web, I discovered some research called Internet matters: The Net’s sweeping impact on growth, jobs, and prosperity (PDF). It’s by the McKinsey Global Institute, about which I know nothing, but it descibes itself as “a global management consulting firm… the trusted advisor to the world’s leading businesses, governments” so I’d hazard a guess they’re not dreamy-eyed idealists given to singing “Imagine” on acoustic guitar at Burning Man festival.

The report (which is well worth reading) suggests:

  • The Internet contributes 3.4 percent to Gross Domestic Product (GDP) averaged over the 13 countries covered by the report (21% of GDP growth for the most developed countries)
  • Most of the economic value created by the Internet falls outside of the technology sector, with 75 percent of the benefits captured by companies in more traditional industries
  • The Internet creates 2.6 jobs for each lost to technology-related efficiencies
  • There’s a 10% increase in productivity for Small and medium enterprises (SMEs) from Internet use
  • SMEs heavily using Web technology grow and export twice as much as others

It notes

an increase in Internet maturity similar to the one experienced in mature countries over the past 5 years creates an increase in real GDP per capita of $500 on average during this period. It took the Industrial Revolution of the 19th century 50 years to produce the same result.

Nice to have some numbers to remind us why we need a world-wide web, based on open standards rather than device-specific walled gardens of content. Imagine all the people, living life in peace.

Scooby Doo and the proposed HTML5 <content> element

Note: Since writing this, I’ve continued vacillating and now support a <main> element. Why I changed my mind about the <main> element.

Trigger warning: contains disagreement about accessibility.

I’ve been vacillating (ooh err, missus) for two weeks from one opinion to the other regarding a proposed (and rejected) <content> element. This weekend, The Mighty Steve Faulkner wrote an unofficial draft of a <maincontent> element.

Dude, where’s my content?

For a while, people have suggested that HTML add a <content> element that wraps main content, because many websites have something like <div id="content"> surrounding the area that authors identify as their main content, which they then use to position and style that central content area.

Fans of WAI-ARIA also like to hang role="main" on that area, to tell assistive technology where the main content of the page starts. I do this too.

The editor of, Ian Hickson, rejected a new <content> element:

What would the element _mean_? If it’s just “the main content”, then that is what the element’s contents would mean even without the element, so really it means the element is meaningless. And in that case, <div> is perfect, since that’s what it is: a grouping element with no meaning.

The primary argument against a special element is that it isn’t necessary, because the beginning of “main content” can be identified by a process of elimination that I call the “Scooby Doo algorithm”: you always know that the person behind the ghost mask will be the sinister janitor of the disused theme park, simply because he’s the only person in the episode who isn’t Fred, Daphne, Velma, Shaggy, or Scooby. (Like most Scooby fans, I’m pretending Scrappy never existed.)

Similarly,the first piece of content that’s not in a <header>, <nav>, <aside>, or <footer> is the beginning of the main content, regardless of whether it’s contained in an <article>, or <div>, or whether it is a direct child of the <body> element.

Authors do need to be able to identify their main content, both for styling (in which case <div> seems to be the most appropriate element) and as a target for “skip links”, in which case, the current <a href=”#main”>Skip nav<a> … <div id=”main”> pattern still does the trick.

It’s worth noting that people often code “skip links” believing it’s required by WCAG 2, but if browsers implemented the Scooby Doo algorithm that is explicitly not the case: “It is not the intent of this Success Criterion to require authors to provide methods that are redundant to functionality provided by the user agent.”

Many assistive technology useragents understand the ARIA role=”main”, so skip links should be unnecessary; ATs can hone in on <div id=”main” role=main> by themselves, even without supporting the Scooby Doo algorithm.

This suggests to me that a new element isn’t required. But…

Paving cowpaths, ease for authors

Chaals (ex-Opera, now Yandex) wrote

To turn the question around, if it is more convenient for authors to identify the main content, and not think about the classification of other parts, should we offer that facility as part of the platform? Or does it make sense to say that only the exhaustive identification of all supplementary content is an appropriate way to mark up a page anyway?

Chaals argues that it makes authoring easier – suddenly you get extra accessibility by just adding one <content> element, rather than adding the other elements that the Scooby Doo algorithm can then exclude. People using CMSs, who only control the textarea that gets lumped in as “main content” and can’t touch the surrounding areas can now add an element, without having to ask others to tweak templates.

But then, they can do this already, by surrounding their content with <div role=”main”> and this already works in assistive technologies.

A flawed argument for a new element is that it paves a cowpath, so should be added to the language. It’s certainly the case that <div id=”main”> and <div id=”content”> are very frequently found in pages – they were #2 and #6 in the most-frequently used ID attributes in the 2008 MAMA: What is the Web made of? report.

But not every cowpath needs paving. If it did, we’d also have a <logo> and a <container> element (#4 and #5 respectively), and we’d be recommending tables for layout. If something can be done automatically, without requiring extra authorial work, shouldn’t that be favoured? In the same way that we like HTML5 form types as they’re baked into the browser, shouldn’t the Scooby Doo algorithm be preferable?

Of course, the Scooby Doo algorithm requires the author to use <header>, <footer> <nav> and <aside> — but if (s)he doesn’t want/ isn’t able to author HTML5, ARIA’s role="main" is there precisely as bridging technology.

There’s also the argument that authors expect there to be a <content> element, so its absence violates the Principle of Least Surprise. But I’m not sure that’s a valid argument. Implementing the Scooby Doo algorithm would mean that pages whose author does nothing for accessibility can be made so that their main content area may be programmatically determined. ARIA exists for pages that aren’t in HTML5, or until the Scooby Doo algorithm is widely supported, and analysis shows that most ARIA is correctly used by authors.

Why add an extra complexity, which is more to go wrong and thus potentially harms accessibility?

Also available:

(Last Updated on 18 December 2012)

Reading List

Sublime Text

  • WebGLTools / GL-Shader-Validator – ” a Sublime Text 2 plugin that passes GLSL / ESSL to ANGLE’s preprocessor / compiler for validation. Any errors that ANGLE finds are routed back to Sublime and the tokens in the shader are highlighted for your convenience and debugging joy.”
  • Element Finder for Sublime Text 2 – “Just copy a CSS selector into Element Finder and you will quickly see all of the HTML elements in your project which match that selector.”


Ling’s cars


Shit Apple fans say

New Spam Call: Charlotte

I got a call last night over dinner from “Charlotte” at “PC support”. As usual, I like to record them keep them talking for as long as possible, to waste their time and in the hope that they’ll blacklist me. I got Charlotte so grumpy that she hung up on me after 5 minutes.

Listen to Spam Call: Charlotte gets grumpy

There are more spam calls, and Reverend Bruce’s replies to spam emails, over at my Spam Letters.