Intent to Deprecate and Remove: Document#selectedStylesheetSet/preferredStylesheetSet

[Chris Nardi]

Primary eng (and PM) emails

cna...@chromium.org

Summary

Document#selectedStylesheetSet/preferredStylesheetSet will be removed with no deprecation period. The tracking bug for this change is https://crbug.com/690609.

Motivation

Document#selectedStylesheetSet/preferredStylesheetSet are non-standard IDL attributes that are only implemented by Chrome and WebKit. The standard versions of these attributes (selectedStyleSheetSet/preferredStyleSheetSet) are only implemented in Firefox, and were removed from the spec in 2016.

Interoperability and Compatibility Risk

UseCounter data for each attribute is relatively low, and per https://crbug.com/690609#c27 and https://crbug.com/690609#c28 the number of sites referencing these attributes appears to be in the single digits. Furthermore, none of the sites found appear to even use the attributes, so no sites should be impacted by this change.

Edge: Not supported

Firefox: Not supported (considering removing the previously-standard attributes in https://bugzilla.mozilla.org/show_bug.cgi?id=1260720)

Safari: Supported, unclear feelings on removal

Alternative implementation suggestion for web developers

Document#styleSheets provides some of the same functionality, but will not cover all use cases of selectedStylesheetSet/preferredStylesheetSet.

https://lists.w3.org/Archives/Public/www-style/2013Aug/0640.html details reasoning for removing the standard attributes from the spec, noting that these features do not appear to be popular.

Usage information from UseCounter

DocumentGetPreferredStylesheetSet (~0.16%) DocumentGetSelectedStylesheetSet (~0.16%) DocumentSetSelectedStylesheetSet (~0%)

Entry on the feature dashboard

https://www.chromestatus.com/feature/6452340664041472

Requesting approval to remove too?

Yes, requesting approval to remove immediately.

[Philip Jägenstedt]

LGTM1. See the crbug comments linked for why the 0.16% numbers do not seem to be match the real risk. It's a very rare thing for this few results to show up in httparchive, so better take the opportunity to remove. There's always some risk of regressions, but if the 0.16% usage is real and not just due to enumeration of document attributes, then it has to be concentrated in a few big sites, which is a good situation to be in too.

[TAMURA, Kent]

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYep25pB8PBkUDjkW%3DxT%2BJcQmHN-qptPVS5Qb3G26RmU%3Dg%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Daniel Bratell]

I find 0.16% a high number. Even if it's only one big site, that is still a lot of page loads and users that could be affected if that site breaks.

A theory in the bug is that 0.16% represents wellsfargo in a script that won't mind if the props disappear, but I lack the context to say if that's a good enough explanation. Wells Fargo is a fairly big bank in a fairly big country, but is that enough to reach 0.16% of the page loads in Chrome?

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqHxn4gmzNsJfULwd1dRtyTX%3DjkHK1baxMZeQVPEEr3M%2Bg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Philip Jägenstedt]

I can't guess how big Wells Fargo in use counter percentage, but 0.16% does seem more than is plausible. Given how little usage we found in httparchive, most plausible to me is that it's accidental use due to iteration in some code paths that aren't run on load and thus don't show up in httparchive.

On https://www.wellsfargocommunity.com/, it definitely looks like the code is creating something like a proxy object for document, and tries to enumerate all attributes. Chris, perhaps you could try using the sites for a bit with the attributes removed to see if you can spot any difference?

Daniel, do you think any additional caution is warranted?

[Daniel Bratell]

The historic usage threshold (which isn't a fixed number but a rule of thumb) for deprecation and removal has been 0.03%. This usage counter is 5 times higher so I think it's prudent to be careful,  especially since the plan is to skip the deprecation phase.

I don't have access to any information that says this is more dangerous than cnardi has stated, but I want to be sure that we have done what we can to ensure we're not shooting someone in the foot. Maybe someone with access to more data than I can either:

1. Verify that the number is explained by wellsfargocommunity's or deltasdenatal's usage

 or

2. Find additional (hopefully harmless) usage that will explain the 0.16%

 or

3. Find a reason to believe the counter is over-counting the actual usage.

I will be easily convinced here but I'm not quite convinced yet.

/Daniel

[Philip Jägenstedt]

It doesn't seem plausible that wellsfargocommunity or deltasdenatal explains the usage, and the remaining options are quite labor-intensive. It would be things like running and instrumented build and visiting lots of big sites looking for a hit.

Rather than asking for that, would a deprecation period help, say 2 release cycles?

[Daniel Bratell]

I've tried to look closer at the data and I think I've found a reason to ignore the number. The curves for the two getters are identical (so identical that I had to verify that they were not the same counter) which could be explained by that you never use one without the other, but more likely it's because they only get triggered by some unintelligent enumeration process and never in an independent fashion.

So maybe this is the baseline for enumerations in which case enumerations are steadily increasing. It's also unlikely that the usage of this feature would increase so the increase also supports the enumeration theory.

So, thanks for following me through the process:

LGTM3 to remove (with or without a deprecation phase).

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYc_YV0gB-AGSD1UcSqyL_UwPeP%3D0VGE9G5epm18E6V8Ww%40mail.gmail.com.

[Philip Jägenstedt]

That's really cool, a good observation! I'll keep this in my back pocket for any future removals on document.

[Rune Lillesveen]

Does that mean it won't be possible to select alternate stylesheets in Chrome anymore?

I haven't investigated, but MDN says Firefox and IE has a UI for that and that Chrome requires an extension [1]. Are such extensions utilizing this API?

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Alternative_style_sheets

On Mon, May 7, 2018 at 6:21 PM Chris Nardi <cna...@chromium.org> wrote:

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXZydcj7YEs8xzPHpS1AbxGZwL6YhtLN4BBaotdn8h%3DB_TfXQ%40mail.gmail.com.

--

Rune Lillesveen

[Rune Lillesveen]

On Thu, May 10, 2018 at 12:04 PM Rune Lillesveen <fut...@chromium.org> wrote:

Does that mean it won't be possible to select alternate stylesheets in Chrome anymore?

I see now from the code that the selectedStylesheetSet did not have any effect on the applied styles. Then I wonder how such extensions work ...

--

Rune Lillesveen

[Harald Alvestrand]

Should there be a counter for "property-only-visible-in-enumeration", so that this baseline is explicitly measured?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYf3ahRPCYMv_sJeu1reSLKd6M6B%2BUOb%2B_iK1h3%3DCoBX0g%40mail.gmail.com.

[Philip Jägenstedt]

That would be great, but would require actually exposing a dummy property. One could measure (in V8?) when enumeration happens, but that's one step short of also getting the attributes's value.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOqqYVFayjrTeTFWrAmzzx8tmRHjtP1nsMj5h3fRK7xh_e9dCg%40mail.gmail.com.