[widgets] Purpose and utility of <feature> unclear

Regarding http://dev.w3.org/2006/waf/widgets/#the-feature-element

I don't understand the purpose and utility of the <feature> element.

> Using a feature element denotes that, at runtime, a widget may  
> attempt to access the feature identified by the feature element's  
> name attribute.

Why is this useful to denote? What happens if a widget doesn't denote  
that it'll attempt to use a feature but does so anyway?

> Using a feature element denotes that, at runtime, a widget may  
> attempt to access the feature identified by the feature element's  
> name attribute.


Why aren't all the implemented features simply available like in a Web  
browser engine?

> A user agent can expose a feature through, for example, an API, in  
> which case a user agents that supports the [Widgets-APIs]  
> specification can allow authors to check if a feature loaded via the  
> hasFeature() method.

Wouldn't this have all the same problems that DOM hasFeature() has had  
previously and the problems that have been pointed out as reasons not  
to have feature detection at-rules in CSS? Namely, that  
implementations have the incentive to claim that they have a feature  
as soon as they have a partial buggy implementation.

> A boolean attribute that indicates whether or not this feature must  
> be available to the widget at runtime. In other words, the required  
> attribute denotes that a feature is absolutely needed by the widget  
> to function correctly, and without the availability of this feature  
> the widget serves no useful purpose or won't execute properly.

What's a widget engine expected to do when an unrecognized feature is  
declared as required?

> <feature name="http://example.org/api.geolocation" required="false"/>


Suppose a WG creates a feature for the Web, the feature is not part of  
the Widgets 1.0 Family of specs and the WG doesn't assign a feature  
string for the feature because the WG doesn't consider widgets. Next,  
suppose browser engines implement the feature making it  
unconditionally available to Web content.

Now, if such a browser engine is also a widget engine, does it make  
the feature's availability on the widget side conditional to importing  
it with <feature>? If it does, what's the point of not making the  
feature available unconditionally? If it doesn't, what's the point of  
<feature>?

If there are two such engines, how do they converge on the same  
feature name string of the specifiers of the feature itself just meant  
it to be available to Web content unconditionally and didn't bother to  
mint a widget feature string?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 1 June 2009 11:25:58 UTC