"appropriate template contents owner document" needs to set "allow declarative shadow roots"

[AtkinsSJ]

What is the issue with the HTML Standard?

I noticed in Ladybird that declarative shadow dom wouldn't work for elements inside a <template>. For example: this test includes the following:

    <div id="elementSource">
        <span>
            <template shadowrootmode="open"></template>
        </span>
    </div>

    <div id="elementTarget"></div>

    <template id="templateSource">
        <span>
            <template shadowrootmode="open"></template>
        </span>
    </template>

    <div id="templateTarget"></div>

The elementSource example works, creating a shadow dom for the span, but the templateSource does not do so.

With some digging, it seems the issue is that the document for templateSource's contents, as created by the appropriate template contents owner document algorithm, doesn't allow declarative shadow roots. This causes step 9 of handle in head -> A start tag whose tag name is "template" to refuse to create the declarative shadow root.

As a test fix, changing that "appropriate template contents owner document" algorithm to set the new document's "allow declarative shadow roots" flag to match document's, improves the WPT score without any apparent regressions. This probably isn't the correct fix, but it suggests that flag does need setting.

[annevk]

In WebKit it seems that we pass this policy directly to the HTML parser and not store it on document. I suspect that forwarding ends up doing the right thing however.

cc @mfreed7 @foolip

[mfreed7]

In WebKit it seems that we pass this policy directly to the HTML parser and not store it on document. I suspect that forwarding ends up doing the right thing however.

In Chromium, this bit is stored in the tree builder, and used for templates (without consulting the template document or copying bits into it). I suspect the same as @annevk - forwarding also probably does the right thing.

[AtkinsSJ]

Thanks. The difference between forwarding it and the way you've described Blink/WebKit doing it, is that the template-contents document won't update its flag after it's set on construction, whereas if it's passed in it could potentially change over time. I don't know if that actually happens in practice though.

[annevk]

I think it would work because the template element would get a new appropriate template contents owner document when it gets adopted elsewhere so it would remain in sync with the template element's node document so to speak. (And the parser currently always operates on a single document. And the fragment parser allocates a new document per the HTML standard, though this doesn't happen in implementations either as an optimization.)

However, for #2142 we are pretty sure we have to formalize making these parser settings that are not bound to the document as we want multiple parsers to operate on the same document. @foolip and @noamr are working on that so maybe they can solve this at the same time.