The first eye catching point was w3c definition of what is a widget.
"A Widget is an interactive single purpose application for displaying and/or updating local data or data on web, packaged in a way to allow a single download and installation on a user's machine or mobile device."
As of this writing there are many Draft documents related to Widget Specification. The documents are mainly the followings
- Device API requirements
- The Widget Interface
- Packaging and Configuration
- Widget URIs
- View Modes Media Feature
- Access Request Policy
- Digital Signatures
- Requirements
- Updates
- The Widget Landscape
The Widget Landscape
The first draft document i selected to read was the Widget landscape http://www.w3.org/TR/2008/WD-widgets-land-20080414/
The following are the items W3C has attempted to point out in this. Overall, this draft is a result of market research on leading widget user agents. The survey exposes the commonalities and fragmentation across various user agents and how fragmentation currently affects among other things, authoring, security, distribution and deployment. The document then concludes by making a set of recommendations on what aspects of widgets require standardization to reduce the fragmentation to ultimately standardize a cross-platform widget solution.
The following are the areas the survey investigates to see how various user agents address these areas
- distribution and deployment
- meta data and configuration
- user interface and accessibility
- authoring
- internationalization and localization
- device independence
- initialization
- automatic updates
- security
Distribution and deployment:
The main issues related to this is the lack of standardization in
- file extension of a widget. Some user agents accept zip file, others accept .widget, .gadget etc.
- It is not mentioned exactly which part of widget specification user agents should support. The compression method chosen need to be standardized.
- The media type of widget is not standardized yet. This makes the widgets transfered over http associated to one widget engine. One media type for widget user agent makes vendor lock in.
Meta Data and Configuration
For almost all types of widgets, the meta data and the configuration file parameters are given below.
The major Meta data elements are
- Root element
- Unique identifier
- version identifier
- description
- copyright
- authorship
The major configuration elements parameters for a widget are
- Bootstrap ( a way to identify the start file)
- network (the need for network access)
- width and height (the initial rendering dimensions)
- plugins (the intention to use plugins)
- Platofrm (minimum version of the widget user agent required to run the widget)
Most of the widget specifications use XML to specify the metadata and configuration parameters. Opera and Apple widgets does not have the file name extension as .xml, instead it is .plist. The vocabulary that defines the semantics and rules for the widget configuration file is proprietary. Due to this the following are the interoperable issues.
- The XML vocabulary is different. Different semantics exist for the widget configuration files.
- The XML parsers are generally non conformant to XML and XMLNS specifications. (Authors currently not required to specify the XMLNS for the configuration document)
Authoring and Scripting
Most of the user agents support the following
- http.
- IRI
- Unicode
- ECMAScript
- DOM
- Ability to render markup languages such as HTML, CSS
- Also support multimedia assets such as images, sound, even video also.
- Due to increase in popularity of Ajax style development, the UAs also support XMLHTTPRrequest or some similar mechanism for asynchronous communication over http.
- Many UA support APIs for authoring and few specific to widgets
The inter operable aspects in Authoring are mainly the below.
- All user agents support XMLHttpRequest
- All but one support HTML & CSS as layout
- There is some limited fragmentation due to the support in some user agents for proprietary technologies such as flash.
Apart from the above, Most of the UAs provide APIs, Events, and properties to the running widgets. Below section gives the comparison of these items across different user agents.
The main API user agents provide to widget is opening a web document in a system browser. Various user agents provide their own API signature for this. some are given below.
Confabulator - openURL
Joost Widgets - navigate(String url)
Also there are other APIs that allows widget to access lower level system commands and open applications.
CommandObject widget.system.execute(String command, [function callbackhandler]);
void widget.openApplication(HexNum Id,String params);
The main properties are widget.version, widget.author,widget.copyright, widget.visible.
The main events given to widgets are widgets.onLoad, widgets.onGainFocus, widgets.onLoseFocus, widgets.onMouseDrag, widget.onUnload etc.
There is one event for Cross communication of widget widget.onTellWidget = function() {} - This could not really understand the syntax of it. Need to update this section
The dockOpen, onDockClosed, onDocOpend, onPreferencesChanged, onRunCommandInBgComplete, onScreenChanged, onWakeUpFromSleep, onWillChangePreferences etc are some other regular events passed on to the widgets.
User Interface and Accessibility
This mainly compares the standards for displaying the content and how user can interact with the content. Except the Google gadgets, the mechanism for displaying the content is HTML, CSS and ECMAScript. For google gadgets, it is propertary XML. Yahoo widget as well uses proprietary XML to represent the data. However it supports HTML, CSS as well.
Instantiation
This section talks about the way the user agent address the resources in the widget to display the initial page of the widgets. Many user agents employ a static file with the name index.htm etc. Apple Dashboard uses tag which specifies the start page.
Internationalization and Localization
Internationalization refers to technical aspects that allow a widget to work in multi lingual environments without making significant engineering changes to a widget. "Localization is the process where by a widget is adapted to use a local convention of particular end users.
One way to do this is to place the locale specific resources inside specifically namesd folders. say en-au. If the user agent can identify the locale and there is matching folder found, the localized widget will be presented to the user.
Another way is to have developers specify the localized strings inside specifically named text file which in turn will be placed inside the specifically named folders. e.g. en-au/Localizable.Strings. Inside the file, the localizable strings are identified by a unique identifier. Say for example, the text file can contain
"greetings" = "g! day mate!"
This can be accessed within the code by the function widget.getLocalizedString("greetings");
