Bug 16527 - [Shadow]: getFlowByName and shadow DOM
Summary: [Shadow]: getFlowByName and shadow DOM
Alias: None
Product: CSS
Classification: Unclassified
Component: Regions (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Alan Stearns
QA Contact: public-css-bugzilla
URL: https://github.com/oslego/shadow-dom-...
Depends on:
Blocks: 15480
  Show dependency treegraph
Reported: 2012-03-26 16:23 UTC by Vincent Hardy
Modified: 2014-11-20 02:10 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Hardy 2012-03-26 16:23:49 UTC
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.
Comment 1 Vincent Hardy 2012-03-26 17:20:12 UTC
Dmitry Glaskov suggested it may be related to:

Comment 2 Dimitri Glazkov 2013-07-17 18:17:39 UTC
Vincent, what's the latest thinking on this?
Comment 3 FremyCompany 2013-08-02 22:46:08 UTC
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.
Comment 4 Hayato Ito 2014-11-19 04:51:51 UTC
I am not sure this is still relevant.
Let me close this tentatively.
Comment 5 Tab Atkins Jr. 2014-11-19 18:18:29 UTC
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.
Comment 6 Hayato Ito 2014-11-20 02:10:16 UTC
I got it. Thank you. Let's keep this open.