(In reply to Hiroyuki Ikezoe (:hiro) from comment #17) > For example, [scrollbar-width-010.html](https://searchfox.org/firefox-main/rev/83d1a08db47b91a4d53341a799745caac9c38bde/testing/web-platform/tests/css/css-scrollbars/scrollbar-width-010.html) is one of the failure tests. [ Explaining the test failure, largely for the benefit of future-me; I expect you already know the following: ] For this specific test, and I imagine many of the others that you referenced -- the test is turning off scrollbars with a `::-webkit-scrollbar { display: none }` rule, and it checks that they were in fact turned off (by comparing the root element's width against the viewport width). That should trivially fail in Firefox because we'll ignore the `::-webkit-scrollbar` style, but the reason we currently pass the test is that it has this fallback style for browsers-that-lack-support-for-`::-webkit-scrollbar` which independently turns off the scrollbars: ```css @supports not selector(::-webkit-scrollbar) { :root { overflow: hidden; } ``` This bug's current patch makes us skip that `@supports` clause (because we now claim to support `::-webkit-scrollbar`), so we end up at the mercy of the `::-webkit-scrollbar{ display:none }` rule to do the scrollbar-hiding; and IIUC the current patch doesn't actually implement any such display:none scrollbar-hiding behavior (right?), which is why we fail. > From [the relevant spec](https://drafts.csswg.org/css-scrollbars-1/#width-compat); > [...] > So I believe the test is invalid, the spec doesn't mention that `::-webkit-scrollbar` needs to be respected in the case where `scrollbar-width` is `auto`. I think the test's expectations are fine, though probably the test should be renamed to have `.tentative` since it's testing something nonstandard -- it's expecting that `::-webkit-scrollbar` DOES have a particular effect; and the relevant standards only make declarations about situations when `::-webkit-scrollbar` should NOT have an effect. (i.e. the spec for the modern feature just says that the modern feature "wins" if the page specifies both, but it's not trying to define how `::-webkit-scrollbar` behaves on its own) So. Having said all that - I'm not super worried about the WPT failure in-and-of-itself (I don't think it's part of an interop score or anything, and I'm not entirely sure whether it's reflective of real-world content) -- but for the purposes of this bug here, I think this WPT failure raises two questions: (A) As part of this work, maybe we should treat `::-webkit-scrollbar { display: none }` as effectively the same as `scrollbar-width: none`? (when `scrollbar-width` is unspecified) I assume that's essentially what Chrome and Safari are doing, and that's what this one test at least is expecting. And I believe we've seen that styling in real-world sites before, so it'd probably be nice to support that. (B) Should we worry about sites specifying scrollbar-styles using `@supports` conditions for `::-webkit-scrollbar` styles, with graceful fallback that we're currently benefiting from, where we'll start losing out if we start pretending to support `::-webkit-scrollbar`? My thoughts on these questions: * I tend to think we should do (A), though it could easily happen as a separate/followup work item. We just might want to consider it as something that blocks letting `layout.css.fake-webkit-scrollbar.enabled` ride the trains. * I'm not super worried about (B); I suspect the types of sites that bother to use @supports conditions to check for ::-webkit-scrollbar support will also be the types of sites that would default to using the standard properties. (And in many cases maybe it won't end up mattering too much either way.)
Bug 1977511 Comment 18 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #17) > For example, [scrollbar-width-010.html](https://searchfox.org/firefox-main/rev/83d1a08db47b91a4d53341a799745caac9c38bde/testing/web-platform/tests/css/css-scrollbars/scrollbar-width-010.html) is one of the failure tests. [ Explaining the test failure, largely for the benefit of future-me; I expect you already know the following: ] For this specific test, and I imagine many of the others that you referenced -- the test is turning off scrollbars with a `::-webkit-scrollbar { display: none }` rule, and it checks that they were in fact turned off (by comparing the root element's width against the viewport width). That should trivially fail in Firefox because we'll ignore the `::-webkit-scrollbar` style, but the reason we currently pass the test is that it has this fallback style for browsers-that-lack-support-for-`::-webkit-scrollbar` which independently turns off the scrollbars: ```css @supports not selector(::-webkit-scrollbar) { :root { overflow: hidden; } ``` This bug's current patch makes us skip that `@supports` clause (because we now claim to support `::-webkit-scrollbar`), so we end up at the mercy of the `::-webkit-scrollbar{ display:none }` rule to do the scrollbar-hiding; and IIUC the current patch doesn't actually implement any such display:none scrollbar-hiding behavior (right?), which is why we fail. > From [the relevant spec](https://drafts.csswg.org/css-scrollbars-1/#width-compat); > [...] > So I believe the test is invalid, the spec doesn't mention that `::-webkit-scrollbar` needs to be respected in the case where `scrollbar-width` is `auto`. I think the test's expectations are fine, though probably the test should be renamed to have `.tentative` since it's testing something nonstandard -- it's expecting that `::-webkit-scrollbar` DOES have a particular effect; and the relevant standards only make declarations about situations when `::-webkit-scrollbar` should NOT have an effect. (i.e. the spec for the modern feature just says that the modern feature "wins" if the page specifies both, but it's not trying to define how `::-webkit-scrollbar` behaves on its own) So. Having said all that - I'm not super worried about the WPT failure in-and-of-itself (I don't think it's part of an interop score or anything, and I'm not entirely sure whether it's reflective of real-world content) -- but for the purposes of this bug here, I think this WPT failure raises two questions: (A) As part of this work, maybe we should treat `::-webkit-scrollbar { display: none }` as effectively the same as `scrollbar-width: none`? (when `scrollbar-width` is unspecified) I assume that's essentially what Chrome and Safari are doing, and that's what this one test at least is expecting. And I believe we've seen that styling in real-world sites before, so it'd probably be nice to support that. (B) Should we worry about sites specifying scrollbar-styles using `@supports` conditions for `::-webkit-scrollbar` styles, with graceful fallback that we're currently benefiting from, where we'll start losing out if we start pretending to support `::-webkit-scrollbar`? My thoughts on these questions: * I tend to think we should do (A), though it could easily happen as a separate/followup work item. We just might want to consider it as something that blocks letting `layout.css.fake-webkit-scrollbar.enabled` ride the trains. * I'm not super worried about (B); I suspect the types of sites that bother to use @supports conditions to check for ::-webkit-scrollbar support will also be the types of sites that would default to using the standard properties. (which means partially-implemented `::-webkit-scrollbar` would still be fine). (And in many cases maybe it won't end up mattering too much either way.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #17) > For example, [scrollbar-width-010.html](https://searchfox.org/firefox-main/rev/83d1a08db47b91a4d53341a799745caac9c38bde/testing/web-platform/tests/css/css-scrollbars/scrollbar-width-010.html) is one of the failure tests. [ Explaining the test failure, largely for the benefit of future-me; I expect you already know the following: ] For this specific test, and I imagine many of the others that you referenced -- the test is turning off scrollbars with a `::-webkit-scrollbar { display: none }` rule, and it checks that they were in fact turned off (by comparing the root element's width against the viewport width). That should trivially fail in Firefox because we'll ignore the `::-webkit-scrollbar` style, but the reason we currently pass the test is that it has this fallback style for browsers-that-lack-support-for-`::-webkit-scrollbar` which independently turns off the scrollbars: ```css @supports not selector(::-webkit-scrollbar) { :root { overflow: hidden; } ``` This bug's current patch makes us skip that `@supports` clause (because we now claim to support `::-webkit-scrollbar`), so we end up at the mercy of the `::-webkit-scrollbar{ display:none }` rule to do the scrollbar-hiding; and IIUC the current patch doesn't actually implement any such display:none scrollbar-hiding behavior (right?), which is why we fail. > From [the relevant spec](https://drafts.csswg.org/css-scrollbars-1/#width-compat); > [...] > So I believe the test is invalid, the spec doesn't mention that `::-webkit-scrollbar` needs to be respected in the case where `scrollbar-width` is `auto`. I think the test's expectations are fine, though probably the test should be renamed to have `.tentative` since it's testing something nonstandard -- it's expecting that `::-webkit-scrollbar` DOES have a particular effect; and the relevant standards only make declarations about situations when `::-webkit-scrollbar` should NOT have an effect. (i.e. the spec for the modern feature just says that the modern feature "wins" if the page specifies both, but it's not trying to define how `::-webkit-scrollbar` behaves on its own) So. Having said all that - I'm not super worried about the WPT failure in-and-of-itself (I don't think it's part of an interop score or anything, and I'm not entirely sure whether it's reflective of real-world content) -- but for the purposes of this bug here, I think this WPT failure raises two questions: (A) As part of this work, maybe we should treat `::-webkit-scrollbar { display: none }` as effectively the same as `scrollbar-width: none`? (when `scrollbar-width` is unspecified) I assume that's essentially what Chrome and Safari are doing, and that's what this one test at least is expecting. And I believe we've seen that styling in real-world sites before, so it'd probably be nice to support that. (B) Should we worry about sites specifying scrollbar-styles using `@supports` conditions for `::-webkit-scrollbar` styles, with graceful fallback that we're currently benefiting from, where we'll start losing out if we start pretending to support `::-webkit-scrollbar`? My thoughts on these questions: * I tend to think we should do (A), though it could easily happen as a separate/followup work item. We just might want to consider it as something that blocks letting `layout.css.fake-webkit-scrollbar.enabled` ride the trains. * I'm not super worried about (B); I suspect the types of sites that bother to use @supports conditions to check for ::-webkit-scrollbar support will also be the types of sites that would default to using the standard properties. (which means partially-implemented `::-webkit-scrollbar` would still be fine). And in many cases maybe it won't end up mattering too much.