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.

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

• Apple’s new multitouch patent
• The W3C seeks info about access control systems available before October 2005 and content distribution systems before April 2006 that offer a viable solution that may apply to the use of access requests policy in Widgets (Our Good Friends at Apple claim to have patents which they say apply to Web Application WG’s Widget Access Request Policy specification)

Opera

• Opera Desktp 11.50 released
• Opera Mobile 11.1 released
• Shwetank has getUserMedia and Device Orientation adventures

Misc

• Need to get from Bell End to Fisting Roughly? Here’s the rude Tube map (NSFW)
• Awkward girl in pink in Rebecca Black’s ‘Friday’ video uses sudden fame to raise money for charity and shows herself to be Queen of Internet

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.

• WebVTT explained (Silvia Pfeiffer)
• WYSIWYG support for @longdesc today (John Foliot)
• The <hgroup> hokey cokey HTML5 Doctor
• Table summary attributes are no more in HTML5 (W3C)
• Implementing HTML5 <details> (me)
• HTML5 video issues on the iPad and how to solve them, Unsolved HTML5 video issues on iOS (Miller H. Borges Medeiros)

Other Web

• A nice SIL Open font-licensed Khmer font called Hanuman
• Opera and Grameenphone in Bangladesh (Me)
• JavaScript performance (Eric Moller, Opera)
• Government publishes cookie law plans and says browser settings cannot give consent (OutLaw)
• Let the cookie crumble and give us net neutrality (The Guardian)

Lulz

• Meta flowchart
• “The potato literally encouraged the Irish to overbreed.” Literally. (Shit My Students Write)
• Just plain wrong: Watching Osama Bin Laden watching me leverage a synergy (Tom Scott)

Opera Dragonfly

The big news was that Opera Dragonfly was released. I made a video to introduce it to you (best viewed full screen):

Opera Dragonfly tour (8 mins) from Bruce Lawson on Vimeo.

This will be a really fast-moving talk with tips and code snippets you can use right away. We’ll cover

• mobile web philosophy: what is “mobile web”?
• The three methodologies for mobile web development
• What new goodies HTML5, CSS 3 and JavaScript offer us
• Tips and tricks (code) to make your site faster on mobile
• Apps vs Web and how the boundary is blurring
• What’s coming soon, with hopefully a preview of what’s cooking in Opera Labs

I doubt many people will be there—it’s pretty late in the day, but do come along if you can. Otherwise, please come and say hi at the Opera booth in the trade show; there will be a giant red O suspended from the ceiling, so you can’t miss us.

I’m doing a cut-down version (1 hour into 40 minutes) at The Big M Conference in Bath, UK, where Patrick Lauke will be giving a 3 hour workshop.

Here are the slides.