On Jun 1, 2009, at 16:44, Marcos Caceres wrote:
On Mon, Jun 1, 2009 at 1:25 PM, Henri Sivonen <[email protected]> wrote:
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?
Then it will fail as the feature will not have loaded. Feature loading
has to be explicit (unless the feature is enabled by default, as might
become the case eventually with, say, Geo-location).
In general, this policy seems alien to browser technologies.
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?
Feature is for proprietary extensions: BONDI makes extensive use of
this element. There are also security considerations: Members of the
WG have asked why would you want the contacts API, for example, to be
enabled by default? if you don't enable it and make it available, then
malicious injected code cannot access those APIs. In widgets, the
security model that we are discussing is one where APIs are made
available on request only... or till implementers consider them benign
enough to allow them in the wild (e.g., XHR).
I think it would be preferable to design APIs in such a way that
security/privacy aspects of the API are Web-ready, i.e. the same API
could be exposed to Web content. (I consider the design of the
Geolocation API and it's authorization UI in Firefox Web-ready in this
sense.)
Failing that, I now see the point of the security aspect of the
<feature> design. However, for that case, I think the default policy
for upcoming features of the platform (feature unavailable unless part
of Widgets 1.0 Family) is backwards if the widget platform is viewed
as a an extension to the browser platform that keeps up with the
evolution of the browser platform as opposed to being a one-time fork
of the browser platform.
It seems to me it would be better to allow features with a Web-ready
security model to be made available by default and require widget-
oriented feature specs that lack a Web-exposable security model opt in
to the <feature> security model.
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
Excuse my ignorance, but I don't know what those problems are. Can you
please give us a pointer?
Implementations have an incentive to claim to have a feature when they
have only partial support. OTOH, when implementors try to do the Right
Thing and resist the temptation, partial implementations will report
false even though the script in question could have worked with only
the part of the implementation that exists. Also, actual feature
implementation status and what hasFeature reports may be out of sync
just by omission.
javascript:alert(document.implementation.hasFeature("Selectors-API",
"1.0")), for example, says false to me on Firefox trunk.
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.
Ok, I see; that is bad. Can you recommend what we should do instead?
Scripts should try to use a given API and whine to the user or perform
workarounds if the API is missing.
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?
Ah, good point! I had not completely specified that in the processing
part of the spec. It now reads:
"If feature-name is not a valid URI, and required-feature is true,
then treat this widget as an invalid widget package.
If feature-name is not supported by the user agent, and
required-feature is true, then treat this widget as an invalid widget
package.
If feature-name is not supported by the user agent, and
required-feature is false, then this element, its attributes, and its
children are in error and must be ignored. Stop processing this
element and proceed to the next element in the elements list."
Thanks. That makes it clearer what <feature> is about.
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?
Like I said, feature was originally intended to request access to
proprietary features designed for widgets (namely BONDI). If the API
just becomes available in the browser, then no feature string is
needed. But yes, we have a potential problem here until we settle on
the security model.
It seems to me this issue is solved by making only widget-oriented
(BONDI) features participate in the <feature> model and making Web-
oriented features (like Geolocation) not participate (i.e. work like
they work in a browser).
--
Henri Sivonen
[email protected]
http://hsivonen.iki.fi/
