Archive for the 'Opera' Category

On the styling of forms

The earliest incarnation of the specification that we now call “HTML5” was an extension of HTML forms, called Web Forms 2.0 (Working Draft 5 February 2004 – almost nine years ago!). It contained lots of cool stuff that’s in the spec today, like <input type=”date”>, <input type=”email”>, the required attribute, and cool stuff that never made it to the final spec like <input type=”location”> and repeating templates (the latter was implemented in Opera, and subsequently removed in 2010).

When I first started talking about HTML5, I’d show these new forms controls to developers, who were all initially very excited. After all, who wants to code JavaScript date-pickers, or email validation routines? But the excitement dissipated after the inevitable question about how you can style the forms and their error messages.

The answer is that unfortunately you can’t very well. You can apply some styling – for example, making invalid or out-of-range inputs have a different border colour with CSS pseudoclasses, as defined in the CSS Basic UI module input:invalid {border:2px solid red;}, but this was badly thought out because, for example, fields with a required attribute are “invalid” at page load and therefore take the ugly styles before the user has even begun to interact with the form. Mozilla implemented their own -moz-ui-invalid mechanism that solves the problem:

If the element is required, the preceding rules apply only if the user has changed the value or attempted to submit the form.

It’s only implemented in Firefox, as it’s proprietary, but it’s a really good idea and informed a W3C proposed :user-error pseudoclass:

The :user-error pseudo-class represents an input element with incorrect input, but only after the user has significantly interacted with it.

This is good, but only deals with styling erroneous input fields. Error messages can be styled in WebKit using proprietary pseudoelements ::-webkit-validation-bubble, ::-webkit-validation-bubble-arrow-clipper, ::-webkit-validation-bubble-arrow, ::-webkit-validation-bubble-message. There’s no cross-browser proposal at W3C, but Peter Gasston has interesting ideas. The only reliable way at the moment to control the appearance of validation is turn it off with <form novalidate …> and script your own, which rather defeats the purpose.

There are no real ways of styling the controls themselves. The HTML5 spec is mostly silent on styling matters (and rightly so); the CSS Basic UI module would be a natural place for it, but that hasn’t been touched for a year, and before that update had languished for half a decade. Of course, this isn’t a trivial problem. <input type=”date”> might be rendered as a pop-up calendar widget on a desktop browser, and you may wish to “grey out” weekends – but are weekends Saturday and Sunday? or Friday and Saturday? How would you achieve that in CSS? input[type=date]::friday {color:gray;}? And the same browser’s mobile version might use the operating system’s native date picking UI, in which case it would probably be unstylable anyway.

And what of sliders? When you have a pointer/ grabber, its track and tickmarks, what would input[type=range] {color: red;} change? Bear in mind that most browsers don’t follow the one styling suggestion that the spec does offer, which is to render vertical sliders when the input’s CSS height exceeds the width.

One thing that working in the web for a decade has taught me is that where there’s a will, clever people will solve the most head-pulsing problems. But I’m beginning to wonder if there is a will. Phenomenally brainy Tab Atkins wrote

I think any arguments that sites will refuse to use the native controls because they don’t match the site’s theme are countered by the observation that most sites using JS-library equivalents today still don’t theme them very well, or at all. I usually just see a very plain mostly-white calendar, using whatever the default color scheme is for the given library.

This doesn’t meet my experience of developers telling me they’ll continue to use things like jQuery UI because of the themes it offers.

It means that developers continue to make forms out of non-semantic elements like <div> and pile on contenteditable attributes and (hopefully) ARIA attributes and tabindex to make them accessible, even though native form controls are accessible by default.

Anne van Kesteren discusssed this in his clean markup plea:

Write whatever the fuck you want with some WAI-ARIA sugar on top is in some scenarios the only thing what works right now. I do not believe that means we should just let it run its course. The real solution to making a button implemented using five div elements and some scripting accessible is not WAI-ARIA. It is to drastically improve the styling capabilities of <input type=”button”>.


Co-chair of the W3C HTML5 Working Group, Apple’s Maciej Stachowiak tried to get some traction for specifying form styling in 2010:

