- From: Hayato Ito <notifications@github.com>
- Date: Thu, 14 Apr 2016 23:56:28 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/331/210314809@github.com>
Thank you, @tabatkins ! I reviewed quickly. Here are my comments: 3. Shadow Encapsulation > The descendants of a shadow host (its light tree) must not generate boxes in the formatting tree. Instead, the contents of the shadow tree generate boxes as if they were the contents of the shadow host instead. > In several instances in shadow DOM, elements don’t have element parents (instead, they may have a shadow root as parent, or something else). An element without a parent, or whose parent is not an element, is called a top-level element. > While a shadow host’s light tree does not generate boxes normally, its light tree direct children can be explicitly pulled into a shadow tree and forced to render normally. This is done by marking the child as slotable and then, in the shadow tree, creating a slot set to receive the slotable, making the element assigned to the slot. (Anonymous text nodes that are direct children are always slotable.) Since the actual logic, "Which elements generate a box?", should be explained by the concept of the [flat tree] , can we avoid to explain that in details here? [flat tree]: https://w3c.github.io/webcomponents/spec/shadow/#dfn-flat-tree I'm wondering how to state it simply in css scoping. The current Shadow DOM spec has the followings in the [section of Flat trees](https://w3c.github.io/webcomponents/spec/shadow/#flat-trees): DOM Standard does not need a flat tree. I think only css scoping is a client of a flat tree. Thus, eventually, we need to upstream *a flat tree* to CSS. > A document flat tree is a flat tree whose root node is a document > A node is in a document flat tree if it participates in a document flat tree. > Unless an element is in a document flat tree, the element must not create any CSS box. > In resolving CSS inheritance, an element must inherit from the parent node in the flat tree, if applicable. > User agents must use the document flat tree in the visual formatting model, instead of the document tree. I think we should upstream these sentences to CSS scoping. I guess these sentences need to be refined somehow to match the css scoping world. 3.1. Shadow DOM Selection Model > Elements in the DOM have zero or more shadow trees. This can be: > Elements in the DOM have zero or *one* shadow tree. Yeah, multiple shadow trees are removed. Otherwise, we might want to omit this because it looks a duplication of the HTML Standard. 3.1.1. Shadow Hosts in a Shadow Tree > For the purpose of Selectors, a shadow host also appears in each of its shadow trees, with the contents of the shadow tree treated as its children. If an element has multiple shadow trees, it appears in each shadow tree’s context independently; each shadow tree sees itself as the contents of the shadow host, not the other shadow trees. This can be: > For the purpose of Selectors, a shadow host also appears in its shadow tree, with the contents of the shadow tree treated as its children. because multiple shadow trees are removed. 3.1.2. Slots and Slotted Elements in a Shadow Tree > If a slot is not assigned any of its shadow host’s children, that slot’s own children are assigned to it. Otherwise, a slot’s DOM children must not generate any boxes, as if they were display:none. > Slots can, themselves, be assigned to a slot in a deeper shadow tree. If this occurs, the elements assigned to the first slot are also treated as being assigned to the deeper slot. The deepest slot that an element is assigned to is its final assigned slot. > Elements assigned to a slot must generate boxes as if they were children of their final assigned slot (rather than children of their actual parent in a shadow host’s light tree). I think we can remove these sentences. If we use the [flat tree] in the previous section, we do not need to mention a slot here as a special. 3.2.2. Selecting Slot-Assigned Content: the ::slotted() pseudo-element > The ::slotted() pseudo-element represents the elements assigned to a slot. This pseudo-element only exists on slots. "::slotted()" represents "distributed nodes", instead of "assigned nodes". "assigned nodes" and "distributed nodes" are different. I think you can refer [this](https://w3c.github.io/webcomponents/spec/shadow/#dfn-distributed-nodes ) as the definition of "distributed". --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/issues/331#issuecomment-210314809
Received on Friday, 15 April 2016 06:56:57 UTC