Re: [csswg-drafts] [css-lists-3] list-item counter nesting is confusing (#9076)

The CSS Working Group just discussed `[css-lists-3] list-item counter nesting is confusing`.

<details><summary>The full IRC log of that discussion</summary>
&lt;keithamus> oriol: something discussed in December. narrow counters<br>
&lt;keithamus> oriol: still propagated to descendents, not to following siblings<br>
&lt;keithamus> oriol: agreed to have something like this in December. Details weren't resolved. Let's do that now<br>
&lt;keithamus> oriol: 1. Syntax to enable this<br>
&lt;keithamus> oriol: first idea something like reversed counters, functional notation in the counter-reset prop.<br>
&lt;keithamus> oriol: takes name of counter as argument<br>
&lt;keithamus> oriol: maybe not great. how do you handle interactions with counter thats both narrow and reversed?<br>
&lt;keithamus> oriol: in general narrow counters are better default. Not defaault because we didnt have counter set<br>
&lt;keithamus> oriol: maybe just better to have option to set all to narrow? fantasai proposed new property counter-scope: narrow<br>
&lt;keithamus> oriol: need exception for list-item counter to preserve compat with html ordinals<br>
&lt;keithamus> oriol: list item counter would be magical but it is alreadu<br>
&lt;keithamus> s/alreadu/already<br>
&lt;kizu> q+<br>
&lt;astearns> ack kizu<br>
&lt;keithamus> kizu: given this is obscure issue. counters with list item is not something authors know or use.<br>
&lt;keithamus> kizu: few years ago there was a lot of compat issues. Now its better. From what I see theres some cross browser issues still<br>
&lt;keithamus> kizu: can we just set default to work how we expect it to work?<br>
&lt;keithamus> oriol: problem is blink and webkit html ordinals arent implemented using css counters<br>
&lt;keithamus> oriol: according to spec it should be magical<br>
&lt;keithamus> oriol: firefox is doing it as counter but when this change happened found some websites breaking. Added hacky narrow counters<br>
&lt;keithamus> oriol: we cant change html ordinals to have wide propagation<br>
&lt;keithamus> oriol: some expect to be narrow<br>
&lt;keithamus> oriol: normal css counters have had this behavior, people rely on this.<br>
&lt;keithamus> oriol: eg without counter-set property people use counter-reset which they want propagated to siblings<br>
&lt;keithamus> oriol: conflict between these. Need to keep old behavior for counters<br>
&lt;keithamus> oriol: we want to allow users to be able to switch to html ordinals<br>
&lt;keithamus> kizu: just for counters without css counters function?<br>
&lt;keithamus> oriol: assuming html ordinals use magical list item counter<br>
&lt;keithamus> oriol: we need something that works for both cases<br>
&lt;miriam> q+<br>
&lt;keithamus> oriol: proposal with new property - counter could be narrow if list item<br>
&lt;emilio> q+<br>
&lt;keithamus> oriol: or if property is set to narrow. Allow authors to decide to opt in to html ordinals<br>
&lt;keithamus> oriol: preserve by default existing in all cases<br>
&lt;keithamus> kizu: only case is that not many cases for counters list-item. If we could make default for list types work more as expected but if not possible its okay<br>
&lt;astearns> ack miriam<br>
&lt;keithamus> miriam: curious if proposed property sets the default for all counters or just the non list item ones?<br>
&lt;keithamus> miriam: if you set wide does it change how list item counters work?<br>
&lt;keithamus> fantasai: no. counter properties dont effect list item unless named<br>
&lt;keithamus> fantasai: list-item counter would have narrow by default unless you explicitly set list-item counter to wide.<br>
&lt;keithamus> fantasai: just like conter-reset none<br>
&lt;astearns> ack emilio<br>
&lt;astearns> ack dbaron<br>
&lt;emilio> q-<br>
&lt;keithamus> astearns: we're at time. Can we take back to issue?<br>
&lt;keithamus> astearns: make async resolution?<br>
&lt;dbaron> I wanted to say 2 things:<br>
&lt;dbaron> 1. the reason compat is interesting here is that we had a CSS feature that was designed to be the underlying mechanism behind an HTML feature, but there was a long period of time where *both* features were implemented but without the underlying-ness.  So we have compat concerns about both features separately, but we also want to make them fit together.<br>
&lt;dbaron> 2. I'd be interested in seeing what the proposed property looks like in a little more detail:  name, values, is it inherited, what does it apply to (counters established by the element?).<br>
&lt;fantasai> Not inherited, applies to counters declared in counter-reset<br>
&lt;fantasai> just like counter-style<br>
&lt;dbaron> (Also, Zoom decided that my browser had denied microphone permission to it... despite that I'd talked earlier in the meeting without leaving Zoom!)<br>
&lt;oriol> I would prefer it to be inherited, even if that's not consistent with other counter properties<br>
&lt;dbaron> see, that's why I wanted to ask :-)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9076#issuecomment-2023328493 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 27 March 2024 17:05:39 UTC