Somebody will have to usecounter these and we can then determine the path forward based on that data. 

> Somebody will have to usecounter these and we can then determine the path forward based on that data.

Use counter was added in https://codereview.chromium.org/1072403008

Usage is between 0.01% and 0.02%
https://www.chromestatus.com/metrics/feature/timeline/popularity/763

https://drafts.csswg.org/cssom/#the-stylesheetlist-interface has the indexed getters. Simon wanted to see if the item method was used, and it is a bit:
https://www.chromestatus.com/metrics/feature/timeline/popularity/761

This bug is about the named getter at the bottom of our StyleSheetList.idl. That doesn't have a use counter yet.

> This bug is about the named getter at the bottom of our StyleSheetList.idl. That doesn't have a use counter yet.

Isn't that https://www.chromestatus.com/metrics/feature/timeline/popularity/763 ? At 0.01%, how about moving forward with the deprecation + removal plans?

Ah, yes it is, the counter is in StyleSheetList.cpp as opposed to generated code.

I think the next step here would be to check if this named getter is present in other browser engines. Another good thing would be to add a second counter to see how often a non-null value is returned. It's quite possible that it's being tickled by accident and virtually always returning null, which would make it low risk to remove.

> I think the next step here would be to check if this named getter is present in other browser engines.

WebKit's always had a named getter (https://trac.webkit.org/changeset/26509/webkit/trunk/WebCore/css/StyleSheetList.idl, and even before that the manual implementation also had a similar getter), while Gecko's never had one (https://hg.mozilla.org/mozilla-central/file/tip/dom/webidl/StyleSheetList.webidl, or at least since 2014 when their IDL file was created). No idea about Edge.

> Another good thing would be to add a second counter to see how often a non-null value is returned.

I can do that, though I guess it means we'll then have to wait even longer to even consider deprecating and removing the getter :/

If you have a test case ready, I could run it on Edge via BrowserStack.

> WebKit's always had a named getter (https://trac.webkit.org/changeset/26509/webkit/trunk/WebCore/css/StyleSheetList.idl, and even before that the manual implementation also had a similar getter)

Oh, I forgot to mention that there's also a TODO item in their IDL file (https://trac.webkit.org/changeset/210667/webkit/trunk/Source/WebCore/css/StyleSheetList.idl) saying

    // FIXME: https://drafts.csswg.org/cssom/#the-stylesheetlist-interface does not
    // specify a named getter for StyleSheetList. We should investigate removing this.

> If you have a test case ready, I could run it on Edge via BrowserStack.

I've run the attached file on Edge (Edge 38.14393.1066.0, EdgeHTML 14.14393) and apparently it still supports the anonymous named getter.

Deleted: stylesheetlist.html 442 bytes

stylesheetlist.html 442 bytes View Download

Hmm, so Chrome+Edge+Safari is a combination where it's plausible that WebKit-sniffing code could depend on it, so that removing it would break even on sites that currently work in Firefox.

Does the named getter do the same thing in all implementations? Is it something sensible that we could just as well standardize?

I think at this point everyone is mimicking a bad decision made by IE ages ago. Both WebKit and Blink have the same comment in StyleSheetList.cpp:

    // IE also supports retrieving a stylesheet by name, using the name/id of the <style> tag
    // (this is consistent with all the other collections)
    // ### Bad implementation because returns a single element (are IDs always unique?)
    // and doesn't look for name attribute.
    // But unicity of stylesheet ids is good practice anyway ;)

and it works by finding <style> elements with a given id and, if one's found, returning its style sheet. This doesn't look like a behavior that people would like to standardize today.

Does it still make sense to try measuring non-null accesses to the named getter?

Standardizing that would probably not be difficult in terms of the prose to write, but it's a bit icky and it would be good to have better evidence that it's needed first. So yeah, how about adding a counter for the non-null case and awaiting that data before deciding whether to pursue standardization or removal?

(If this was a Blink-only thing then removal based on the lack of interop and the 0.01% usage would look more compelling, but Edge+Chrome+Safari means it's quite possible to depend on this.)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f7a75591a52c88a9bcd24b1d97d14606d9236977

commit f7a75591a52c88a9bcd24b1d97d14606d9236977
Author: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Wed Aug 02 15:26:05 2017

css: Count usages of StyleSheetList's named getter that do not return null.

The anonymous named getter is not part of the spec, and we are trying to
figure out how much it is actually used. The existing counter is triggered
whenever code tries to access a named property, this second counter is
triggered only when a property is found and should give us a better idea of
when named properties are not accessed by accident.

Bug: 689687
Change-Id: I7f255593d2a998a83a62ca60d814751b938db0af
Reviewed-on: https://chromium-review.googlesource.com/596975
Reviewed-by: Eric Willigers <ericwilligers@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Commit-Queue: Raphael Kubo da Costa (rakuco) <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#491378}
[modify] https://crrev.com/f7a75591a52c88a9bcd24b1d97d14606d9236977/third_party/WebKit/Source/core/css/StyleSheetList.cpp
[modify] https://crrev.com/f7a75591a52c88a9bcd24b1d97d14606d9236977/third_party/WebKit/public/platform/web_feature.mojom
[modify] https://crrev.com/f7a75591a52c88a9bcd24b1d97d14606d9236977/tools/metrics/histograms/enums.xml

The counter's been added; how many stable releases do we normally watch before making a decision?

As soon as there's data from the stable channel it's OK. So 1-2 weeks after M62 reaches stable. Setting next action date to Nov 1.

The NextAction date has arrived: 2017-11-01

Usage counter data: https://www.chromestatus.com/metrics/feature/timeline/popularity/2066

Before 2017-10-26 (when the underlying metrics switched to a new collection system), usage was around 0.0005%; after that date, it's around 0.02-0.03%.

Philip/Simon, based on the usage data we've got, what should we do here? Go on the standardization path or start working on an intent to deprecate/remove?

Support in Chrome+Edge+Safari and usage around 0.02-0.03% sounds like too much risk to remove. Agree foolip?

Yes, spec'ing this seems like the better path if it can be defined to do something sensible.

Alright; I'm leaving things as-is for now while the spec work is taken care of.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot