xmlEncoding: https://www.chromestatus.com/metrics/feature/timeline/popularity/115
xmlStandalone: https://www.chromestatus.com/metrics/feature/timeline/popularity/116
xmlVersion: https://www.chromestatus.com/metrics/feature/timeline/popularity/117

It would probably be web compatible to remove these. On the other hand, they are just string properties, so I'm not sure there's a tremendous benefit to removing them.

I assume that these are all actually still in all implementations, so I think what we should probably revive this in the spec instead. (The linked issue 674593 is to standardize or remove non-spec'd things, with no a priori preference either way.)

Firefox does not appear to implement any of these 3 properties.

Chrome, Safari, and Edge do implement them.
Although Edge returns empty strings for xmlEncoding and xmlVersion, whereas Chrome+Safari return null for those.

My preference would be to remove these:
- It would reduce cognitive load, for example when developers write document. in DevTools console, etc.
- They're not useful, it's a useless constant value.
- It's probably web compatible to remove them because they return different falsy values, removing them would also be falsy (undefined), and FF doesn't have them anyway.
- It would make the product marginally smaller.

On the other hand, this may not meet the bar for Blink removals these days because compatibility doesn't immediately get better by removing them, and there's no security benefit to removing them.

Rick, Foolip, WDYT?

It would be interesting if Edge gave them string values for a reason.

Ff other vendors are also still interested in eventual removal and if somebody does the necessary httparchive research to figure out what the impact of this would be, then removal could still be the best outcome. There mere fact that these are ancient APIs and supported everywhere should raise the bar for removal somewhat, but not rule it out entirely.

These attributes return null/false in HTML documents, but for example document.implementation.createDocument(null,'').xmlVersion is "1.0". The main risk is probably with these properties being used as a kind of "is this XHTML" check, but checking httparchive would reveal that.

Yes, good point--it's 1.0 in non-blink::HTMLDocument instances.

Rough cut:

SELECT SUM(xmlversion), SUM(xmlencoding), SUM(xmlstandalone), SUM(all)
FROM (
  SELECT
    body CONTAINS '.xmlVersion' AS xmlversion,
    body CONTAINS '.xmlEncoding' AS xmlencoding,
    body CONTAINS '.xmlStandalone' AS xmlstandalone,
    1 AS all
  FROM [httparchive:har.2016_05_15_chrome_requests_bodies]
)

xmlVersion = 0.06%
xmlEncoding = 0.005%
xmlStandalone = 0.002%

Ah. Ironically, https://www.w3.org/TR/xhtml1/ is apparently not considered X(HT)ML, so my testing was flawed.
https://www.w3.org/2000/07/8378/schemas/xhtml1-sample.xml would be a proper testcase.

I looked at 90% of the xmlVersion instances and yes, they're basically type tests for XMLDocument.

There's a smattering (~500) false positives of things called xmlVersion.

Did you find a case where it looks like the breakage would be bad, like where taking the wrong branch would cause us to try to call methods that don't exist or something similar?

Hard to say, I just looked at snippets of the surrounding 50 characters. Some of them are minimized helper functions so it would need more digging to see what's calling them.

Filling out my form from https://docs.google.com/document/d/1LSuLWJDP02rlC9bOlidL6DzBV5kSkV5bW5Pled8HGC8/edit?usp=sharing:

Tests: https://jsbin.com/xaquni/edit?html,output
Implemented in: Blink, EdgeHTML, WebKit (not Gecko)
Standard: https://dom.spec.whatwg.org/#interface-document

xmlEncoding was once in Gecko but was removed in 2011:
https://bugzilla.mozilla.org/show_bug.cgi?id=687426

The other two properties I couldn't find Bugzilla bugs for.

The "algorithm" in my doc would suggest httparchive analysis at this point, due to the generic risk that Blink+EdgeHTML+WebKit APIs may be used for UA sniffing and cause trouble if added to Gecko. But that's actually not a concern here because there are ancient APIs, not something originally introduced by WebKit.

Because Ms2ger went through the trouble+risk of removing xmlEncoding from Gecko, I think we should try to follow rather than standardizing again. So, next step here would be to look for things that would break in httparchive and then just try it.

Bulk disowning per sshruthi's email about bug triage best practices.