Opera Mini widgets authoring guidelines
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
- Opera Mini Widgets authoring tips
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
- Opera Mini: web content authoring guidelines
- 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
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.
To make sure widgets work properly in Opera Mini the widgets must support the following view modes.
For Opera widgets:
- docked (optional)
For W3C widgets:
- mini (optional)
This widgets implementation coforms to the Widgets 1.0: View Modes Media Feature working draft from 6 October 2009.
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.
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.
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.
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.
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
onkeyup will not work since a full screen text edit box is used.
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.
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.