DCE Demo Discussions: HTML Modules and Declarative Custom Elements Proposal by Rob Eisenberg

[Westbrook]

As presented on 18 March to the WCCG, ideas, concepts, and possible API shapes for structuring a proposal to implementors with current and in-discussion APIs by @EisenbergEffect.

Links to gist TK as available.

Further discussion and questions below.

[JRJurman]

Love the write up and a lot of the detail in the doc.

I'm curious if you feel like the <view> would need to be constantly kept in-sync with DSD APIs, if we have examples of that elsewhere in the standard (where two elements have matching APIs), and if it would make more sense to have <view> have a <template> child element? e.g.

<element export id="HelloWorld">
  <view>
    <template shadowrootmode="none">
      Hello World!
    </template>
  </view>
</element>

Also, is <view> something you see exclusively in DCE? What is the interface here if we wanted to use it in a class-based implementation of a web component? Or outside of an element definition?

[EisenbergEffect]

This was a tricky area. I first thought to use template instead of view, but that didn't seem right because putting shadowrootmode on a template will create a DSD, which we don't want. We basically still want a template. Also, shadowrootmode=none doesn't make sense in any other context other than a DCE, so I didn't think we should add that option to a template.

More or less, that led me to pick a different element altogether, which means somewhat synchronizing the attributes with template and DSD in the future. Perhaps browser vendors can make template work a bit different when it's inside of element. If they can, then I would just get rid of view and switch it back to template. Basically, we need some sort of element to indicate both what should be rendered and the options for the light/shadow dom. I don't think that can be the host element, since it has its own options and non-rendered children. If template can be made to work, then I'd say go with that. If not, then I think view will make sense to people. Using something like shadowroot doesn't fit the light dom rendering scenario, which is why I didn't go that path.

I think adding template as a child of view would be overly verbose and have the same problems with DSD, which is why I introduced a view element in the first place. So, I'd want to avoid that.

My current thinking is that view also only makes sense in the context of an element. For anything else, you would just use template directly. While I haven't fleshed out the ideas yet, I think that we should probably have some way to declaratively render a template in HTML, in dependent of custom elements, potentially against data as well. I'll probably add that into my document once I get a bit more time to think through the various options.