This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
See the results of Razvan's experiment and the issue of accessing a named flow and scoped styles. There is a conflict between having the named flow on the Document and scoped shadow DOM branches. The question is: should named flows be Document-wide (always) or be scoped as the rest of the shadow styles? One solution is to say that named flows are document-wide (always) and can be referenced from scoped styles. Another solution is to say that flows are scoped, and provide a solution to give DOM access to scoped flows.
Dmitry Glaskov suggested it may be related to: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444
Vincent, what's the latest thinking on this?
The two questions we want to ask ourselves is: (1) let's suppose we want to use css regions inside a web components, do we want to be able to use a flow name that's not accessible from the outside document and do not conflict between multiple (possibly nested) instances of the web component? If the answer is "yes", which I believe, then named flows should be layout-tree-relative, and a document & a shadow dom may not share flows. That means, however, that the only way to pour content from a document to inside a web components will then be to put the document-hosted elements you want to pour into the flow as descendant of the web components and to rely on the Web Components <content select="..."> element to modify the position in the layout-tree of those elements and bring them inside the shadow layout-tree. (2) let's suppose we want to use css regions inside a document, do we want a web component to be able to pour elements from the shadow tree in a document-wide tree? how would those elements get reported by the different APIs in such case ? If the answer is yes, then we must find a way for a shadow subtree to intervene in the document-wide world, and this may be related to previously noted issue about selections. I believe a flag asking to flatten an element's shadow sub-tree to its parent sub-tree would affect named flow behavior as well and provide us with a solution for this specific case. My tentative conclusion is that we want to specify (1) but may leave the door open to (2) in the future, if the shadow dom spec allows to control the layout-tree scope of a shadow tree.
I am not sure this is still relevant. Let me close this tentatively.
This needs to stay open, but should be generalized. It's describing a problem with everything in CSS that defines a global name, which is problematic when shadow DOM is scoping styles. It's too easy for shadow styles and light styles to accidentally collide when defining, and particularly when *using*, global names. We need to solve this in a general way, that fixes Regions and @font-face and @counter-style and all the rest.
I got it. Thank you. Let's keep this open.