Re: [csswg-drafts] [css-lists] How do counters and Shadow DOM interact?

I agree that for layout and rendering, "document order" should always be the flattened tree order.  Maybe it's worth adding a generic interpretation guideline somewhere to that effect, until all specs can be updated to newer language?  Somewhere in [CSS Scoping](https://drafts.csswg.org/css-scoping-1/), maybe?

On the specific issue:

Counter incrementing already skips over un-rendered elements (`display: none`), meaning it operates at rendering time, not on the raw DOM. So incrementation would probably need to operate on the flattened tree.

I'm inclined to suggest that counter resets and nested scope should also work in the flattened tree.  But I'm also having a hard time coming up with practical examples of it making a difference.  Shadow trees can only (currently) "slot" DOM elements that are direct children of the custom element, so you can't pull an element outside of a nesting context (all of the element's DOM ancestors will also be flattened tree ancestors). You _can+ insert it into new nested structures (adding new shadow elements between the slotted element and its DOM parent), but that would only make a difference to nested counters if the shadow elements reset the same counter.

Which brings up another question: how are counter names scoped when it comes to shadow trees?  If you have counters in the scoped stylesheet and counters in the main document stylesheet, and they happen to have the same name, would the values get intermingled?

Another possible complication: if counter resets operate on the rendering tree, wouldn't that also prevent using counter resets on `display: contents` elements, providing unexpected results if you applied `display: contents` to a  `<ol>`?

-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2679#issuecomment-390036202 using your GitHub account

Received on Thursday, 17 May 2018 22:41:06 UTC