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

+ian since this wording is actually in the HTML spec.

I'm not sure how exactly this should be specced. DOM4 could specify the two
interfaces and HTML could use those definitions?

On Mon, Nov 21, 2011 at 7:05 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.


Hmmm. I wasn't thinking of expandos. We'll definitely need to keep
supportting that. :(


>  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?


The fewer properties that are exposed this way, the smaller the quirk is. I
was hoping that we could have a fixed small list of properties that the
spec says are exposed. Maybe that's too ambitious and doesn't actually buy
us much though.


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