Abstract
This specification defines an application programming interface (APIs)
for widgets that provides, amongst other things, functionality for
accessing a widget's 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 4 November 2009 Last Call Working Draft version of the
"Widgets 1.0: The widget Interface" 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
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 an application programming interface that
enables baseline functionality for widgets, including the ability to:
- Access some of the metadata declared in a widget's configuration document,
- Persistantly store data relating to a widget instance.
- Handle an IRI through an appropriate scheme handler.
- Retrive the name and value of preferences, which may have been
declared in a widget's configuration document.
This section is non-normative.
This specification is part of the Widgets 1.0 family of
specifications, which together standardize widgets as a whole. The
list of
specifications that make up the Widgets 1.0 Family of Specifications
can be found on the Working Group's wiki.
1.2
Design Goals and Requirements
This section is non-normative.
The design goals and requirements for this specification are documented
in the Widgets 1.0 Requirements [Widgets-Reqs] document.
This document addresses some of the requirements relating to
Application Programming Interfaces of the 30 April 2009 Working Draft
of the Widgets 1.0: Requirements Document:
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.
- Author script
-
An script running within a widget
instance (e.g., some ECMAScript).
- 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.
- Feature
-
A runtime component (e.g. a device API, video decoder, etc.) that is
made available by the user agent to the widget instance as a direct result of an
author requesting its availability via a feature element in the widget's configuration document.
- Getting
-
A DOM attribute is said to be getting when its value is being
retrieved (e.g. by an author script).
- Initialization
-
When a user agent first runs a widget
package through the Steps
for Processing a Widget Package, as specified in the [Widgets-Packaging] specification, prior
to runtime.
-
-
- Preference
-
A persistently stored name-value pair that is associated with the
widget the first time the widget is initiated.
- Setting
-
A DOM attribute is said to be setting when a new value is assigned to
it (e.g. by an author script).
- 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.
- Supports
-
A user agent implements a mentioned specification or conformance
clause.
- Valid IRI
-
A string that matches the IRI token of the [RFC3987] specification.
- Viewport
-
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. The
dimensions of a viewport excludes scrollbars, toolbars, and other user
interface "chrome".
- Widget Instance
-
A widget instance is a top-level browsing context whose
origin is valid IRI. The
concepts of a top-level browsing
context and origin are defined in
[HTML5].
All examples and notes in this specification are non-normative, as are
all sections explicitly marked non-normative. Everything else in this
specification is normative.
The key words must, must not,
should, recommended, may and optional in the normative
parts of this specification are to be interpreted as described in [RFC2119].
The only conformance class defined by this specification is user agents. Conformance requirements phrased as
algorithms or specific steps can be implemented in any manner, so long as
the end result is equivalent to what would be archived when following the
specification. (In particular, the algorithms defined in this
specification are intended to be easy to follow, and not intended to be
performant.)
4 User Agents
A user agent is a software implementation of
this specificaiton that also supports the [Widgets-Packaging] specification.
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. A user agent needs
to impose implementation-specific limits on otherwise unconstrained
inputs, e.g. to prevent denial of service attacks, to guard against
running out of memory, or to work around platform-specific limitations.
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.
The Widget
interface primarily provides access to metadata derived from processing
the widget's configuration document.
The interface also allows authors to access persistently-stored
preferences (via the preferences attribute).
This specification uses [WebIDL] to define the
application programming interfaces.
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
HTML5's Window interface, must implement the Widget interface as the
widget attribute of the window object in the following manner:
[Supplemental, NoInterfaceObject]
interface WindowWidget {
readonly attribute Widget widget;
};
Window implements WindowWidget;
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 DOMString shortName;
readonly attribute Storage preferences;
readonly attribute DOMString version;
readonly attribute unsigned long height;
readonly attribute unsigned long width;
void openURL(in DOMString iri);
};
Note: A user agent can 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
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.
During the [Widgets-Packaging]
specification's steps
for processing a widget package, the resulting data is stored by the
user agent in the Table of
Configuration Defaults 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 of the widget object, a user agent must set the attributes identified in the left column of
the configuration attributes table to the values that correspond to the
Table of Configuration Defaults as defined in [Widgets-Packaging] (identified by the
values in the right hand column).
Configuration
Attributes Table
| Attributes |
Values in Table of Configuration Defaults |
author |
author name |
authorEmail |
author email |
authorHref |
author href |
description |
widget description |
id |
widget id |
name |
widget name |
version |
widget version |
shortName |
widget short name |
Upon getting any of the attributes in the configuration attributes
table, a user agent must return the value the configuration attributes
table.
5.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
widget.openURL(emailURI);
}
// 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 +
"</div>";
document.getElementById("console").innerHTML = box;
}
5.2 The width Attributes
Upon getting the width,
a user agent must return the width of the widget instance’s viewport
in [CSS21] pixels.
5.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;
}
5.3 The height Attribute
Upon getting the height
attribute, a user agent must return the height of the widget instance’s viewport
in [CSS21] pixels.
5.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;
}
5.4 The preferences
attribute
The purpose of the preferences attribute is to allow
authors to manipulate the storage area that is
unique for the instance of a widget.
Upon invocation of the setItem() or
removeItem() method by an author
script on a read-only item, user agent must throw a NO_MODIFICATION_ALLOWED_ERR
exception and must not fire a storage event (described
in [WebStorage]). 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 read-only items and
corresponding values from a storage area. A
user agent, must, however, remove other items 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 read-only key to be read by author scripts.
When the preferences attribute is accessed, the user agent
must run the following steps:
-
If the Document's effective script origin is
not the same origin as the Document's origin, then throw a SECURITY_ERR
exception and abort these steps. The concept of effective script
origin and same origin are defined in
[HTML5].
-
Check to see if the user agent has associated a storage area for the
origin of the Document of the
Window object on which the method was
invoked. If a user agent has not previously associated a storage area with the instance of a
widget, then the user
agent must initialize the
preferences attribute.
-
Return the Storage object
associated with that origin's storage area. Each Document
object must have a separate object for its widget's preferences attribute.
5.4.1
Usage Example
This section is non-normative.
<!doctype html>
...
<fieldset id="prefs-form">
<legend>Game Options</legend>
<label>Volume: <input type="range" min="0" max="100" name="volume"/> </label>
<label>Difficulty: <input type="range" min="0" max="100" name="difficulty"/> </label>
<input type="button" value="Save" onclick="savePrefs()"/>
<input type="button" value="load" onclick="loadPrefs()"/>
</fieldset>
...
<script>
var form = document.getElementById("prefs-form");
var fields = form.querySelectorAll("input[type='range']");
function loadPrefs () {
for(i in fields){
var field = fields[i];
if (typeof widget.preferences[field.name] != "undefined") {
field.value = widget.preferences[field.name];
}
}
}
function savePrefs () {
for(var i = 0; i < fields.length; i++){
var field = fields[i];
widget.preferences[field.name] = field.value;
}
}
</script>
5.4.2 Initialization of the preferences
Attribute
The steps to initialize
the preferences attribute are given by the following
algorithm:
-
Establish the instance of a widget for this widget and
create a storage area that is unique for the
origin.
-
If the widget preferences variable of the Table of Configuration
Defaults contains any preferences, then for each preference held by widget
preferences:
-
Let pref-key be the name
of the preference.
-
If the pref-key already exists in the storage area, stop processing this
preference: go back to step 2 in
this algorithm, and process the next preference (if any).
-
Let pref-value be the value of the preference.
-
Directly write pref-key and pref-value to the
storage area (i.e., don't use the Storage interface):
-
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.), terminate all
processing of this widget. It is recommended
that the use agent inform the end-user of the error.
-
If this preference's
associated readonly value is true, then flag
this key as a protected key in the storage area.
-
Implement the Storage interface on the storage area, and make the
preferences attribute a pointer to that storage area.
5.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 handle 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), then
the user agent must act as if the method had not been
invoked.
If the iri is not a valid IRI, the
user agent should inform the end-user that the request
to handle the IRI method has failed.
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.
5.5.1
Usage Example
This section is non-normative.
//open email
openURL("mailto:jsmith@example.org?subject=A%20Hello&body=hi");
//make a phone call
openURL("tel:+1234567678");
//open a web page
openURL("http://example.org");
//send and sms
openURL("sms:+41796431851,+4116321035;?body=hello%20there");
//SSH
openURL("ssh://user@host.example.com:2222");
6 Storage Areas
A storage area is a data-store that is
unique for the widget instance, which a
user agent uses to store key-value pairs that pertain to the
preferences attribute. An author
script interacts with the storage area via
the [WebStorage] specification's Storage interface.
To facilitate the storage of preferences during
the initialization of the preferences
attribute, a user agent
must have the ability to directly read and write to a
storage area without invoking the methods of
the [WebStorage] specification's Storage interface.
A user agent must preserve the values stored in a
storage area when a widget is re-instantiated
(i.e., if the widget is closed, the data is saved; when the device is
rebooted and the widget is reopened, the save data is made available to
the storage area).
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.
6.1
Read-only Items in the Storage Area
As an extension to the [WebStorage]
specification, this specification allows certain key-value pairs (items)
in a storage area to be read-only: a read-only item is an item in a storage area that cannot be modified or deleted
by an author script. A
read-only item always represents a preference that author explicitly
flagged as "read-only" in the widget's configuration document
(denoted by the preference having
readonly attribute value set to true). Read-only
items are created by the user agent when the preferences attribute is
initialized.
Acknowledgements
Max Froumentin, Rune F. Halvorsen, Scott
Wilson, Addison Phillips, Alexander Dreiling, Arun Ranganathan, Arthur
Barstow, Bárbara Barbosa Neves, Brian Wilson, Bjoern Hoehrmann, Benoit
Suzanne, Bert Bos, Boris Zbarsky, Bradford Lassey, Cameron McCormack,
Cliff Schmidt, Claudio Venezia, Coach Wei, Corin Edwards, Dan Brickley,
David Clarke, Dean Jackson, David Pollington, Doug Schepers, Ed Voas,
Felix Sasaki, Francois Daoust, Gautam Chandna, Geir Pedersen, Gene
Vayngrib, Gorm Haug Eriksen, Guido Grassel, Hari Kumar G, Ian Hickson, Jay
Sweeney, Jere Käpyaho, Jim Ley, Jon Ferraiolo, Jose Manuel Cantera
Fonseca, Josh Soref, Jouni Hakala, Joey Bacalhau, Kevin Lawver, Kai
Hendry, Krzysztof Maczyński, Lachlan Hunt, Marc Silbey, Marcin
Hanclik, Mark Baker, Mikko Pohja, Mohamed Zergaoui, Olli Immonen, Philipp
Heltewig, Philip Taylor, Scott Wilson, Stephen Paul Weber.
Normative References
- [CSS21]
- 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.
- [DOM3Core]
- 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.
- [RFC2119]
- Key words for use in
RFCs to Indicate Requirement Levels, RFC2119, S. Bradner.
March 1997.
- [RFC3987]
- Internationalized
Resource Identifiers (IRIs). RFC3987, M. Duerst, M. Suignard.
January 2005.
- [URI]
- Uniform Resource
Identifier (URI): Generic Syntax.RFC 3986, T. Berners-Lee, R.
Fielding and L. Masinter. January 2005.
- [Widgets-Packaging]
- Widgets 1.0: Packaging
and Configuration. M. Caceres, Ed. W3C Last Call Working Draft
May 2009. (Work in progress)
- [WebIDL]
- Web
IDL. Cameron McCormack. W3C Working Draft, 19 December 2008.
(Work in progress).
- [WebStorage]
- Web
Storage. I. Hickson. W3C Working Draft, 23 April 2009. (Work
in progress).
- [Widgets-Landscape]
- Widgets 1.0: The
Widget Landscape (Q1 2008). M. Caceres. W3C Working Draft. 14
April 2008.
- [Widgets-DigSig]
- Widgets 1.0:
Digital Signature
- [A&E-Test-Suite]
- Forthcoming.
- [Widgets-Access]
- Widgets 1.0:
Access Requests Policy. Robin Berjon. W3C Working Draft 4
August 2009 (Work in progress).
- [Widgets-Reqs]
- Widgets 1.0
Requirements, M. Cáceres and M. Priestley. W3C Working Draft,
30 April 2009 (Work in progress).
- [Widgets-Views]
- Widgets
1.0: Media Query Extensions. A. Bersvendsen and M. Caceres.
Unpublished editors' draft.
- [Widgets-Updates]
- Widgets 1.0:
Updates. M. Cáceres. W3C Working Draft, 7 October 2008 (Work
in progress).
- [HTTP]
- Hypertext Transfer
Protocol -- HTTP/1.1, RFC 2616, R. Fielding, et al. June 1999.