Re: Straw-poll: hanging the device API

On Wed, 07 Oct 2009 18:28:11 +0200, Ian Hickson <> wrote:
> On Wed, 7 Oct 2009, Robin Berjon wrote:
>> Option A: window.navigator.device
>> Option B: window.device
> I don't think it's possible to make a single decision. Assuming these  
> APIs are intended for use on the broad Web (which isn't entirely clear  
> to me),
> we are likely to be constrained in all kinds of ways, e.g. it may be that
> window.device clashes with a script on or and we
> can't use that identifier, or it may be that we need a constructor and so
> we need an interface at the global scope level, or it may be that some  
> API ends up needing an API more like the document constructor methods,  
> or it
> may be that some API is related so tightly to an element that we actually
> should hang it off the element and not one of the global singleton
> objects.
> It also depends a lot on the security model we want to use. If it turns
> out that we want a security model based on the user dragging and dropping
> a permission onto the page, maybe we need to hang the API off a drag-and-
> drop event's Event object. It also depends on the locking model we want  
> to use, since that affects whether the API will be visible on Workers,  
> which
> affects whether we should put the API on the Navigator object or the
> global scope, or whether to be inconsistent across both.
> In conclusion, I think that where the API is exposed is probably the last
> question that can be answered. We first need to determine what the API's
> security model is, what it's locking model is, what it's threading model
> is, what the API itself is, and so on. Then, the question of where to put
> the API mostly solves itself.


Anne van Kesteren

Received on Thursday, 8 October 2009 08:54:34 UTC