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

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.

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.

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

It's a nasty wart to put on the platform, but it's better than being unable
to expose APIs with good names or with exposing APIs with good names and
breaking existing content.

Ojan

On Mon, Nov 21, 2011 at 6:00 PM, Aryeh Gregor <ayg@aryeh.name> wrote:

> On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
> > You're not misunderstanding, but you're wrong.  ^_^  The element
> > itself is put in the lookup chain before document.  See this testcase:
> >
> > <!DOCTYPE html>
> > <button onclick="alert(namespaceURI)">foo</button>
> >
> > (namespaceURI was the first property I could think of that's on
> > Element but not Document.)
>
> Awesome.  It seems on* is even more pathological than I realized.  So
> definitely, I don't think we want to avoid adding short names to Node
> or Element or Document forever just because of this.  If the cost is
> making bare name lookup in on* slightly more pathological than it
> already is, I don't think that's a big deal.  Authors who want to
> preserve their sanity should already be prefixing everything with
> "window." or "document." or whatever is appropriate.  Let's add
> .matches() and just make it not triggered as a bare name from on*.
>
>

Received on Tuesday, 22 November 2011 02:59:23 UTC