Opera Binary Markup Language

By Chris Mills

Introduction

OBML is a feature available to Opera Mini and browsers created using the Opera Devices SDK 9.6 (all built upon the Presto 2.1 rendering engine)—when OBML is used to render a web page, instead of the whole page being downloaded to the device and rendered it is transformed into the ultra-compact OBML format then sent to the device, which reduces download sizes by up to 90%. This offers obvious advantages to those using devices with low memory or low power, who may also be downloading on slow networks. It does however have cavets that you need to be aware of, in terms of how it renders web technologies.

In this article I’ll cover how the OBML system works, and discuss what caveats there are to be aware of with OBML.

How OBML works

When a browser rendering using OBML requests a web page from a server, the following occurs:

  1. The web page request is sent to a large, power server farm.
  2. This server farm retrieves the requested web page, and converts it into OBML
  3. The OBML version of the page is sent to the browsing device, and displayed in the browser that originally made the request

If the browser does not have available plugins such as a download manager, a video player or a music player, it will usually try to use the device’s own functionality to deal with such things, if it has such functionality available.

CSS and HTML

The OBML servers are able to handle the full HTML and CSS specs as well as any other browser based upon the Presto 2.1 rendering engine—see the Presto 2.1—web standards supported by Opera’s core article for more details. It will also faithfully reproduce other technologies supported by Presto 2.1, such as SVG. The OBML server farm renders the requested web page then takes a snapshot of it before converting it into OBML and sending it to the browser. Any page constructs that render and then remain consistent until the next page load work fine. Technologies that require constant server-client interaction (such as heavy Ajax) or lots of animation tend to be more troublesome’in fact no animations are supported under OBML (including JavaScript, Flash or animated GIFs). We will explore JavaScript as a whole in the next section.

How does OBML interpret JavaScript?

We need to consider where the JavaScript is executed—on the server, before the page loads, or after the page loads. As hinted above, the OBML servers are based on the new Presto 2.1 rendering engine, which means that OBML has full support for JavaScript on the server (ECMAScript 3.)

On the client-side, however, support is limited by the hardware limitations of the handsets; therefore the OBML client itself only supports a limited subset of JavaScript, which means:

  1. Limited support for DOM events
  2. No background scripting
  3. Very limited Ajax support

We’ll look at this in more detail in the sections below.

Server-side support

All scripts executed before a page is fully loaded will work as expected when your page is loaded in Opera Mini. This includes manipulation of elements in the DOM tree. Furthermore, the body element’s onLoad event is fired and its code executed in the OBML server farm before the page is transferred to the client.

The only caveat to consider here is that we don’t allow scripts to run for more than a second or two once the page has finished loading, and will not allow any scripts to run before the user does some kind of user interaction (such as click a link or submit a form)—therefore interval() and delay() are disabled. The same is true for xmlrpc requests—they work but are only allowed to run for a few seconds. Once the page is sent to the device, all scripts are stopped.

Client-side support

After the page has been transferred to the device the browser is running on, things are more limited, as the client does very little JavaScript processing, with most of the processing being done on the server before it is sent to the device. No background scripts running after the page is loaded will be executed, and executing code using setTimeout is not possible.

The supported events are as follows:

  1. Loading: normal event processing is done for onLoad and onUnload.
  2. Forms:
    1. onSubmit
    2. onChange: this even works during filling out a form, not just on submitting the entire form. For example, if you have 2 form fields, “Select Country” and “Select State/Region”, and the second one changes depending on the country you selected in the first one, the OBML will reload to display this change
    3. onClick on buttons (bear in mind that events will only be fired when the form is finally submitted, not while it’s being edited in the client, therefore onFocus would not work)
  3. Clicks: onClick is implemented as a mouse motion to the coordinate being clicked (onMouseEnter, onMouseOver, onMouseLeave etc) followed by onMouseDown followed by onMouseUp and finally onClick.

Other events are ignored/not applicable, for example:

  1. key/mouse events (onMouseOver/-Out/-Down/-Up, onKeyDown/-KeyPress)
  2. focus events (onBlur, onFocus, as mentioned above)

This sounds limiting, but there is another point to consider—OBML can execute JavaScript on the server if it’s triggered by the JavaScript events listed above in the client, so some complex pages work surprisingly well—for instance Facebook is able to display popup menus and popup dialogs very well on OBML browsers.

Ajax Support

Given device limitations and OBML’s client-server architecture, Ajax applications cannot be expected to work as expected on OBML browsers. XMLHttpRequest is supported, therefore many Ajax-powered sites will function pretty well, for example iGoogle (you can’t move boxes around, but you can add and delete them, and change themes,) and GMail (this mostly works, although you don’t get new mails appearing automatically.)

Sites that use Ajax to trigger very regular page changes however, such as Google Suggest and the automatic new mail functionality of GMail mentioned above won’t work. Other examples of things that don’t work are IRC-like chat-clients using server-side events, and clocks.

As mentioned above, client-side events are limited to form changes (onChange and onClick) and clicking (onClick, links, submits, etc.—everything you can do by clicking with a mouse,) so things that react to user input (clicking, or changing form values) usually work, unless they need to see each individual character inputted (eg Google Suggest,) or react to changing state in the outside world (eg new mail, new text message, end of the world, the time, etc.)

What it all boils down to is that once a page has been rendered by the server it won’t change until the user clicks something.

Summary

In this article I have covered OBML, including how it works, and the caveats you need to consider when developing web applications to run in OBML browsers.

Chris Mills is a web technologist, open standards evangelist and education agitator, currently working at Opera Software in the developer relations team. He spends most of his time writing articles about web standards for dev.opera.com and other publications (such as .net mag and A List Apart), giving talks at universities and industry conferences, and lobbying universities to improve their web education courses. He believes that education is the answer to everything, but in particular he is passionate about using education to improve the overall content quality, accessibility, usability and future-viability of the Web.

He is the creator of the Opera Web standards curriculum, contributor to the WaSP InterACT project, and coauthor of InterACT with web standards: A Holistic Approach to Web Design. In August 2011, he also accepted the position of co-chair of the newly-formed Web Education Community Group.

Outside work he is a heavy metal drummer, proud father of three and lover of good beer.


This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.

Comments

The forum archive of this article is still available on My Opera.

No new comments accepted.