16527 2012-03-26 16:23:49 +0000 [Shadow]: getFlowByName and shadow DOM 2014-11-20 02:10:16 +0000 1 1 1 Unclassified CSS Regions unspecified PC All REOPENED https://github.com/oslego/shadow-dom-regions P2 normal --- 15480 1 vhardy stearns dglazkov eoconnor fremycompany_pub hayato jackalmage stearns public-css-bugzilla oldest_to_newest 66061 0 vhardy 2012-03-26 16:23:49 +0000 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. 66066 1 vhardy 2012-03-26 17:20:12 +0000 Dmitry Glaskov suggested it may be related to: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444 90855 2 dglazkov 2013-07-17 18:17:39 +0000 Vincent, what's the latest thinking on this? 91555 3 fremycompany_pub 2013-08-02 22:46:08 +0000 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. 115094 4 hayato 2014-11-19 04:51:51 +0000 I am not sure this is still relevant. Let me close this tentatively. 115137 5 jackalmage 2014-11-19 18:18:29 +0000 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. 115184 6 hayato 2014-11-20 02:10:16 +0000 I got it. Thank you. Let's keep this open.