Opera Mini widgets authoring guidelines

By Opera Software

Note: the ability to run Opera Mini widgets on your phone is a B2B product delivered only to Vodafone at this time.

Table of Contents

• Introduction
• Opera Mini Widgets authoring tips
  • Resources
  • General considerations
  • View modes
  • Container issues
  • Animation issues
  • Font issues
  • Layout issues
  • Asynchronous issues
  • Event handler issues
  • Library issues
  • Platform issues

Introduction

Opera Mini widgets attempt to be as close to other widgets as possible. However, there are some differences and issues that widget authors should be aware of. This document attempts to list all the known issues and differences when authoring widgets for Opera Mini.

Opera Mini widgets authoring tips

Resources

• Opera Mini: web content authoring guidelines
• JavaScript support in Opera Mini 4
• Evolving the Internet on your phone: Designing web sites with Opera Mini 4 in mind
• Differences between Opera Mini 3 and 4
• A developer’s look at Opera Mini 5 beta 2
• Mobile-friendly: The mobile web optimization guide

General considerations

The most important issue when developing widgets for Opera Mini is that all the rendering and processing of HTML occurs on a Transcoder server. Keeping this fact in mind it is possible to avoid a lot of mistakes.

View modes

To make sure widgets work properly in Opera Mini the widgets must support the following view modes.

For Opera widgets:

• fullscreen
• docked (optional)

For W3C widgets:

• fullscreen
• mini (optional)

This widgets implementation coforms to the Widgets 1.0: View Modes Media Feature working draft from 6 October 2009.

Container issues

The Opera Mini client does not support scrollbars on individual elements. This means that content that relies on containment in a scrollable box will not work properly. Either the content will be truncated at the end of the container, or the box will be expanded to be big enough for all the content it contains.

If the container is expanded the viewport will scroll instead of the element itself. In many cases this works well. Examples of this are the Twiget (Twitter widget) and the BBC Headline News widget.

A practical consequence of this is that any widget that shows content of varying sizes cannot put controls underneath the content and expect them to be visible.

Animation issues

Since all rendering happens on the Opera Mini transcoder server there is no point in including effects like animations in widgets. In cases where desktop or other widgets are being converted to run on Opera Mini it is just as well to disable animation. There is a risk that the transcoder might send the view back to the Opera Mini client in the middle of an animation.

Font issues

Opera Mini supports a limited number of fonts, and what fonts are available might vary depending on the device. This means that a lot of font style rules will be ignored; fonts end up as being "big", "normal" or "small" regardless.

Layout issues

When rendering widgets on mobile, the transcoder will try to render the content using as much space as possible on the device. In other words, designs should be as fluid as possible so as to be usable on several different screen resolutions. In this regard, developing Opera Mini widgets is not dissimilar to developing fluid layout for normal web pages.

When different styling depending on the size of the target screen is necessary there are two techniques that should work. One is to use CSS media queries based on resolution. The second technique is to position content programmatically by accessing the size of the view port through JavaScript. It is highly recommended that authors favor fluid designs, and only fall back to media queries and JavaScript positioning when necessary.

Asynchronous issues

The transcoder attempts to play nicely with asynchronous activity, that is it tries to run scripts to completion before returning data to the client. Periodic tasks - for example scheduled with setInterval - will be allowed and will run on the server.

Keep in mind that any updates to the screen happening after the Opera Mini transcoder has sent the page to the client will NOT be transmitted. That is, once the page is rendered on the client, it will not be updated until the next time the client has to contact the transcoder, usually due to some user interaction.

Event handler issues

The Opera Mini client supports a limited number of events for <input> elements. It's possible to use onchange and onmouseover, however onkeydown/onkeyup will not work since a full screen text edit box is used.

Library issues

An advantage of having rendering happen on a transcoding server is that the server has significantly more memory, and is much faster than the device itself. This means it should be unproblematic to use libraries, whereas one would normally try to avoid it to save resources on a mobile device.

Platform issues

The Opera Mini server loads widgets from an operating system that is case sensitive with regards to file names. This means that if there are file names referenced in the widget that use a different case than the actual file name the file will not be loaded. For example if there is a file on the file system called ICON.png but it is referenced in the HTML as <img src="icon.png"> then the icon will not appear in the widget. It will however work on platforms that do not care about the case in filenames, for example Windows.

This article is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.