Clarify that declarative custom element definitions don't contain declarative shadow roots.

[justinfagnani]

The current Declarative Custom Elements Strawman was authored before Declarative Custom Elements was specified, and the pattern of putting shadow root instance options on the <template> element. Now that that pattern does exist, it has created something of an semantic ambiguity with the strawman syntax. (with the assumption that shadowmode should be updated to shadowrootmode).

In this example, is <template shadowmode="open"> intended to do?

<definition name="my-element" constructor="MyElement">
    <template shadowmode="open">~</template>
</definition>

Does it:

1. Create a shadow root on the <definition> element
2. Define a template with options to be used to initialize instance shadow roots.

If the answer is (2), then we have the same syntax with two different behaviors: one creates a shadow root instance, one defines future shadow roots.

Since the strawman was created before DSD, it doesn't seem like this collision was intended. I think to separate DSD from declarative custom elements, even just in this strawman syntax, we should make a small edit to put the options on a new element. This has the benefit of shortening the option names by not requiring the shadowroot prefix on every one.

<definition name="my-element" constructor="MyElement">
    <shadowoptions mode="open"></shadowoptions>
    <template>~</template>
</definition>

cc @rniwa

[sashafirsov]

<shadowoptions mode="open"></shadowoptions> given an impression that multiple modes can be applied to the DCD.

Alternatively mode placed on <template> or <definition> is always unique. Which IMO is preferred to avoid potential mistakes and validation ambiguity.

[trusktr]

@sashafirsov the rule could be only one <shadowoptions> element is allowed (any more are ignored).

[sashafirsov]

@trusktr

the rule could be only one element is allowed (any more are ignored).

which creates ambiguity as on implementor' side( last or first to be used?) as for web app developer. Better to avoid that. Attributes been created exactly for the case when only one key is permitted.

[JRJurman]

@justinfagnani - I think this makes sense, but did you have an idea of what the behavior should be when this <shadowoptions> is missing? Is there a default behavior expected, or should we fail to build the component if these options aren't defined?