Intent to Implement and Ship: Update the behavior of the "disabled" attribute for HTMLLinkElement

158 views
Skip to first unread message

Mason Freed

unread,
May 27, 2020, 8:20:27 PM5/27/20
to blink-dev
mason...@chromium.org https://github.com/whatwg/html/issues/3840 Specification: https://github.com/whatwg/html/pull/4519 Very small change, TAG review not needed Previously, Chromium had intermittent behavior with respect to the "disabled" attribute: - <link id=foo rel="stylesheet" disabled> would not show up in document.styleSheets. - foo.disabled=false; foo.disabled=true; would cause it to appear (and remain) in document.styleSheets. - <link rel="alternate stylesheet"> cannot be enabled, except by disabling and re-enabling it. - When disabled, link.ownerNode was not null The above issues are being resolved with this I2S. The behavior of <link disabled> was not very interoperable, and not well specified. With this HTML spec PR (https://github.com/whatwg/html/pull/4519) the behavior has been more completely specified. Chrome will implement this modified behavior starting in M85. See https://github.com/whatwg/html/issues/3840 for more details and conversation.
As discussed on the spec issue, the current situation is quite non-interoperable. The implementations all do slightly different things with the disabled attribute, and the spec text is vague. For this reason, the compat risk should be relatively lower, though still non-zero. It is possible that sites may be relying on the existing Chromium behavior, and this change may break those sites by either applying or not applying styles, or by changing the length of document.styleSheets when not expected. The overall use counter for <link disabled> is around 0.2%, but only a fraction of that should be affected by the particular behavior being changed here. The conclusion on the issue thread was that the change should not be too incompatible. Firefox already implements the new behavior. https://www.chromestatus.com/metrics/feature/timeline/popularity/809 Firefox: Shipped (https://github.com/whatwg/html/issues/3840#issuecomment-634272725) Edge: No public signals Safari: No public signals (https://lists.webkit.org/pipermail/webkit-dev/2020-May/031223.html) Web developers: No signals This makes the behavior of <link> and 'disabled' more sane and tractable, and reduces interop differences. So this should be a net win. N/A N/A
This should be fully debuggable. Yes Yes https://wpt.fyi/results/css/cssom?label=master&label=experimental&aligned&q=htmllinkelement-disabled https://crbug.com/1087043 https://github.com/whatwg/html/issues/3840#issue-343413388 https://chromestatus.com/feature/5110851973414912
This intent message was generated by Chrome Platform Status.

Yoav Weiss

unread,
May 28, 2020, 7:43:43 AM5/28/20
to Mason Freed, blink-dev
LGTM

On Thu, May 28, 2020 at 2:20 AM Mason Freed <mason...@chromium.org> wrote:
mason...@chromium.org https://github.com/whatwg/html/issues/3840 Specification: https://github.com/whatwg/html/pull/4519 Very small change, TAG review not needed Previously, Chromium had intermittent behavior with respect to the "disabled" attribute: - <link id=foo rel="stylesheet" disabled> would not show up in document.styleSheets. - foo.disabled=false; foo.disabled=true; would cause it to appear (and remain) in document.styleSheets. - <link rel="alternate stylesheet"> cannot be enabled, except by disabling and re-enabling it. - When disabled, link.ownerNode was not null

This just concerns style rels, right?
Are you aware of similar issues around the disabled attribute and other rels? Non-blocking for this intent, I'm just curious...

