Make Attr a Node again (referencing whatwg/dom#102)

[DigiTec]

In issue whatwg#102 we are discussing the ramifications of making Attr not derive from Node and what APIs would need to be added to make this stable.

Here is 14 days of sampled profiler data which we are working on expanding:

[DigiTec]

@foolip Here is an initial start on the data collection for Attr.

The fact that we some very low counts tells me we need data from a longer period of time.

[foolip]

That's awesome, @DigiTec!

Can these numbers be interpreted relative to something? Perhaps as a first approximation we could say that nodeValue is 23606=0.5% of page views in accordance with https://www.chromestatus.com/metrics/feature/timeline/popularity/348?

Of the things not already on Attr, it looks like the top ones are childNodes at 135, compareDocumentPosition at 104 and firstChild at 50. Assuming 23606=0.5%, that's in the 0.01-0.02% range. For things that could start to throw exceptions and break pages completely, that's still a bit high for comfort, or how would you interpret the numbers?

[ArkadiuszMichalski]

@DigiTec Any data for Node.nodeName? It was added to Attr due to high usage (whatwg#171).

[DigiTec]

Adding more data for @foolip and thank you for drilling in and teasing out problems!

There were 125 million samples in this range, so all of the numbers can be scaled by that to determine usage. We don't have a session breakdown at this time unfortunately.
Attr had a little less than 30k of those samples

Attr itself is 0.00024% of all API usage.

Even the numbers in the 100's range are pretty much "unused" and sparsely seen. Maybe by looking at some other datasets we could draw some stronger conclusions. And I could certainly try more telemetry if that would help.

Bug in my data

Thanks to @ArkadiuszMichalski for pointing out nodeName/nodeType. We have no data for these APIs because they are directly memory mapped properties and don't go through our telemetry pipeline. It would be a detriment to performance of these APIs to do so.

The only usage for nodeName/nodeType is when you are squashing Attr in with other nodes and you are using it to disambiguate. Maybe for XPath like scenarios? But it is a blind spot and it could be heavily used. I believe we had data which stated nodeName/nodeType were the top two most widely used APIs by call count on the web before we lost our ability to measure them. With only window and document coming anywhere close in equivalent usage.

[foolip]

Hmm, scaling by 125 million, nodeValue usage would be ~0.02%, which is quite far from the ~0.5% we see in https://www.chromestatus.com/metrics/feature/timeline/popularity/348

Some differences due to the different methodologies are of course expected, but that's off by a factor of ~25.

Have you used this type of data when making other changes, so that you already have an idea about a cut-off for where you'd be willing to make changes?

[DigiTec]

@foolip We have not used the methodology that produced this specific data to make a decision as hefty as what we are making. Off by a factor of 25 is not unreasonable. chromestatus is based on sessions. The longer the session the more likely a single instance of the API is to show up. Whereas with profiled data it isn't about sessions, but hits. If it turns out this API is mainly used as a feature detect of some sort, then it would be high session count, but low hit count. I think that is what we are seeing here.

We actually have had APIs before that as a group show up at precisely the same rates, upon inspection we found that some libraries were simply enumerating all of the properties on an object to make a copy of it. It will be hard to differentiate these states without drilling into the sites.

If we want session based data please let me know and I can try to land something like that before we ship the anniversary update. Just need to know what APIs, specifically, we want more data on.

[foolip]

@DigiTec Those are good points about session vs. simply counting hits. From your data the biggest risks seem to be childNodes at 135, compareDocumentPosition at 104 and firstChild at 50. Is it correct to say that you'd be comfortable attempting to align with the spec based on these numbers, or is there some change you think would make it safer and thus more likely to work out?

[ArkadiuszMichalski]

What Edge does for Attr.childNodes and Attr.firstChild? This is from actual Firefox and Chrome:

<script>
    var attr = document.createAttribute("id");
    attr.value = "test";
    console.log(attr.childNodes); // [object NodeList]
    console.log(attr.childNodes.length); // 0
    console.log(attr.firstChild); // null
</script>

Edit: still supports child for attr.

NodeList
1
test 

[yongsheng]

will address this in 4.1.

[yongsheng]

Below is the change in whatwg dom:

• whatwg@f64b0c8 Put Attr.prototype.ownerElement back; give Attr.prototype.value a setter and an alias named textContent

[zqzhang]

Also consider this change:

• whatwg@0e17e05 Further Attr node fixes for compareDocumentPosition()