W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

From: Anne van Kesteren <annevk@annevk.nl>
Date: Fri, 18 Jan 2013 11:35:04 +0100
Message-ID: <CADnb78h47SYu6GsRpO1swoXAJfYP7PGNRy6bqfooH=BWXPx+HQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Vincent Scheib <scheib@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, Tantek Çelik <tantek@cs.stanford.edu>, Webapps WG <public-webapps@w3.org>
On Fri, Jan 18, 2013 at 4:34 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Jan 10, 2013 at 1:28 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> I think HTML should maintain the registry and policy for on*
>> attributes insofar they concern Window/Document/HTMLElement objects.
>> http://fullscreen.spec.whatwg.org/ only fires on Document, fwiw.
> That doesn't seem either scalable or documentation/implementation
> friendly. It means that someone reading the X feature spec (to
> implement it, to use it or to review it) will have to also go look at
> the HTML spec. And know that he/she needs to do so. And it means that
> the development of the X feature spec is blocked on getting the
> attention of the HTML spec authors.

Well the other perspective is that someone looking to refactor event
handlers (as has happened in e.g. Gecko in recent history) has just
one place to look through. Currently HTML defines the allowfullscreen
attribute too and how it interacts with the various other sandboxing
features. Untangling that cleanly is hard and I do not think there is
an obvious right way to do it.

> Isn't this the reason we adding "partial interface" to WebIDL?

One of the main reasons I recall was separating obsoleted features
from non-obsoleted features in HTML. It is of course useful as well
for self-contained extensions drafted elsewhere. I'm not sure that
though that all the splintering is useful long term as you lose track
of what is going on.

Received on Friday, 18 January 2013 10:35:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC