Parse <slot> like <template>

[hayatoito]

See https://lists.w3.org/Archives/Public/public-whatwg-archive/2012Jan/thread.html#msg130 for context.

[annevk]

Should we consider this for <slot> for v1? @rniwa? @travisleithead?

[annevk]

This makes some sense given the use cases suggested in #95 too.

[rniwa]

If we're making this change, it's better done in v1 than v2. Changing the parser behavior of an element after it started getting used is extremely risky.

[annevk]

@hayatoito @dglazkov thoughts?

[dglazkov]

👍

[rniwa]

It probably doesn't make sense for slot element to appear within a head element though.

[hayatoito]

@annevk
Yeah, definitely. Regarding parsing, <slot> should have the same behavior of <template>.

That's one of pre-requirements for #404

[hayatoito]

Should I mention it as a monkey patch in Shadow DOM spec?

[hayatoito]

The <slot> in the current Shadow DOM spec only says:

Context
  Where flow content is expected.
Content model
  Transparent

On the other hand, It looks <template> has a lot of details in categories, content models and so on: https://html.spec.whatwg.org/multipage/scripting.html#the-template-element

[domenic]

More important is the maaaany changes to the parser that are necessary for template. I guess they'll need to be generalized...

[annevk]

@hayatoito that is the easy part. Search for "template" in https://html.spec.whatwg.org/multipage/syntax.html. Monkey patching that is the hard part here and the most important for correct parser implementations. And note that we cannot do the exact same thing as for template elements, since template elements have their children inserted into DocumentFragment object. We don't want that here.

[rniwa]

In addition to needing a consensus, someone needs to make a concrete proposal.

[annevk]

So I'm trying to figure out when we need this complexity and it seems given the restrictions on attachShadow() that currently you can never get there. E.g., the original example is

<slot>
  <tr><td>...
</slot>

meaning the slot element's fallback is a row in a table. That means however that the shadow root's host must be a thead element (since only children are slotable) or a table element in an XHTML context. And neither of those is possible with the current attachShadow() restrictions.

I'm not opposed to changing the HTML parser so that this kind of thing will be possible in the future once attachShadow() becomes less restricted, but I would like everyone to sign of on changing the HTML parser to treat template and slot nearly identical as it is quite an invasive change that will take me a bit of time (I'm happy for someone else to volunteer too, but since @dglazkov's email in 2012 that doesn't seem to have happened...).

[zcorpan]

If we make slot parse like template I think we should make custom elements also parse like template, so that there is no reason to abuse slot when there is a need to use a tr child for a custom element.

Also see #113 (comment)
Also related whatwg/html#721

[domenic]

Wouldn't making custom elements parse like template be a backward-incompatible change?

[zcorpan]

Yes, but only if you have broken markup to begin with, I believe. But certainly it's not zero-risk. Same with supporting /> for custom elements.

[rniwa]

Yes, but only if you have broken markup to begin with, I believe. But certainly it's not zero-risk. Same with supporting /> for custom elements.

That seems quite risky to me.

[zcorpan]

Which part, parsing as template or supporting />, or both?

I analyzed httparchive for /> for custom elements in whatwg/html#721 (comment) and concluded that for those pages it would be a net improvement, but it's still not zero-risk because the data doesn't include the long tail or deep pages or corporate apps or logged-in pages and so forth. Adding use counters and/or trying to ship the change would tell more, but that needs someone who thinks the benefit is worth the risk and the work.

[annevk]

I don't care strongly what we do here, but this is something we need to decide on soon. This basically blocks both Shadow DOM and custom elements.

Parsing custom elements like template seems high unlikely to be web-compatible, given that a lot more elements can then become children of table, tr, etc. So if we want to couple the behavior of slot and custom elements, the easiest path forward would be to give neither parsing behavior that is different from other unknown elements (apart from maybe supporting /> as per above).

[zcorpan]

tl;dr: I can live with different parsing for slot and custom elements.

Rendering of <table><custom-foo><tr><td>... would indeed be broken unless it's display:contents by default, at least when it's a child of table/tbody/tfoot/thead/tr.

If people working on this see a clear benefit for template-like parsing for slot but less benefit and higher risk for custom elements, I don't want to block making slot as useful as it can be. I just wanted to point out that enabling it could lead to developers opting to abuse the element for other purposes than what slot was intended for to get better parsing when what they actually wanted was a custom element.

[annevk]

I think @hayatoito and also @dglazkov would ideally like to allow these kind of scenarios, as posted by @hayatoito elsewhere:

Light tree:

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

x-foo's shadow tree:

<table>
  <tr>
    <slot>
      <td>fallback</td>
      <td>fallback</td>
    </slot>
  </tr>
</table>  

If we want to enable that, we will need to change parsing for both custom and slot elements. These are the problems we face:

1. Lack of HTML parser expertise. The experienced developers and specification editors are mostly working on other things and have limited amounts of time.
2. Lots of compatibility hazards that will require trial and error; tweaking the HTML parser is somewhat dangerous

The upside is that it would be quite neat to be able to do the above and make HTML a lot more extensible.

[rniwa]

I'm strongly opposed to parsing custom elements like template as that would be backwards incompatible change that likely to affect many existing contents.

[domenic]

Going to untag this as custom elements since it seems like nobody has the stomach for that kind of change. I agree it would have been nice but oh well.

[annevk]

Then we should probably not do it for <slot> either and just parse them all as normal elements.

[domenic]

Telecon agreement: don't change the parser. A variety of alternatives are possible and can be pursued in the future, to solve the underlying problems, but the appetite for changing the parser is too low. If it turns out this is super-popular, there will be workarounds possible via libraries, and we can reconsider.