Archive for the 'Opera' Category

Reading List

NEWT

Industry

Misc

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

CSS

Standards

Industry

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

NEWT

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.

Industry

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.

misc

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

Standards

  • 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

Misc

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:

Mobile

HTML, CSS

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.

Opera

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

HTML and CSS

  • 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

Misc

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!

Me

HTML

CSS

JavaScript

Multimedia

Data

Mobile

Kerrrazy Shit!