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

On Tue, Nov 22, 2011 at 10:24 AM, Ojan Vafai <ojan@chromium.org> wrote:
> On Tue, Nov 22, 2011 at 10:04 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>>
>> On 11/22/11 12:57 PM, Ojan Vafai wrote:
>>>
>>> The fewer properties that are exposed this way, the smaller the quirk
>>> is.
>>
>> I think the problem is that from web developers point of view the quirky
>> behavior is _not_ exposing properties.  Certainly in the short term...
>
> That's true for a large percentage of developers for sure, but most web
> developers I've talked to about this are surprised to learn about this
> behavior and have never (intentionally) depended on it.
>
>>
>> In the long term, since we have to expose all expandos, I suspect that not
>> exposing properties will continue to be seen as the quirky behavior.
>>
>> Note, by the way, that having to expose expandos (including expandos on
>> prototypes) but not new built-in properties might make for some fun
>> spec-work (e.g., what happens when the standard adds a property but then
>> some page overrides it on the prototype with a different property
>> definition: should the page-defined value be exposed?).
>>
>> Again, some decent data on what pages actually do in on* handlers would be
>> really good.  I have no idea how to get it.  :(
>
> I've been trying to get some data on this, but I haven't had much success.
> I'll report back if I do. But even if I get data, it'll be for specific
> names, not a generic "what do pages do in on* handlers", so it wouldn't
> actually help resolving this expando question.
>>>
>>> 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.
>>
>> Given the expando situation, I'm not sure that approach works at all.  :(
>
> Well, it would be a small list + expandos. :)

This is a feature that is definitely causing severe pain to the
platform since it's putting constraints on APIs that we can add to our
main data model, the DOM.

It would be really awesome if we could figure out a way to fix this.
I'd say the first step would be to evaluate if we actually need
expandos. And be prepared to break a few pages by removing support for
them. If we can agree to do that, then it's likely that we can create
a small object which forwards a short list of properties to the <form>
element (likely including the dynamic list of form element names) and
only put that object in scope.

/ Jonas

Received on Wednesday, 23 November 2011 00:13:50 UTC