Luke Warlow

Raised this after hearing a few people on Twitter get surprised by it as well as seeing this issue on the compat-data repo: https://github.com/mdn/browser-compat-data/issues/22195

Oh that's good it's already there, but yeah I think it's worth making more prominent i read through the page and didn't spot that initially.

No longer relevant (for agenda) as the property is only exposed where supported now (except for the submit button case but that's less important imo)

More granular but same overall theme to https://github.com/openui/open-ui/issues/758

Could it be worthwhile specifying that `::-webkit-scrollbar { display: none; }` should be implemented? I believe this is probably the only styling that could lead to breakage if it was...

Given they already can't do that in Firefox I can't see how they could take issue with it? scrollbar-width at least allows for hiding and requesting thinner bars when space...

https://groups.google.com/a/chromium.org/g/blink-dev/c/PkEsMirl2zE/m/ArphSa39AAAJ just as an FYI I've filed an intent to ship in Chrome for the standard properties.

It'd be good if we could add one for usage in general (maybe another for usage that won't be ignored by standard property usage) and another for the display none...

I recall there was a firefox bug that discussed implementing this (at least a minimal case) for compat reasons and the conclusion seemed to be that the performance could be...

> it's probably also worth handling width:0 similarly to display:none, as I'm quite sure I've seen it used as well on live sites in my webcompat work before. Interestingly Safari...