Popular sites are applying a great deal of custom styling to form controls. One example page we love to use here is If you take a peek in, say, Safari or Firefox, you can see that Google has put a lot of custom styling on the text field and the two <input type=submit> buttons on their home page. This lets them have a custom look while still working in old or obscure browsers, or in browsers with script disabled, and to provide good accessibility while maintaining fairly compact markup. But by styling form controls at all, they are in a no-man’s land in terms of standards. We need to bring this technique into the real of interoperable-specified behavior.

…but to no avail. So what is to be done? The Shadow DOM may help. Shadow DOM gives you access to the internals of browser widgets; for example, the buttons in a <video> element that the browser provides when you specify the controls attribute. It’s a work in progress, part of the suite of specifications called Web Components. Spec editor Dimitri Glazkov writes

Shadow DOM specifies that all HTML elements must behave as if they already have an existing, UA-provided shadow tree, which in turn allows the author-created shadow trees to properly override and even include) those UA-provided shadow trees.

You should be able to do the same exact thing with every other element (though there’s a very tricky issue with IMG, VIDEO, OBJECT, et al. about the nature of “the insides” of the actual replaced content that will need to be first resolved by CSS WG).

So, again, back to the CSS Working Group. I’d like to ask them, when they’re specifying the insides of replaced content, that they do the same with form controls, and give us pseudoelements.

As Tab Atkins continued:

…us devs are mostly lazy, and love being able to write a simple element instead of piping in a library just to do a crappy calendar.

Tab’s absolutely right. And developers really start to use features when they’re specified in languages they already use. We’ve seen this with CSS transitions, animations and filters, all of which were possible for ages in SVG but that was something extra to learn.

The Shadow DOM is potentially a great advance in web development, but it’s a whole new set of technologies. Allowing form styling through CSS would make it simple and allow developers to satisfy the marketing department’s demand for sliders in corporate heliotrope and goldenrod, while using native, accessible controls rather than JavaScript libraries, ARIA bolt-ons and abusing semantics.

If you’re a developer, let me know if you use the native HTML5 form inputs, or – if you use some JS library – do you adjust them to suit your site?

Notes on Contents Strategy Forum 2012, Cape Town

I was fortunate enough to be invited to speak at Content Strategy Forum 2012 which was previously in Paris and London, and this year went to Cape Town. I used to be a content bloke; in fact, I now realise that at The Law Society I was a Content Strategist, there just wasn’t a name for it in 2008.

But that was four years ago, so for this conference I was firmly out of my [American accent] “comfort zone”. Fortunately, I had a preparatory natter with Rellington Annett-Baker to ensure my introductory HTML5 for content specialists talk was likely to hit their sweet spots and tickle their fancies. (It seemed to work.)

The conference was headlined by Kristina Halvorson, and Luke Wroblewski, both of whom seemed to disagree with each other. I’m not well-versed in Content Strategy schisms to have an opinion either way, although Luke’s assertion that we now have a write-read web rang true. Kristina is the godmother of Content Strategy, so her talk was a “state of the nation” speech from paper notes (she’d lost her laptop), largely about how she’d grown her agency to 28 people and then laid off all but five.

Other notable talks were by Razorfish’s Rachel Lovinger who talked about structuring content for re-use, using standards and responsive design in Content in the Age of Promiscuous Reuse.

Relly Annett-Baker’s “Guerillas in their midst” was a fun, British talk about guerilla content strategy. Relly is a black belt at on-stage swearing (I was on best behaviour; these are her friends).

Richard Ingram did an interesting talk about visualising data and recommended the really good Scraping for Journalists book which taught me loads in the first chapter.

John Alderman gave an entertaining talk on how to use Big Data. In it, he spoke about meet-ups where people discuss data they’ve collected about their own bodies. (Yup.) He’d probably be interested in Pete Fletcher’s sneezecount project documenting his sneezes since July 2007 (also see his 5 minute Ignite video On the Counting of Sneezes) and Manu Sporny open-sourcing his genetic data on GitHub.

Great thanks to the organisers: Kerry-Anne Gilowey, Rian van der Merwe, Nathan Blows and Irene Walker. Organisation was perfect; they even managed to get a Cheetah!

Bruce and Luke W stroking a cheetah

I’m no Content Strategist, so I might be entirely wrong, but it felt that this conference was somehow a pivotal event in the solidifying a community. It reminded me of the @media conference of 2005, in which loads of UK web developers first met each other and realised that there is actually a community of UK front-enders and we’re not just a collection of lonely weirdos who read A List Apart. Friendships began; businesses were formed, networks opened and a community came of age. I wonder if Content people in Africa will look back at CSForum 2012 like that.

South Africa

I stuck around in Cape Town for a while, hobnobbing with the great and the good, doing five press interviews, giving some tech talks for developers and business people at Saatchi and Saatchi and the workplace of an old friend Allan Kent who’s Head of Digital at South Africa’s leading media group, Primedia.

An impromptu meet-up was arranged by a Sean O’Connell, a front-end dev, and hosted by Paul Cartmel at New Media Labs (thanks chaps). It was over-subscribed, and too many pizzas and beers were bought; we soldiered on, drinking too much beer and eating too much pizza. (Banana on pizza is wrong, by the way).

I did a talk on why standards are great and good for business (sorry about ugly slides; there wasn’t much time and I preferred gawping at penguins, Chapman’s Peak and brunching with beautiful people to wrangling presentation software!).

In amongst meet-ups and press interviews I did some sight-seeing, mostly under the kindly protection of Allan and saintly Wendy who drove me round to look at Cape Point, Simons Town, Kommetjie, Boulders and other gorgeous places. Their hospitality meant I saw so much I wouldn’t otherwise have done. Thanks so much to both of them.

On my last day, I skived emails after the last press interview and went to Robben Island where the apartheid-era political prisoners were kept. Having been to Auschwitz and Cambodia’s killing fields this year, I didn’t need another reminder of how vile people can be to each other. One redemptive thing about Robben Island, though, is that there are still ex-prisoners and ex-guards living on the island, giving tours around the prison.

On my last night, South Africa’s leading pointillist painter, Gavin Rain, picked me up in his posh car and we drove to Camps Bay where all the beautiful people go. Unfortunately, I was so affected by some twilight Death Pollen that I had to wear my shades all night (not uncommon in Camps Bay). But it did mean my attempts at mild flirtation with the gorgeous Kenyan waitress came to naught, as she doubtless thought Gavin and I were a gay couple splitting up and that I was crying in grief.

My guidebook – which should be renamed “The Alarmist Guide to Cape Town” – had cautioned me never to step out of my hotel or I’d have my kidneys removed. I never felt at all threatened in Cape Town’s CBD. In fact, just the opposite; it was vibrant, friendly and fun.

I don’t know what I expected of South Africa. I suppose I imagined lots of grumpy Afrikaanas trying to pretend they’d never been racist, and desperately poor black people. There certainly are many desperately poor black people; white South African households’ income is six times higher than black ones according to the latest census. And it seems to me that the elder statesmen like Mandela, Sisulu etc are gone, leaving a outrageously corrupt group governing the country.

But it felt to me (from my admittedly brief visit, cocooned in nice hotels in a prosperous city) that South Africa is on its way up, rather than down to Zimbabwe-like failed statehood. The workplaces I visited were highly multi-racial, as you’d expect given the demographics but as you might not expect given the recent history of the country.

Cape Town is probably the most beautifully situated city I’ve visited, with excellent cuisine (mmm, ostrich steaks and Bunnychow). All that, plus I got to talk to interesting people about cool stuff meant that I had a splendid time. Thanks so much to all those I met who made it so memorable.

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




Super-NSFW Corner

  • Fifty Shades Generator – Traditionally, print and web designers had to make use of placeholder text known as Lorem Ipsum. Now, creatives can excite clients in more ways than one with Fifty Shades of Grey-inspired filler text.”

Reading List


Sublime Text 2

I haven’t actually enjoyed using an editor since VAX EDT in my old programming days, but Sublime Text 2 is an excellent program that not only doesn’t get in the way but has lots of utilities and features.


Dell Extends Ubuntu Retail into India – Unreported, of course, because it’s about FOREIGNERS, but Dell have been featuring Ubuntu on a wide range of Dell computers in China, starting at 220 stores and expanding to 350. They’re also expanding in to 850 stores across India.


Specifying which camera in getUserMedia