The above issues are being resolved with this I2S. The behavior of <link disabled> was not very interoperable, and not well specified. With this HTML spec PR (https://github.com/whatwg/html/pull/4519) the behavior has been more completely specified. Chrome will implement this modified behavior starting in M85. See https://github.com/whatwg/html/issues/3840 for more details and conversation.
As discussed on the spec issue, the current situation is quite non-interoperable. The implementations all do slightly different things with the disabled attribute, and the spec text is vague. For this reason, the compat risk should be relatively lower, though still non-zero. It is possible that sites may be relying on the existing Chromium behavior, and this change may break those sites by either applying or not applying styles, or by changing the length of document.styleSheets when not expected. The overall use counter for <link disabled> is around 0.2%, but only a fraction of that should be affected by the particular behavior being changed here. The conclusion on the issue thread was that the change should not be too incompatible. Firefox already implements the new behavior. https://www.chromestatus.com/metrics/feature/timeline/popularity/809 Firefox: Shipped (https://github.com/whatwg/html/issues/3840#issuecomment-634272725) Edge: No public signals Safari: No public signals (https://lists.webkit.org/pipermail/webkit-dev/2020-May/031223.html) Web developers: No signals This makes the behavior of <link> and 'disabled' more sane and tractable, and reduces interop differences. So this should be a net win. N/A N/A
This should be fully debuggable. Yes Yes https://wpt.fyi/results/css/cssom?label=master&label=experimental&aligned&q=htmllinkelement-disabled https://crbug.com/1087043 https://github.com/whatwg/html/issues/3840#issue-343413388 https://chromestatus.com/feature/5110851973414912
This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
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/CAM%3DNeDjjUUnO_WiZc6D%3DrD66H3saVztYMf7pLtiT%2B54h55gYBw%40mail.gmail.com.

Mason Freed

unread,
May 28, 2020, 12:43:30 PM5/28/20
to Yoav Weiss, blink-dev

This just concerns style rels, right?
Are you aware of similar issues around the disabled attribute and other rels? Non-blocking for this intent, I'm just curious...

Thanks for the LGTM! And yes, this is just for stylesheet links only. I am not aware of something similar for non-style rels - do you know of particular issues? There is this bug, which discusses HTMLStyleElement and SVGStyleElement, but that's the only other related bug on my radar.

Chris Harrelson

unread,
May 28, 2020, 3:13:00 PM5/28/20
to Mason Freed, Yoav Weiss, blink-dev
LGTM2, but could you put this behavior behind a flag in case we encounter compat problems?

sligh...@chromium.org

unread,
May 28, 2020, 3:21:43 PM5/28/20
to blink-dev, mason...@chromium.org, yo...@yoav.ws, Alice Boxhall
LGTM3, however, a question:

It seems to me that this should at least justify an FYI to the TAG. If there's a larger project to do here regarding the `disabled` attribute behaving consistently across elements, that's something they can weigh in on and, if they support, can help drive.

+aboxhall for the TAG perspective

Regards

On Thursday, May 28, 2020 at 12:13:00 PM UTC-7, Chris Harrelson wrote:
LGTM2, but could you put this behavior behind a flag in case we encounter compat problems?

On Thu, May 28, 2020 at 9:43 AM Mason Freed <mason...@chromium.org> wrote:

This just concerns style rels, right?
Are you aware of similar issues around the disabled attribute and other rels? Non-blocking for this intent, I'm just curious...

Thanks for the LGTM! And yes, this is just for stylesheet links only. I am not aware of something similar for non-style rels - do you know of particular issues? There is this bug, which discusses HTMLStyleElement and SVGStyleElement, but that's the only other related bug on my radar.


The above issues are being resolved with this I2S. The behavior of <link disabled> was not very interoperable, and not well specified. With this HTML spec PR (https://github.com/whatwg/html/pull/4519) the behavior has been more completely specified. Chrome will implement this modified behavior starting in M85. See https://github.com/whatwg/html/issues/3840 for more details and conversation.
As discussed on the spec issue, the current situation is quite non-interoperable. The implementations all do slightly different things with the disabled attribute, and the spec text is vague. For this reason, the compat risk should be relatively lower, though still non-zero. It is possible that sites may be relying on the existing Chromium behavior, and this change may break those sites by either applying or not applying styles, or by changing the length of document.styleSheets when not expected. The overall use counter for <link disabled> is around 0.2%, but only a fraction of that should be affected by the particular behavior being changed here. The conclusion on the issue thread was that the change should not be too incompatible. Firefox already implements the new behavior. https://www.chromestatus.com/metrics/feature/timeline/popularity/809 Firefox: Shipped (https://github.com/whatwg/html/issues/3840#issuecomment-634272725) Edge: No public signals Safari: No public signals (https://lists.webkit.org/pipermail/webkit-dev/2020-May/031223.html) Web developers: No signals This makes the behavior of <link> and 'disabled' more sane and tractable, and reduces interop differences. So this should be a net win. N/A N/A
This should be fully debuggable. Yes Yes https://wpt.fyi/results/css/cssom?label=master&label=experimental&aligned&q=htmllinkelement-disabled https://crbug.com/1087043 https://github.com/whatwg/html/issues/3840#issue-343413388 https://chromestatus.com/feature/5110851973414912
This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Yoav Weiss

unread,
May 28, 2020, 5:27:52 PM5/28/20
to Mason Freed, blink-dev
On Thu, May 28, 2020 at 6:43 PM Mason Freed <mason...@chromium.org> wrote:

This just concerns style rels, right?
Are you aware of similar issues around the disabled attribute and other rels? Non-blocking for this intent, I'm just curious...

Thanks for the LGTM! And yes, this is just for stylesheet links only. I am not aware of something similar for non-style rels - do you know of particular issues? There is this bug, which discusses HTMLStyleElement and SVGStyleElement, but that's the only other related bug on my radar.

Not aware of other issues.

Another concern that was raised at the API owners meeting is regarding the compat risk here.
If I'm reading the relevant CL correctly, that change in behavior removes a style's application when it's dynamically disabled.
Do we have a sense of how many of the 0.2% sites would result in changes there?
Can you add a use counter to the cases that would actively be impacted, so that we can estimate potential breakage as this rolls out, and potentially revert in case it's too large?

Mason Freed

unread,
May 29, 2020, 5:44:53 PM5/29/20
to Yoav Weiss, blink-dev, Emilio Cobos Álvarez
+Emilio Cobos Álvarez for further input here.

Thanks for the 3 LGTMs, but it also seems like there is some concern about the potential for compat issues. I do share this concern, but I'm at a bit of a loss for what to use-count. The biggest breaking change that I can see (and that was discussed on the issue thread) is that document.styleSheets will no longer contain stylesheets for disabled HTMLLinkElements. And that might cause indexing errors later, if code assumes that a stylesheet lives at a particular index of document.styleSheets, based on the <link> contents of the html, and regardless of disabled status. I can't see a clean way to use-count that particular type of access. Also, importantly, any such page will already be broken on Firefox. I'm really open to suggestions here. About all I could think of was to count pages that 1) use link.disabled, and then subsequently 2) index out of bounds of a StyleSheetList. But even that would just put another semi-upper-bound on this situation, since I have no way to connect the two events, and the invalid index might not actually go out of bounds.

One additional data point: the total usage of link.disabled is 0.2%, as previously mentioned. However, the usage of link.disabled by the parser is 0.1%, and that use case shouldn't change behavior here. So the true use counter value upper limit is actually 0.2%-0.1% = 0.1%. Still high, but at least down by a factor of 2.

Thanks for the suggestion to run this by TAG. I'll do that.

I'll stay in hold-mode for this change pending further input.

Thanks,
Mason

Emilio Cobos Álvarez

unread,
May 29, 2020, 5:59:40 PM5/29/20
to Mason Freed, Yoav Weiss, blink-dev


On 5/29/20 11:44 PM, Mason Freed wrote:
+Emilio Cobos Álvarez for further input here.

Thanks for the 3 LGTMs, but it also seems like there is some concern about the potential for compat issues. I do share this concern, but I'm at a bit of a loss for what to use-count. The biggest breaking change that I can see (and that was discussed on the issue thread) is that document.styleSheets will no longer contain stylesheets for disabled HTMLLinkElements. And that might cause indexing errors later, if code assumes that a stylesheet lives at a particular index of document.styleSheets, based on the <link> contents of the html, and regardless of disabled status. I can't see a clean way to use-count that particular type of access. Also, importantly, any such page will already be broken on Firefox. I'm really open to suggestions here. About all I could think of was to count pages that 1) use link.disabled, and then subsequently 2) index out of bounds of a StyleSheetList. But even that would just put another semi-upper-bound on this situation, since I have no way to connect the two events, and the invalid index might not actually go out of bounds.

One additional data point: the total usage of link.disabled is 0.2%, as previously mentioned. However, the usage of link.disabled by the parser is 0.1%, and that use case shouldn't change behavior here. So the true use counter value upper limit is actually 0.2%-0.1% = 0.1%. Still high, but at least down by a factor of 2.

Thanks for the suggestion to run this by TAG. I'll do that.

I'll stay in hold-mode for this change pending further input.

Thanks,
Mason


On Thu, May 28, 2020 at 2:27 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Thu, May 28, 2020 at 6:43 PM Mason Freed <mason...@chromium.org> wrote:

This just concerns style rels, right?
Are you aware of similar issues around the disabled attribute and other rels? Non-blocking for this intent, I'm just curious...

Thanks for the LGTM! And yes, this is just for stylesheet links only. I am not aware of something similar for non-style rels - do you know of particular issues? There is this bug, which discusses HTMLStyleElement and SVGStyleElement, but that's the only other related bug on my radar.

Not aware of other issues.

Another concern that was raised at the API owners meeting is regarding the compat risk here.
If I'm reading the relevant CL correctly, that change in behavior removes a style's application when it's dynamically disabled.

Note the styles don't apply either before or after that CL. This is only about whether HTMLinkElement.sheet returns non-null / document.styleSheets contains the disabled stylesheet in the case the attribute has been dynamically set.

In the case where the behavior changes, the behavior becomes the one that Blink already has when the attribute comes from the parser. So the behavior change here is as Mason has said pretty minimal, IMO.

The reasoning behind defining this in this particular way has been to minimize the behavior changes from browsers that implemented this attribute (i.e., WebKit / Blink), while having a somewhat sane / easy to reason about behavior (i.e., setting link.disabled = false; link.disabled = true; behaves the same as the link being disabled in the first place).

 -- Emilio

Mason Freed

unread,
Jun 2, 2020, 5:04:34 PM6/2/20
to Emilio Cobos Álvarez, Yoav Weiss, blink-dev
On Fri, May 29, 2020 at 2:59 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

Note the styles don't apply either before or after that CL. This is only about whether HTMLinkElement.sheet returns non-null / document.styleSheets contains the disabled stylesheet in the case the attribute has been dynamically set.

In the case where the behavior changes, the behavior becomes the one that Blink already has when the attribute comes from the parser. So the behavior change here is as Mason has said pretty minimal, IMO.

The reasoning behind defining this in this particular way has been to minimize the behavior changes from browsers that implemented this attribute (i.e., WebKit / Blink), while having a somewhat sane / easy to reason about behavior (i.e., setting link.disabled = false; link.disabled = true; behaves the same as the link being disabled in the first place).

 -- Emilio


Thanks Emilio. Based on this comment, and the three LGTMs, I'm going to do this:
 - Implement a feature flag so that this change can be field-disabled, if compat concerns arise.
 - Land this change, with the feature enabled by default, on M85 Canary. Hopefully today, which will give ~3 weeks before Beta branch.

Thanks everyone.
Mason

Yoav Weiss

unread,
Jun 3, 2020, 2:41:31 AM6/3/20
to Mason Freed, Emilio Cobos Álvarez, blink-dev
On Tue, Jun 2, 2020 at 11:04 PM Mason Freed <mason...@chromium.org> wrote:


On Fri, May 29, 2020 at 2:59 PM Emilio Cobos Álvarez <emi...@mozilla.com> wrote:

Note the styles don't apply either before or after that CL. This is only about whether HTMLinkElement.sheet returns non-null / document.styleSheets contains the disabled stylesheet in the case the attribute has been dynamically set.

OK, glad I got that wrong :) 

In the case where the behavior changes, the behavior becomes the one that Blink already has when the attribute comes from the parser. So the behavior change here is as Mason has said pretty minimal, IMO.

The reasoning behind defining this in this particular way has been to minimize the behavior changes from browsers that implemented this attribute (i.e., WebKit / Blink), while having a somewhat sane / easy to reason about behavior (i.e., setting link.disabled = false; link.disabled = true; behaves the same as the link being disabled in the first place).

 -- Emilio


Thanks Emilio. Based on this comment, and the three LGTMs, I'm going to do this:
 - Implement a feature flag so that this change can be field-disabled, if compat concerns arise.
 - Land this change, with the feature enabled by default, on M85 Canary. Hopefully today, which will give ~3 weeks before Beta branch.

This plan SGTM!
Reply all
Reply to author
Forward
0 new messages