Remove XMLDocument.prototype.load

[domenic]

This is only implemented in Gecko, and is long-deprecated.

@smaug----, any objections? I notice it was deprecated in Gecko in https://bugzilla.mozilla.org/show_bug.cgi?id=494705. I'm happy to file a removal bug.

[smaug----]

oh, yes, we should get rid of the horrible .load.
Does IE support it still? It was originally IEism, I think.

[domenic]

Edge does not.

[domenic]

I think this might also allow us to make XMLDocument an alias of Document, like HTMLDocument is supposedly specced as...

[annevk]

Do we still need XMLDocument if we do this?

[zcorpan]

SELECT page, url
FROM [httparchive:har.2016_06_15_chrome_requests_bodies]
WHERE body CONTAINS "XMLDocument.prototype"

565 matches. So at least it should be an alias, but possibly it needs to stay as separate (if a script adds something to XMLDocument.prototype but expects it to not be present for other documents).

results-20160701-101246.csv.zip

[Ms2ger]

In https://bugzilla.mozilla.org/show_bug.cgi?id=983090, bz mentioned

  xmlDoc = new ActiveXObject("Microsoft.XMLDOM")
  xmlDoc.load(whatever);

Did you test that in IE?

[annevk]

Results in an error in Edge, "'ActiveXObject' is undefined".

[cdumez]

FYI, as far as I know, WebKit does not support this and we do not have plans to support it either.

[bzbarsky]

Note that there is code out there that does browser sniffing and would break in browsers it does not sniff as "WebKit" that don't have document.load. Edge gets away with things because it gets sniffed as "WebKit". See https://www.w3.org/Bugs/Public/show_bug.cgi?id=14037#c10 and relatedly https://www.w3.org/Bugs/Public/show_bug.cgi?id=14037#c14 and I'm so tired of having to repeat this stuff every so often....

[bzbarsky]

And note that the current spec was written precisely in a way that would allow all UAs to implement it and be compatible with known existing content... That's what https://www.w3.org/Bugs/Public/show_bug.cgi?id=14037 was all about.

[domenic]

I guess we could add this to Gecko compatibility mode...

[smaug----]

and I'm so tired of having to repeat this stuff every so often....

Could we add some comments to the spec source code to prevent this kind of issues.
There isn't any good blame for spec source code so it should really be in the source code somewhere.

[domenic]

Yes, I think that adding comments is definitely the correct way to handle this sort of thing.

So Mozilla would prefer we add this back in Gecko compatibility mode? I assume that'd be easier than trying to do telemetry to see if things have changed since 2011.

[bzbarsky]

I'm not sure I have a strong preference for whether this should be added in the compat mode or just as a spec note or something, but I do want the spec to document reality so new engine implementors are not lead astray...

[domenic]

Well, new engine implementers should not implement XMLDocument.prototype.load, so I'm not sure what the issue is there...

[bzbarsky]

Then new engine implementers need to have a UA string that will sniff as "WebKit" by the relevant libraries and need to implement a bunch of webkit-prefixed stuff. Does the spec document that?

[domenic]

That's fair. It sounds like Gecko compatibility mode would be the best place to document this, then.

[cdumez]

If we drop XMLDocument.prototype.load, do we still need XMLDocument? XMLDocument brings nothing beside load().

[annevk]

@cdumez could you comment on whatwg/dom#278 instead? And maybe indicate what the status is in WebKit? It sounds like Gecko needs to keep the distinction around... And developers might have used XMLDocument.prototype...