getUserMedia started life as a nice little API that allowed the developer to grab video and/ or audio from a device.

navigator.getUserMedia({audio: true, video: true}, success, error);

It’s shipping for camera access in Opera 12 desktop and Opera Mobile 12 and implemented in Chrome nightlies.

The spec has ballooned since I last looked at it in detail. There is a new “constraints API” which adds significant complexity, while the language of the spec isn’t rigorous (yet). This is likely to delay standardisation yet the simplest use-cases that it originally met are the core features.

Originally, it had a method for authors to hint to the user agent which camera to use – you could suggest “user” for the camera that faces you, or “environment” for the camera that faces outwards. This has disappeared from the spec, to be dealt with later, once the complex capabilities & constraints API is fleshed out.

Should the author be able to specify which camera should be used? It seems to me that this would be a good idea. For example, my mobile phone camera is usually set to use the rear-facing “environment” camera, but if I were to start up a video-conferencing app (or any of the fun “Photo booth” apps on Shiny Demos) I’d like the app to switch to using the forward-facing “user” camera without my having to manually switch camera. (Some devices don’t have hardware switches, so would require me to go to a system preference to change which camera to use, which would be a major pain in the arse.)

I strongly feel that the Working Group should allow authors to choose which camera to use before fleshing out advanced capabilities & constraints APIs which are beyond the use-cases of many authors.

However, although most phones will continue to have two cameras, some devices like the Mito 611 have more than two. How do we write a specification for hinting which camera to use with multiple cameras?

Reading List


  • Once again, discussion of installable/ packaged web app thingies. Major points:
    • Mozilla doesn’t want to reuse the W3C Widget spec because they want hosted, not installable apps. And the name “widget” is rubbish.
    • Hosted web apps are .. er .. web sites. But wrapped up, with a manifest, they can be monetized in a synergy of micropayment leverage.
    • “Installing” packaged apps can give them greater permissions than web sites. Hixie responded

      The “installation” security model of asking the user up-front to grant trust just doesn’t work because users don’t understand the question, and the “installation” security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn’t scale.

  • Two New Proposals to Solve the CSS3 Vendor Prefix Crisis
  • Last week I linked to an article that claimed adherence to WCAG didn’t magically solve all blind users’ problems. Here’s a rebuttal Methodological flaws put question mark on study of the impact of WCAG on user problems. It seems to me obvious that, while WCAG is very useful, it doesn’t replace brain, or testing.

Mobile and devices

Web Biz


Web Standards Song

“Like A Rounded Corner”, by Bruce and The Standardettes

Reading List

Vendor bloody prefixes

As you may have noticed, Opera announced an experimental Labs build supporting a handful of -webkit- vendor prefixes, based on an idea originally suggested by Daniel Glazman, CSS Working Group co-chair:

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.

Here are some of the most useful commentaries (both for and against). Mostly I haven’t commented, except for Andy Clark’s piece which contained factual inaccuracies which could mislead readers.

My favourite commentary has been Daniel Davis‘ interview with Dr Stanley Dards, wise old man of the web:



Spot the difference!

An exciting competition for readers. Can you spot the difference between these two articles?

Two years ago, Dean Hachamovitch, General Manager of Internet Explorer wrote:

Today, intellectual property rights for H.264 are broadly available through a well-defined program managed by MPEG LA. The rights to other codecs are often less clear, as has been described in the press. Of course, developers can rely on the H.264 codec and hardware acceleration support of the underlying operating system, like Windows 7, without paying any additional royalty.

This week, the BBC reports Motorola wins Xbox and Windows 7 ban in Germany – also Windows 7 system software, Internet Explorer and Windows Media Player:

It follows a ruling that Microsoft had infringed two patents necessary to offer H.264 video coding and playback.


For the sake of open-ness, here’s a link to Opera’s 2011 annual report (Giant PDF!).

There is no truth in alleged “leaked emails” that our business plan reads 1) Publish photos of loads of multi-ethnic hipsters in glossy report 2) alias -webkit- prefixes 3) profit!

