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


>
>
> -Boris
>
>