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

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 21 Nov 2011 17:54:24 -0800
Message-ID: <CAAWBYDDdc_icyhn1o1ZLOUc9JVh2yVeLR287M6QRN9ohqacR+w@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Mon, Nov 21, 2011 at 5:31 PM, Aryeh Gregor <ayg@aryeh.name> wrote:
> On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>> The sticking point here is obviously item #2.  Data needed on use of
>> "matches" and "is" as barewords in on* attributes, specifically.
> I don't follow.  matchesSelector is on Element, not Node, right?  Why
> is it relevant to on* attributes?  The lookup chain is first document
> then window, with no elements anywhere, right?  Or am I
> misunderstanding you?  I see why new proposed methods on Node like
> .prepend could be an issue (although we could leave most of those off
> Document too, as noted).
> If this is a recurring problem, could we consider implementing magic
> so that new methods on Document (or Node) that might cause problems
> are ignored in on* unless you prefix with "document."?  So generally a
> bare name will check for variables on the document first and then the
> window, but for the magic blacklist ("matches", "is", whatever causes
> problems) it will only check the window.  Obviously this is not a
> great solution -- but I'd really hate us to lose out on the ideal
> names for common methods just because of a tiny number of sites using
> on*.
> It's possible that I'm just completely not understanding what you mean
> here, though.

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

I would also *love* if it we could mitigate this in the future by
requiring you to use document.* or this.* to access new stuff on the
document or element, so we could stop worrying about this sort of
conflict.  We'd just have to define the handful of legacy properties
from before this change that can still be accessed as barewords, and
possibly all expandos (investigation is needed).

Received on Tuesday, 22 November 2011 01:55:19 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC