- From: Oriol Brufau via GitHub <sysbot+gh@w3.org>
- Date: Tue, 22 Aug 2023 11:10:19 +0000
- To: public-css-archive@w3.org
https://drafts.csswg.org/css-contain-2/#example-6932a400 > the `counter()` and `counters()` value of the content property is not itself scoped, and can refer to counters established outside of the subtree So the `::before` can see the outer instance of the counter instead of `0`. That said, there are nested `.list-item` children that will use `counter-increment` and thus create a new instance of the counter. Where does this happen? See discussion in #5175 The example in the spec says > As [counter-increment](https://drafts.csswg.org/css2/#propdef-counter-increment) is scoped to an element’s subtree, the first use of it within the subtree acts as if the named counter were set to 0 **at the scoping element** So with that interpretation the `::before` of the `.list-item` wrapper should see `0` indeed. ``` [0] A1 [1] B1 [2] B2 [2] A2 [3] A3 ``` However I think that's wrong, the new counter should be instantiated on the element that tries to modify it (which is what all browsers do in simple cases). So then I agree with Firefox: ``` [1] A1 [1] B1 [2] B2 [2] A2 [3] A3 ``` In fact, when using `counters()`, Blink behaves like Firefox ``` [1] A1 [1.1] B1 [1.2] B2 [2] A2 [3] A3 ``` -- GitHub Notification of comment by Loirooriol Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9212#issuecomment-1687981141 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 22 August 2023 11:10:22 UTC