Use a parent/child relationship in the flat tree in the definition of some elements, i.e. <tr>/<td>

[hayatoito]

See the context: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353.
I do not think we need to address this issue for v1. "It should not work by default" might make sense for a while.

[annevk]

Yeah, I think it's best to just poke holes as we go by filing issues against the respective standards.

[annevk]

Should this be closed? I still don't really understand what this is asking for.

[hayatoito]

I am okay to close this because I do not have a plan to support this soon.

What this issue is asking is:

For example, in a light tree:

<x-foo>
  <td>...</td>
  <td>...</td>
</x-foo>

in x-foo's shadow tree:

<table>
  <tr>
    <slot></slot>
  </tr>
</table>  

For example, according to https://html.spec.whatwg.org/#the-tr-element,

The sectionRowIndex attribute must, if the element has a parent table, tbody, thead, or tfoot element, return the index of the tr element in the parent element's rows collection (for tables, that's the HTMLTableElement.rows collection; for table sections, that's the HTMLTableRowElement.rows collection). If there is no such parent element, then the attribute must return −1.

The element's definition is using a raw parent, which prevents these examples from working as intended. If we are to support this kind of example to work, we might want to consider to replace a parent with *flat-tree-parent' in each definition.

[annevk]

To support that kind of light tree we'd need template-like parsing for custom elements. That is the kind of thing we'd need to address right now in #59 if we wanted it. My tentative conclusion on that is that we're not going to do it, since it's a lot of work and the benefits are marginal. (Of course, you could use XML, but it seems unlikely that kind of approach will see general adoption.)