Published: Wednesday, Nov 18, 2009 Last modified: Monday, Apr 8, 2024

Update: Marcos has replied to all my concerns

This late rant is prompted by Widget interface spec (Last Call).

Widget APIs or rather Widgets 1.0: The widget Interface is largely about exposing what’s defined in the widget configuration document to the Widget developer.

WHY? You may rightly ask. The widget developer should know his own name and email address whilst writing a function to mail him a bug report. I guess someone has argued that slapping new widget. attributes makes it easier for library developers. BONDI incidentally rightly (imo), didn’t bother with this mapping.

Another reason WHY pointed out by robin is that the simple Widget interface exposed by the widget runtime, would implement locale support and give you the localised interface. I.e. it’s doing a bit of work behind the scenes for the convenience of Widget developers and well… non-English speakers. However again, one can argue that Widget developers can implement their own locale support, which isn’t that hard (they have probably done it before), but it would probably suck.

Ok, in an example Widget configuration file, like config.xml, you might find:

<widget xmlns="" id="" version="0.4.2" viewmodes="fullscreen">

Which maps onto the Widget interface as: = "";
widget.version = "0.4.2";

Though what about viewmodes? Hmm…


<name short="WebC">Web Commander</name>

Maps as: = "Web Commander";
widget.shortName = "WebC";

Ok, the attribute short was used as a prefix to name which has become capitialised in order to make it easier to distinguish. Ok, fine. However this is there is an inconsistency with:

<author href="" email="">LiMo Foundation</author>

Maps to the Widget interface like so: = "LiMo Foundation";
widget.authorEmail = "";
widget.authorHref = "";

Now the author element attributes like email and href become suffixed to author. You see how `shortName, should be nameShort?

Other elements can be found on the config.xml such as:

  <feature name="" required="true"/>
  <license href=""/>
  <content src="index.html"/>
  <feature name="" required="true"/>
  <feature name="" required="true"/>

However there is no mapping to the Widget interface. Who decides what gets mapped and what doesn’t? Wouldn’t it be simpler and more consistent to just map everything?

It does get tricky especially thinking about the possible multiply nested

Also some punks might overload the config.xml with openURL which would clash.

I understand some elements like the feature elements and undefined (proprietary) elements like:

<access network="false" localfs="false" remote_scripts="false"/>
<billing required="true"/>

..are perhaps only relevant and used by particular runtimes, though shouldn’t there be convention and reasoning for why (and why not) certain interfaces are exposed in the widget interface specification?

If the was mandatory, which I think it should be since many widgets I’ve come across rely on setPreferenceForKey and preferenceForKey conventions, wouldn’t it be sensible to put the interfaces all into this preference Web storage mechanism?

Consider read-only keys like:


Though perhaps ideally when you did a widget.getItem, you received the JSON representation of the XML fragment. Though I’m not entirely sure if there is a standard way to map XML onto JSON. You might as well canonicalise the whole config.xml as a JSON string bound to widget.config. There, simple. Or innerXML if a JSON translation isn’t possible.

Btw the Widget interface as it stands are all readonly except for preferences and openURL.


It’s unclear to me if width and height map to the config.xml or the real actual viewport size. Surely one can defer to window.screen.width and window.screen.height instead? I know it says screen, but just imagine it says viewport?

My final proposal Widget interface proposal after thinking about it for two hours

interface Widget {
	readonly attribute DOMString     config; // innerXML or rather JSON representation of configuration document
	readonly attribute Storage       preferences; // key value
	void openURL(in DOMString iri);