Archive for the 'Opera' Category

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.

Reading List – Vendor prefixes, mobile, monoculture

The first reading list of 2012 is themed, rather than the usual miscellany. It’s about the Open Web and the dangers it faces.

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

Reading List

The last reading list of the year is a bumper one, so you have plenty to read over the hols. Enjoy!








Kerrrazy Shit!

Reading list

Here are some links I’ve tweeted recently, for those without time, inclination or access to read them on Twitter. And why would you, when I’ve categorised them here for you?

Web Development

  • That clever Doug Schepers of the W3C has a cunning plan to make html5 <canvas> more accessible:

    a simple graphics API that will allow either 2D Canvas (immediate-mode) or SVG (retained-mode) images with the same set of methods and parameters, with the only difference being which “mode” the author selects to have as the instantiated form. If the author draws a circle to the canvas context, it would simply be drawn to the screen with no structure; if the author draws that same circle to the SVG context, it creates a element with the appropriate attribute values and style and inserts it into the DOM

    This would allow authors to learn only one API for 2D graphics for the Open Web Platform. With this ease of learning and use, the author could decide on a case-by-case basis, even within the same application, which mode works best.

  • WebRTC is real-time communication in the browser (think: video-conferencing). Google open-sourced their code. “we expect to see WebRTC support in Firefox, Opera, and Chrome soon!”
  • Make-super-CSS3-Gradients-o-matic! Super tool for making gradients with all the lovely vendor prefixes
  • Some links on writing HTML5 games
  • Dr Oli Boblet has done research in how blockquotes are attributed in the print world
  • Trygve Lie has some cool Orientation API demos: Using a mobile phone as a remte conrtrol for a video on a desktop, and a remote / receiver demo that captures the orientation events from a device and transfers these over a WebSocket to the receiver to create a rotating image in the receiver. The image in the receiver will rotate depending upon how the remote is rotated.
  • PDF.js: rendering PDF with JavaScript

What’s the opposite of “to develop”? That’s right – “to inhibit” or “to retard”. So after the “Web Development” section, stuff that inhibits the Open Web:

Web Retardation



Installable web apps and interoperability

One (of many) super outcomes of the HTML5 evolution is that browser vendors are striving towards interoperability – even Microsoft is talking of “same markup”.

However, the dedication to interoperability hasn’t spilled over into the world of installable browser applications. Installable apps (in W3C parlance, Widgets – which is a terrible name) allow authors to write apps using HTML(5), CSS, JavaScript, SVG etc, and package them up into a glorified Zip file with some configuration details which can then be installed on a computer. They then use the browser’s rendering engine, but don’t show browser chrome. To all intents and purposes, they’re indistinguishable from native apps.

The W3C defines them as

full-fledged client-side applications that are authored using technologies such as HTML and then packaged for distribution. Examples range from simple clocks, stock tickers, news casters, games and weather forecasters, to complex applications that pull data from multiple sources to be “mashed-up” and presented to a user in some interesting and useful way.

Opera (disclosure: my employer) uses the W3C standard for its packaging format – so the assets are bagged up in a zip file, which is renamed .wgt The configuration information is an XML file that specifies things like required features (eg, camera access), default size of the Widget (full-screen, minimised etc) and its network access permissions. (Learn more or download some widgets and have a play).

W3C Widgets work in Opera browsers (and we re-use the format for Opera Extensions), Apache Wookie, Nokia Series 40 phones [PDF], some Vodafone phones, Windows Mobile 6.5 (although in Win Phone 7 you have to use Silverlight, yay Same markup!) and other places, such as forthcoming interactive classroom whiteboards and TVs.

Chrome has a widget format called .crx that is so similar to W3C Widgets that Scott Wilson wrote a Chrome apps to W3C Widget converter, saying

I was intrigued to find out what sort of formats the Chrome Web Store was using for its “installed web applications”, and discovered somewhat to my surprise it uses yet another packaging and manifest format! This is in addition to the two manifest formats Google already uses (for Gadgets/OpenSocial/Wave and Google App Market).

The format uses the file extension “.crx” and consists of a 7-Zip archive and a manifest file in JSON. The actual contents however are almost identical to W3C Widgets, and so I created a proof-of-concept set of conversion code.

My question to chums in Chrome and Mozilla (which has its own Mozilla Install Manifest format): what’s missing from the standard W3C Widgets specification that you need? Wouldn’t it be better for us all to collaborate on one interoperable specification, as we’re doing so successfully with HTML5?

My chum Marcos Caceres is the editor of the Widgets spec and would doubtless leuurve your feedback.

Update 24 July 2012. I never got an answer from Chrome, but they have announced their own non-standards-based proprietary Packaged Apps format. Hurray for interoperability.