Reading List


  • HTML5 gets a new <dialog> element which behaves as top-layer in the fullscreen spec. If the dialog is modal, it makes the rest of the document inert:

    A subtree of a Document can be marked as inert. When a node or one of its ancestors is inert, then the user agent must act as if the element was absent for the purposes of targetting user interaction events … Note: When a node or one of its ancestors is inert, it also can’t be focused.

    An entire Document can be marked as blocked by a modal dialog dialog. While a Document is so marked, every node that is in the Document, with the exception of the dialog element, its ancestors, and its descendants, must be marked inert.

    The great thing about a built-in <dialog> element, even with its egregious mis-spelling, is that it will make a lot of websites more accessible. For example, many sites use pseudo-dialogs that they either write themselves or get from JavaScript libraries. Many of these don’t allow modal dialogs and lightboxes to be closed using just the keyboard, for example (see Lightboxes and keyboard accessibility for more). Building accessible dialogs into the language is far better than expecting every developer to bolt it on.

    There’s already the beginnings of a shim for it.

  • Let’s Talk about Semantics on HTML5 Doctor
  • Flexbox and CSS Grids have too many alignment properties, suggests Fantasai, and attempts to harmonise them.
  • Content order on touch screens by Henny Swan
  • HTML5 Accessibility Chops: ‘real world’ ARIA landmark use – “From an initial analysis the correct use of ARIA landmark roles is surprisingly high. Developers are generally using ARIA landmark roles as intended. Although use is low, there is an major upward trend in use as sites switch to HTML5.”

Open Formats, Open Standards

Proprietary lobby triumphs in first open standards showdown – the UK government is consulting on how it can use “open standards for software and systems are required to ensure interoperability between software systems, applications and data”. Simon Wardley of Leading Edge Forum has more on how the lobbyists of the Big Proprietary Vendors are changing the definitions of “Open” to favour them.

Mobile development

Webdev tools and services


What Users Want from Mobile, and what we can re-learn from them

From Stephanie Rieger’s excellent piece The Best Browser is the One You Have with You, I came upon a report called What Users Want from Mobile (PDF, 3.6 MB), “A study of consumers’ mobile web and application expectations and experiences conducted by Equation Research on behalf of Compuware”, dated July 2011.

There are a couple of key nuggets in there (although the full report is worth a read). First, let’s remind ourselves that the internet contributed £121 billion (not million) to the UK last year, which is more that £2000 per person, making it 8.3% of the economy. Let’s also agree that mobile is an important and rapidly-growing part of that.

A bad experience on a mobile website leaves mobile web users much less likely to return to, or recommend, a particular website. Nearly half of mobile web users are unlikely to return to a website that they had trouble accessing from their phone and 57% are unlikely to recommend the site.

It’s pretty likely that visitors are coming to your website from non-webkit browsers: Opera is huge. It’s becoming more likely as Internet Explorer on Windows Phone 7 hits the market and when Firefox Fennec is released.

If you don’t make sure that your website works in those browsers (this means testing), 50% of those customers won’t come back. And, unless you are selling something completely unique, they’re quite likely to buy from your competitors instead:

Mobile users do not have much patience for retrying a website or application that is not functioning initially — a third will go to a competitor’s site instead.

Another interesting finding is likely to annoy some developers. When asked “What is the most common problem you’ve encountered accessing websites or applications on your mobile phone?”, respondants answered “Slow to load” (38%), “Crashed/froze received an error” (18%), “Formatting made it difficult to read and use” (15%).

This tells us that speed is more important than aesthetics. So perhaps some of the time and effort put into media queries, viewports, avoiding scrolling, line length would actually be better employed reducing HTTP requests and optimising so that websites are perceived to render faster.

Certainly, if you’re using gigantic libraries and frameworks to speed up your development, you might pause to wonder whether trading off faster development for slower loading is a trade-off you want to make, given that most users find speed to be the main problem – and problems drive consumers away and potentially into the arms of competitors.

It seems to me that old-fashioned, oh-so-dull techniques might not be ready for retirement yet. You know: well-crafted HTML, keeping JavaScript for progressive enhancement rather than a pre-requisite for the page even displaying, and testing across browsers.

They might not be cool. But it’s what users want. And if your business doesn’t provide it, your competitors will.

Added 17 April: in a survey conducted in Brazil, 62% agreed that speed was the most important feature for them while browsing the mobile web.