This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28353 - [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. <ol>/<li>
Summary: [Shadow]: Use a parent/child relationship in the composed tree for some eleme...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 22716
  Show dependency tree / graph
 
Reported: 2015-03-27 06:07 UTC by Hayato Ito
Modified: 2015-04-30 06:20 UTC (History)
4 users (show)

See Also:

Attachments

Description Hayato Ito 2015-03-27 06:07:11 UTC 
For example, suppose the following case:

<div id="shadow-host">
  <summary>summary</summary>
</div>


#shadow-root-of-the-shadow-host
  <details>
    <content></content>
    <div>details</div>
  </details>


Unfortunately, this should not be rendered as intended, if we interpret the spec [1] strictly.

[1]: https://html.spec.whatwg.org/multipage/forms.html#the-summary-element

The spec says:

> Contexts in which this element, <summary>, can be used:
>   As the first child of a details element.


The same discussion might be also applied to the following elements, including, but not limited to:

- <tr>/<td>
- <ol>/<li>

I've not investigated carefully yet. We have to investigate further.


In Blink, AFAIR, we've spent some efforts to support these elements so that they are rendered correctly as intended even though they form a parent/child relationship in the composed tree, rather than in a node tree. However, I'm afraid that no one has a clear idea what behavior is correct.

If we are to support these cases, the spec must specify that somehow.
Comment 1 Anne 2015-04-23 21:18:48 UTC 
This falls out of defining CSS in terms of the composed tree.
Comment 2 Koji Ishii 2015-04-24 00:11:24 UTC 
Can tpu clarify what you meant? I just didn't understand.

Should the example be valud, pr not? I prefer not, but it was controversial.
Comment 3 Anne 2015-04-24 00:26:06 UTC 
So in the case of <tr> it should work if the <td> becomes an actual child of the <tr> in the composed tree.

For <details> it seems like this should not work per the specification at the moment: https://html.spec.whatwg.org/multipage/rendering.html#the-details-element-2 We might want to revisit the specification at some point to consider the composed tree rather than the light tree, but we'd have to consider that on a case-by-case basis.
Comment 4 Koji Ishii 2015-04-24 01:13:54 UTC 
If it's a case-by-case basis, and "should not work" by default unless it's defined to work, I'm fine. Some people believes that it should work by default.

Why do you think <td> should work? Did you mean it should work without efforts given what current impls do, or did you mean it's defined to work somewhere in the spec I missed?
Comment 5 Anne 2015-04-24 16:21:54 UTC 
It should fall out of CSS operating on the composed tree. Not sure that's well defined though. Or is there something I'm missing?
Comment 6 Koji Ishii 2015-04-28 15:56:57 UTC 
Ah, sorry, I was thinking of table DOM operation but that was not the original topic. So for rendering of table is defined well with display and anonymous boxes, so I agree that it should work.

So, what you meant was anything that has mapping to CSS display should work, but <details> is not? That I did not read well from your sentence at the first point, but now make sense. Thank you (and sorry) for explaining twice.
Comment 7 Anne 2015-04-30 06:20:38 UTC 
<details> is defined in terms of some magic component that only considers the actual first child, not the composed first child. Therefore per the current HTML specification it would not work.

APIs would indeed also not work.

What we discussed is that we'd file bugs on a per-API basis whenever it would make sense to change something. Ideally APIs that poke into the shadows have some kind of prefix though, e.g. "deep" as with "deepPath".