Repository navigation
[css-counter-styles-3][css-lists-3] Unable to feature detect built-in counter styles #8907
Description
In the CSS2-era, pre-@counter-style, you can feature detect whether a given counter style is supported via CSS.supports("list-style-type", "foo") (or similar CSSOM incantations which work further back).
However, with list-style-type now taking <counter-style>, (almost) any <custom-ident> is a valid value for list-style-type, which means you can no longer feature detect what counter styles have built-in support as far as I can tell.
Activity
nt1m commentedon Jun 2, 2023
It may be that we need something like
@supports counter-style(X).cc @tabatkins @fantasai
nt1m commentedon Jun 2, 2023
Although if you're going to define a counter style either way, it doesn't make a big difference if you define it conditionally or unconditionally.
tabatkins commentedon Jun 2, 2023
Right, I think the only way in which this would really be useful is if you needed to test for a new predefined complex counter style, which you couldn't reproduce yourself with
@counter-style.For anything you can reproduce with
@counter-style, the use-case for testing for it seems very minimal at first glance. If it's not supported, you can just add support for it yourself. At best, maybe using this to guard an import would make sense, tho I'm pretty certain the overhead of a fresh request is gonna be larger than the extra kilobyte from inlining it instead. I'm not certain what you'd do with the query besides adding your own support, tho; what possible layout or styling difference would make sense to be contingent on whether a counter style was predefined or not?I could be convinced otherwise, tho.
Update Safari 17 based on mdn-bcd-collector
Update based on mdn-bcd-collector
Update Safari 17 based on mdn-bcd-collector
Update Safari 17 based on mdn-bcd-collector
Update Safari 17 based on mdn-bcd-collector
Updates for Safari 17, based on Beta 1 (#20064)