Widgets 1.0: APIs and Events

W3C Working Draft 18 August 2009

This Version:
Latest Version:
Previous Versions:
Marcos Cáceres, Opera Software ASA
Robin Berjon, Vodafone
Arve Bersvendsen, Opera Software ASA


This specification defines an application programming interfaces (APIs) for widgets that enable functionality for accessing widget metadata and persistently storing data.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This is the 18 August 2009 Last Call Working Draft version of the "Widgets 1.0: APIs and Events" specification. The Last Call period ends on 15 September 2009. The requirements, which are listed in the specification, were addressed and specified through extensive research, and via consultation with W3C members and the public via the Working Group's mailing lists (WAF archive, WebApps archive). The purpose of this Last Call is to give external interested parties a final opportunity to publicly comment on how the API should work within widgets before the Working Group issues a call for implementations. The Working Group's goal is to make sure that vendor's requirements for an API for widgets have been effectively addressed and clearly specified.

This document is produced by the Web Applications WG, part of the Rich Web Clients Activity in the W3C Interaction Domain. It is expected that this document will progress along the W3C's Recommendation track. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

You can find the latest Editor's Draft of this document in the W3C's CVS repository, which is updated on a very regular basis. The public is encouraged to send comments to the Web Apps Working Group's public mailing list public-webapps@w3.org (archive). See W3C mailing list and archive usage guidelines. A detailed list of changes from the previous version is also available from the W3C's CVS server.

Interested parties should be aware that this document is not stable and should not be implemented. Interested parties who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. If you are interested in implementing this document before it eventually reaches the Candidate Recommendation stage, join the aforementioned mailing lists and take part in the discussions.

Table of Contents

1 Introduction

This section is non-normative.

This specification defines APIs and events for the Widgets 1.0 family of specifications that enable baseline functionality for widgets. The APIs and events defined as part of this specification provide, amongst other things, the means to:

This specification defines APIs using [WebIDL].

1.1 The Widget Family of Specifications

This section is non-normative.

Widgets are client-side applications authored using Web standards. They are downloaded and installed on a client machine or device where they can run as stand-alone applications outside of a Web browser. Examples range from 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 (see [Widgets-Landscape] for more information). The environment in which a widget runs is referred to as a widget user agent.

This specification is part of the Widgets 1.0 family of specifications, which together standardize widgets as a whole:

1.2 Design Goals and Requirements

This section is non-normative.

The design goals and requirements for this specification are addressed in the Widgets 1.0 Requirements [Widgets-Reqs] document.

This document addresses the requirements relating to Application Programming Interfaces of the 30 April 2009 Working Draft of the Widgets 1.0: Requirements Document:

The following requirements relating to Application Programming Interfaces are not addressed by this specification:

2 Definitions

The following definitions are used throughout this specification. Please note that other terms are given throughout this document and defined where they are used.

Widget context

An environment in which a Widget object is presented to the user. When a user agent instantiates a start file, the content of the start file is said to be running in a widget context.

Author script

An script running within the widget context (e.g., some ECMAScript).

Valid IRI

A string that matches the IRI token of the [RFC3987] specification.


A runtime component (e.g. an Application Programming Interface) that is not part of the defined set provided by the Widgets 1.0 family of specifications.


A CSS viewport. For a start file rendered on continuous media, as defined in the [CSS21] specification, a viewport is the area on which the Document of the start file is rendered by the user agent.

A user agent must exclude scrollbars, toolbars, and other "chrome" when calculating the dimensions of the viewport.


A DOM attribute is said to be getting when its value is being retrieved (e.g. by an author script).


A DOM attribute is said to be setting when a new value is assigned to it (e.g. by an author script).


The first run through the Steps for Processing a Widget Package, as specified in the [Widgets-Packaging] specification, prior to runtime.

Configuration document

A configuration document is a file called "config.xml" at the root of the widget package as specified in the [Widgets-Packaging] specification.

Start file

A start file designates a file from the widget package to be loaded by the user agent when it instantiates the widget, as specified in the [Widgets-Packaging] specification.

Origin of a widget

The universally unique identity of a widget represented as a URI, established via the rules defined in the [Widgets-URI] specification.


A persistently stored name-value pair that is associated with the widget the first time the widget is initiated.

3 Conformance

As well as sections marked as non-normative, all diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words must, must not, required, should, should not, recommended, may and optional in this specification are to be interpreted as described in [RFC2119].

This specification describes the conformance criteria for user agents (relevant to implementers).

There are two classes of product that can claim conformance to this specification:

  1. a user agent.
  2. a storage area.

4 User Agents

A user agent is software that supports storage areas and implements the widget interface defined in this specification.

A user agent must behave as described in this specification in order to claim conformance.

Note: The user agent described in this specification does not denote a "widget user agent" at large. That is, a user agent that implements all the specifications, and dependencies, defined in the Widgets 1.0: Family of Specifications. The user agent described in this specification is only concerned with the behavior of programming interfaces.

Note: Implementers can partially check their level of conformance to this specification by successfully passing the test cases of the [A&E-Test-Suite]. Note, however, that passing all the tests in the test suite does not imply conformance to this specification; It only implies that the implementation conforms to aspects tested by the test suite.

A user agent must establish the origin of a widget using the rules set forth in the [Widgets-URI] specification.

4.1 Support of Other Specifications

A user agent supports a specification if it implements and conforms to that specification.

A user agent must support:

5 Storage Areas

A storage area is a data-store that is unique for the origin of a widget, which a user agent can use to store string-based key-value pairs.

A user agent must provide a means to flag a key, and its corresponding data, as a protected key.

A user agent must have the ability to create one ore more unique storage areas, one for each origin of a widget.

A user agent must have the ability to directly read and write to the storage area (i.e., without needing to make use of the [WebStorage] specification's Storage interface) and must have the ability to delete a storage area.

A user agent should preserve the values stored in a storage area across subsequent instantiations of a widget (i.e., the data needs to be saved if the widget is closed, the device is rebooted, and then the widget is reopened).

A user agent may expire data from a storage area for security reasons, or when requested to do so by the end user, or if the user agent detects that it has limited storage space.

A user agent should avoid deleting data from a storage area while a script that could access that data is running.

A user agent must only allow author scripts to interact with a storage area via the [WebStorage] specification's Storage interface, but must behave in accordance with this specification any time a script accesses a storage object that a user agent has associated with the origin of a widget.

A user agents should limit the total amount of space allowed for storage areas. An arbitrary limit of five megabytes per origin of a widget is recommended.

Implementation feedback is welcome on an appropriate storage size for widgets and will be used to update this suggestion in the future.

A user agent should impose their own implementation-specific limits on the length of otherwise unconstrained keys and values of a storage area, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.

A User agent may prompt the user when total amount of allowed space for a storage is reached, allowing the user to grant a widget more space. For instance, this enables widgets to incrementally store user-created media (e.g., photos, drawings, emails, documents) on the end-user's device.

A user agents may allow end-users to know the amount of space a storage area is using (e.g., through some visual interface external to the widget).

5.1 Protected Keys in the Storage Area

As an extension to the [WebStorage] specification, this specification allows certain keys, and corresponding values, in a storage area to be protected; meaning that author scripts cannot change or delete protected keys, and corresponding values, in a storage area.

A protected key is a preference held by the widget preferences variable of the configuration defaults table that an author has explicitly flagged as "read-only" (denoted by a preference having a readonly value set to true). A user agent must not allow author scripts to change or delete protected keys, and corresponding values, in a storage area.

A user agent must only create a protected key in a storage area when the preferences attribute is initialized.

Upon invocation of the setItem() or removeItem() method by an author script on a protected key, user agent must throw a NO_MODIFICATION_ALLOWED_ERR exception. The NO_MODIFICATION_ALLOWED_ERR is defined in the [DOM3Core] specification.

Upon invocation of the preferences attribute's clear() method, a user agent must not remove protected keys and corresponding values from a storage area. A user agent, must, however, remove other (unprotected) keys and corresponding values from the storage area in the manner described in the [WebStorage] specification.

Upon getting, via the key() and getItem() methods, a user agent must allow a protected key to be read by author scripts.

6 The Widget Interface

The Widget interface primarily provides access to metadata derived from processing the widget's configuration document. It also provides an interface for persistently storing, modifying, and deleting key value data (via the preferences attribute).

A user agent must implement the Widget interface as a widget attribute in the global object context of the widget's start file.

A user agent whose start file implements the HTML5 Window interface, must implement the Widget interface as the widget attribute of the window object in the following manner:

[Supplemental] interface Window {
  readonly attribute Widget widget;

Within the widget context, the Widget object provides the following attributes and methods.

interface Widget {
    readonly attribute DOMString     author;
    readonly attribute DOMString     authorEmail;
    readonly attribute DOMString     authorHref;
    readonly attribute DOMString     description;
    readonly attribute DOMString     id;
    readonly attribute DOMString     name;
    readonly attribute Storage       preferences;
    readonly attribute DOMString     version;
    readonly attribute unsigned long height;
    readonly attribute unsigned long width;
    void openURL(in DOMString uri);

A user agent may support the Storage interface on DOM attributes other than the preferences attribute (e.g., a user agent can to support the [WebStorage] specification's localStorage attribute of the window object in conjunction to preferences attribute defined in this specification).

Note: for the sake of interoperability across widget user agents, and where it makes sense, authors should use the preferences attribute over other APIs that provide a Storage interface.

6.1 Metadata Attribute Values

During the [Widgets-Packaging] specification's steps for processing a widget package, the resulting data is stored by the user agent in the configuration defaults table that is defined in the [Widgets-Packaging] specification. Most of the attributes of the widget interface correspond to the metadata derived from processing a widget's configuration document.

Upon initialization, a user agent must set the attributes identified in the left column of the configuration attributes table to the values that correspond in the [Widgets-Packaging]'s the configuration defaults table, as identified by the right hand column.

Configuration Attributes Table
Attributes Values in Configuration Defaults Table
author author name
authorEmail author email
authorHref author href
description widget description
id widget id
name widget name
version widget version

Upon getting any of the attributes in the configuration attributes table, a user agent must return the value the attribute as was set in the configuration attributes table.

6.1.1 Usage Example

This section is non-normative.

// Hypothetical example that emails a bug to an Author
function emailBug(bug){
    var subject  = widget.name   + " (" + widget.version + ")";
    var to       = widget.authorEmail;
    var emailURI =    "mailto:"   + to 
                    + "?subject=" + escape(subject) 
                    + "&body="    + escape(bug); 
  //use email client to send email

// Hypothetical example that generates an about box 
// using metadata from a widget's configuration document. 
function makeAboutBox(){
    var title    = "<h1>" + widget.name + "</h1>";
    var version  = "<h2>Version: " + widget.version + "</h2>";
    var id       = "<p><small>" + widget.id +"</small></p> <hr/>";
    var auth     = "<p>Created by: " + widget.author + "</p>"; 
    var homepage = "<p>My Site: "  +widget.authorHref + "</p>" 
    var desc     = "<h3>About this Widget</h3><p>"  
                  + widget.description + "</p>";
    var box      = "<div id='aboutBox'>" 
    + title + version + id + auth + desc +
    document.getElementById("console").innerHTML = box; 

6.2 The width Attribute

Upon getting the width, the user agent must return the width in [CSS21] pixels of the widget context’s viewport.

6.2.1 Usage Example

This section is non-normative.

function getHypotenuse(){
    var x   = widget.width;  
    var y   = widget.height;  
    var hyp = Math.sqrt(x*x + y*y);
    return hyp;

6.3 The height Attribute

Upon getting the height attribute, the user agent must return the height in [CSS21] pixel of the widget context’s viewport.

6.3.1 Usage Example

This section is non-normative.

function getHypotenuse(){
    var x   = widget.width;  
    var y   = widget.height;  
    var hyp = Math.sqrt(x*x + y*y);
    return hyp;

6.4 The preferences attribute

The purpose of the preferences attribute is to allow authors to manipulate the storage area that is unique for the origin of a widget.

A user agent must initialize the preference attribute in accordance with this specification.

Upon getting the preference attribute, the user agent must return a Storage object that represents the storage area for the origin of a widget.

A user agent must not fire a storage event, described in [WebStorage], if calling the setItem() or removeItem() causes a NO_MODIFICATION_ALLOWED_ERR exception to be thrown.

Whenever the user agent performs any of the following operations on the Storage object of a preference attribute, the user agent must obtain the storage mutex in manner specified in the [WebStorage] specification:

The above applies as part of:

6.4.1 Initialization of the preferences Attribute

If a user agent has not previously associated a storage area with the origin of a widget, then the user agent must initialize the preference attribute.

The steps to initialize the preference attribute are as follows:

  1. Establish the origin of a widget for this widget.

  2. Create a storage area that is unique for the origin of a widget.

  3. If the widget preferences variable of the configuration defaults table contains any preferences, then for each preference held by widget preferences:

    1. Let pref-key be the name of the preference.

    2. Let pref-value be the value of the preference.

    3. If pref-key is not protected by the storage area, then attempt to add pref-key and pref-value to the storage area:

      1. If the pref-key already exists, override the value for that key-pref in the storage area with pref-value.

      2. If the user agent cannot write to the storage area (e.g., because it ran out of disk space, or the space quota was exceeded, etc.), apply the rule for dealing with an invalid Zip archive specified in the [Widgets-Packaging] specification.

      3. If this preference's associated readonly value is true, then treat this key as a protected key in the storage area for the lifetime of the widget.

  4. Implement the Storage interface on the storage area, and make the preferences attribute a pointer that storage area.

For example, consider the case whereby widget preferences contains the following preferences (represented as JSON, for simplicity):

         {‘name’     : ‘apples’, 
          ‘value’    : ‘5’,
          ‘readonly’ : ‘false’},

         {‘name’     : ‘apples’, 
          ‘value’    : ‘12345’,
          ‘readonly’ : ‘false’},
         {‘name’     : ‘apples’, 
          ‘value’    : ‘1000’,
          ‘readonly’ : ‘true’},

         {‘name’     : ‘apples’, 
          ‘value’    : ‘52’,
          ‘readonly’ : ‘false’}

Encountering the above set of preferences, the user agent would behave in the following manner with respect to the storage area:

  1. For the first preference, the user agent stores the key ‘apples’ with the value ‘5’ and ignores the value of ‘readonly’ as it is ‘false’.

  2. For the second preference, the user agent overrides the key ‘apples’ with the value ‘12345’ and ignores the value of ‘readonly’ as it is ‘false’.

  3. For the third preference, the user agent overrides the key ‘apples’ with the value ‘1000’. As, the value of ‘readonly’ is ‘true’, the user agent flags the key ‘apples’ as protected in the storage area.

  4. For the fourth preference, as the key ‘apples’ is now a protected key, attempt by the user agent to store the value will be ignored.

6.4.2 Usage Example

This section is non-normative.

  var form = document.getElementById("prefs-form");
  function loadPrefs () {
      form.querySelectorAll("input, select, textarea").forEach(function (field) {
          if (typeof widget.preferences[field.name] != "undefined") field.value = widget.preferences[field.name];

  function savePrefs () {
      form.querySelectorAll("input, select, textarea").forEach(function (field) {
          widget.preferences[field.name] = field.value;
      return false;


<form onsubmit="savePrefs()" id="prefs-form">
 <legend>Game Options</legend>

 <label for="volume">Volume: </label> <input type="range" min="0" max="100" name="volume"/>
 <label for="hints">Hints: </label> <input type="range" min="0" max="100" name="hints"/>
 <input type="submit" value="OK"/>


6.5 The openURL() Method

The openURL() method provides authors with a means to defer the handling of IRIs, defined in [RFC3987], to an appropriate scheme handler for the given IRI scheme (if one is available). The openURL() method takes a valid IRI as an argument.

When invoked, a user agent should open the provided iri with the appropriate handler for the given URI scheme. If there is no such scheme handler, or it is otherwise rejected by the user agent (e.g., because of security policy or user prompting), or iri is not a valid IRI, then the user agent must act as if the method had not been invoked.

The user agent should inform the end-user when a request to handle the IRI via the openURL() method has failed.

If a relative reference is used as an argument for openURL(), a user agent must act as if the openURL() method had not been invoked.

6.5.1 Usage Example

This section is non-normative.

//open email 

//make a phone call 


//open a web page

//send and sms




Max Froumentin, Rune F. Halvorsen.

Normative References

Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification, B. Bos, I. Hickson, T. Çelik, H. Wium Lie. W3C Candidate Recommendation 23 April 2009.
Document Object Model (DOM) Level 3 Core Specification, A. Le Hors, P. Le Hégaret, L. Wood, G. Nicol, J. Robie, M. Champion, S. Byrne, editors. World Wide Web Consortium, April 2004.
Key words for use in RFCs to Indicate Requirement Levels, RFC2119, S. Bradner. March 1997.
Internationalized Resource Identifiers (IRIs). RFC3987, M. Duerst, M. Suignard. January 2005.
Uniform Resource Identifier (URI): Generic Syntax.RFC 3986, T. Berners-Lee, R. Fielding and L. Masinter. January 2005.
Widgets 1.0: Packaging and Configuration. M. Caceres, Ed. W3C Last Call Working Draft May 2009. (Work in progress)
Web IDL. Cameron McCormack. W3C Working Draft, 19 December 2008. (Work in progress).
Web Storage. I. Hickson. W3C Working Draft, 23 April 2009. (Work in progress).
Widgets 1.0: Widget URI. Robin Berjon. W3C Working Draft 18 June 2009 (Work in progress).

Informative References

Widgets 1.0: The Widget Landscape (Q1 2008). M. Caceres. W3C Working Draft. 14 April 2008.
Widgets 1.0: Digital Signature
Widgets 1.0: Access Requests Policy. Robin Berjon. W3C Working Draft 4 August 2009 (Work in progress).
Widgets 1.0 Requirements, M. Cáceres and M. Priestley. W3C Working Draft, 30 April 2009 (Work in progress).
Widgets 1.0: Media Query Extensions. A. Bersvendsen and M. Caceres. Unpublished editors' draft.
Widgets 1.0: Updates. M. Cáceres. W3C Working Draft, 7 October 2008 (Work in progress).
Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, R. Fielding, et al. June 1999.