Document, DocumentFragment, and SVGSVGElement, fwiw.

Right. I should ping www-svg@w3.org to get them to point to our definition.

(In reply to Anne from comment #0)
> jQuery made it web-incompatible.

Could you share some details? Thanks.

jQuery 1.2.5 assumes that any node it found in the DOM that has a "getElementById" property is a Document node.  See https://bugzilla.mozilla.org/show_bug.cgi?id=933193#c17

Er, I meant jQuery 1.2.6, but 1.2.5 in fact has the same code.

Can someone point me to the relevant discussions that lead to the addition of "getElementById" to Element, thanks!

Probably starting at http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jun/0207.html and then going on approximately forever.

This is unfortunate. If it were an issue with a modern version of the library, I'd personally commit to resolving it, but unfortunately a version from 5 years ago requires a time machine and mine is in the shop. 

@mozillians: Is there any way to gather info on jQuery version use in Firefox? I'm willing to do evangelism, on behalf of jQuery, for any major site breakage this change may cause—if there is a way to identify breakage? Can the change be made temporarily? In a Nightly?

I have no idea how realistic this is, but if you asked me to guess, this is pretty close to what I would say the usage is http://w3techs.com/technologies/details/js-jquery/1/all

> @mozillians: Is there any way to gather info on jQuery version use in Firefox?

We can try, but the version is often in neither the url nor the actual script...

Also worth asking the Blink folks if they can do this.

> for any major site breakage this change may cause—if there is a way to identify
> breakage?

That's the problem.  The symptom is that some queries will just return the wrong nodeset.  What happens after that depends on what the site is doing.  And no breakage today is no guarantee of anything tomorrow.  :(

> Can the change be made temporarily? In a Nightly?

We could try; we'd have to disable our jQuery regression tests or something, since those also break with the change (which is how the problem was discovered).  That has its own problems, obviously.

(In reply to Boris Zbarsky from comment #10)
> > @mozillians: Is there any way to gather info on jQuery version use in Firefox?
> 
> We can try, but the version is often in neither the url nor the actual
> script...
> 

jQuery.fn.jQuery is where the version is always exposed, since 1.3 (if it's not present, then "mostly" safe to assume it's pre-1.3)

> Also worth asking the Blink folks if they can do this.

Agreed! 

> 
> > for any major site breakage this change may cause—if there is a way to identify
> > breakage?
> 
> That's the problem.  The symptom is that some queries will just return the
> wrong nodeset.  What happens after that depends on what the site is doing. 
> And no breakage today is no guarantee of anything tomorrow.  :(
> 
> > Can the change be made temporarily? In a Nightly?
> 
> We could try; we'd have to disable our jQuery regression tests or something,
> since those also break with the change (which is how the problem was
> discovered).  That has its own problems, obviously.

Of course and I will understand if this can't happen at all. I will continue to seeking more information about version usage and will post back here.

> jQuery.fn.jQuery is where the version is always exposed

Mmm...  We could try to look for that, but invoking functions of the page when they don't expect to be like that is pretty dangerous from a compat standpoint (and hence there is real infrastructure for doing it, since we never want to do it).  :(

It's a property(In reply to Boris Zbarsky from comment #12)
> > jQuery.fn.jQuery is where the version is always exposed
> 
> Mmm...  We could try to look for that, but invoking functions of the page
> when they don't expect to be like that is pretty dangerous from a compat
> standpoint (and hence there is real infrastructure for doing it, since we
> never want to do it).  :(

It's a property :)

A property get is in general a function call, though.  We don't have a sane way from the non-js-engine part of gecko to do "get this property, but only if it's a value property and if you can determine that without running any script (e.g. none of the objects are proxies)"...  We could try to add a bunch of complex code to do that, I guess...

A couple of ideas about how jQuery could be precisely identified:

1. compare checksums (predefined in browser) of official JS files distributed via jQuery website with checksums of files which URL (or filename) contains "jquery" string (most likely jQuery file is typically used as is -- without modifications);

2. take URLs of jQuery hosted on popular CDN's (e.g. Google's) into account.

(In reply to Marat Tanalin | tanalin.com from comment #15)
> A couple of ideas about how jQuery could be precisely identified:
> 
> 1. compare checksums (predefined in browser) of official JS files
> distributed via jQuery website with checksums of files which URL (or
> filename) contains "jquery" string (most likely jQuery file is typically
> used as is -- without modifications);

For statically scanning the official release of jQuery:

- the minified version string looks like: `f="1.10.2"`
- the source version string looks like: `core_version = "1.10.2"`

But this may appear differently in older versions of jQuery. 

The header of jquery.js and jquery.min.js also include version:

"v1.10.2"

This pattern (ie. "v1.x[.x]" has been the same since jQuery 1.3

> 
> 2. take URLs of jQuery hosted on popular CDN's (e.g. Google's) into account.

Yep, this was #1 on my list to check into :)

Why was getElementById added to ParentNode in the first place?

Erik, see comment 7.

I asked Corey of the jQuery infrastructure team to pull stats on downloads from their code.jquery.com CDN: https://gist.github.com/gnarf/471375415438802390a9. This data is "this month from one of the cdn hosts".

https://github.com/whatwg/dom/commit/f71d7de304e1ee25573279157dd6ce1c2aa2c4f2

(In reply to Anne from comment #20)
> https://github.com/whatwg/dom/commit/f71d7de304e1ee25573279157dd6ce1c2aa2c4f2

Based on the CDN request data the Mike provided above, there were only 6,952 requests for jQuery 1.2.x, out of total 34,201,901 valid requests for jQuery (0.02033%).

By the way, on syntax level, we could just add context element as optional second parameter to existing `document.getElementById()` method so that

    document.getElementById('example', someElement)

would be equivalent to

    someElement.getElementById('example')

Same is probably applicable to DocumentFragment.

Rick, if you can get Chrome to implement it on Element, or manage to change bz' mind for Firefox, I will update the specification. For now I'm happy with moving forward with just adding it to DocumentFragment (and therefore ShadowRoot).

I still don't get it. Why do we want getElementById on Element?

Erik, did you read the mailing list discussion about that exact question?

(In reply to Boris Zbarsky from comment #25)
> Erik, did you read the mailing list discussion about that exact question?

Yes. I didn't find a conclusion to that thread and the arguments were not very convincing. Anyway, please feel free to ignore me.