W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

Re: [csswg-drafts] [css-lists] CSS counter scope/inheritance is incompatible with HTML ordinals (#5477)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 22 Oct 2020 16:29:30 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-714611576-1603384169-sysbot+gh@w3.org>
The CSS Working Group just discussed `[css-lists] CSS counter scope/inheritance is incompatible with HTML ordinals`, and agreed to the following:

* `RESOLVED: change CSS Lists to make all CSS counters behave differently for this case`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> Topic:  [css-lists] CSS counter scope/inheritance is incompatible with HTML ordinals<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/5477<br>
&lt;emilio> TabAtkins: when I was writing the counter rules I was working from css 2.1 and my testing<br>
&lt;emilio> ... I knew HTML &lt;ol> didn't match CSS counters in invalid markup<br>
&lt;emilio> ... Gecko tried to switch to counters for CSS lists<br>
&lt;emilio> ... and found out that they were not web compatible<br>
&lt;emilio> ... see the example in the issue with a nested &lt;ol> directly under another<br>
&lt;emilio> ... html renders that as you'd probably expect<br>
&lt;emilio> ... that's also what editors generate for some reason<br>
&lt;emilio> ... In order to fix it we can specify that either html is magic<br>
&lt;emilio> ... that the list-item counter is magic<br>
&lt;emilio> ... or switch counter behavior<br>
&lt;emilio> ... mats is going for the later<br>
&lt;Rossen_> q<br>
&lt;emilio> ... and is proposing to do an ancestor-only check and only if that fails we look for a previous sibling counter<br>
&lt;emilio> ... that's probably fine and would still work with the main sibling use case which is naming headers<br>
&lt;emilio> ... so I'm ok with making that change<br>
&lt;emilio> Rossen_: you're referring to the third approach in the comment?<br>
&lt;emilio> TabAtkins: no, number 1<br>
&lt;dbaron> seems like a reasonable way to fix this without breaking use of counter numbering for headers<br>
&lt;emilio> fantasai: if you look at the example and replace list with section and item with h1, it will end up giving a better result<br>
&lt;emilio> ... I'm in favor of this change<br>
&lt;Rossen_> ack fantasai<br>
&lt;emilio> ... if we can pull it of<br>
&lt;emilio> off<br>
&lt;emilio> q+<br>
&lt;astearns> and you’re OK with this, faceless2?<br>
&lt;fantasai> emilio: We actually have made this change, unsure if released yet<br>
&lt;fantasai> emilio: but haven't heard of any breakage<br>
&lt;fantasai> Rossen_: cool<br>
&lt;faceless2> yes. everything I had to say on the topic before was wrong :-)<br>
&lt;emilio> Rossen_: objections?<br>
&lt;fantasai> strong +1 given emilio's report :)<br>
&lt;emilio> RESOLVED: change CSS Lists to make all CSS counters behave differently for this case<br>
&lt;emilio> [... discussion about republishing CSS2 ...]<br>
&lt;oriol> The change is in Firefox 82, which seems it was released on 2020-10-20 (but I still don't have it)<br>
</details>


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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 22 October 2020 16:29:32 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:20 UTC