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/AThis 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/5110851973414912This 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.
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...
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDhXUtrwJgL5p8yJ6X3wFRFvObRZqWOxPCVUEyy5fVCLwg%40mail.gmail.com.
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/AThis 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/5110851973414912This 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.
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.
--
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.
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.
+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
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
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.