- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Sep 2023 19:19:15 +0000
- To: public-css-archive@w3.org
Rendering of Chrome's handling of @vmpstr's code, with a little bit of styling to show off the nesting and containment better:
Yeah, this is just buggy, it reflects neither the current spec *nor* dbaron's proposal.
The current spec *should* render as:
```
1
2 (the style-contained element)
2.1
2.2
3
4
5
```
Because `counter-*` properties are specified as scoped to the *subtree* rather than the *element*, the style-scoped element itself should act like normal; it increments the `foo` counter. Then the elements *inside* the scope can *see* the foo counter, but aren't allowed to modify it, so they create a nested `foo` counter instead.
Dbarons' proposal should render as:
```
1
2 (the style-contained element)
3
4
3
4
5
```
Same reasoning as above for the style-scoped element itself. The elements inside the scope instead see a *copy* of the counters coming from the style-scoped element. They're thus allowed to modify the `foo` counter as normal, but since they're only modifying a copy, the elements outside of the scope don't see their modifications.
----------
And for completeness, without any containment at all it should look like this (and impls do indeed match this):
```
1
2 (the element that used to be style-contained)
3
4
5
6
7
```
So we see the differences here. Under both the current spec and dbaron's proposal, the elements *following* the containment act identically, pretending the contained subtree doesn't exist. In dbaron's proposal, however, the stuff inside the subtree also acts identically to how it worked without containment.
--
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9212#issuecomment-1739877555 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 September 2023 19:19:17 UTC