W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Mon, 21 Nov 2011 22:05:54 -0500
Message-ID: <4ECB1192.8050406@mit.edu>
To: Ojan Vafai <ojan@chromium.org>
CC: Aryeh Gregor <ayg@aryeh.name>, "Tab Atkins Jr." <jackalmage@gmail.com>, public-webapps@w3.org
On 11/21/11 9:58 PM, Ojan Vafai wrote:
> I think this is the only sane solution to this problem. Lets split up
> the Element interface. I'm not attached to these names, but something
> like ElementExposed and Element. Element inherits (mixins?)
> ElementExposed and only the methods on ElementExposed are exposed to the
> on* lookup chain.

This is somwhat backwards.  In particular, expandos almost certainly 
need to be exposed on the on* lookup chain for backwards compat.  So 
more precisely, only the properties and methods that are NOT on 
ElementExposed (nor on any other DOM APIs elements implement at the 
moment) are missing from the on* lookup chain.  I agree that all new 
methods and properties we add should go in this set.  How to structure 
this in spec terms is a good question.

> ElementExposed would have everything that is currently on the Element
> API and all new methods would go on Element. You could imagine that over
> time we could figure out the minimal set of APIs required by web compat
> to leave on ElementExposed and move everything else to Element.

This exercise doesn't seem to be worthwhile.  What would be the benefit?

> In fact, we should do this for form and document as well.

Yes.

-Boris
Received on Tuesday, 22 November 2011 03:06:23 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT