Re: [webcomponents]: Platonic form of custom elements declarative syntax

> mistake to make element registration a concern of <template>.

Raf: does that include making a new type 'element' which is a subtype of
'template', which is specifically given this concern?

> stamp out light DOM is a new semantic

This is true, it sort of appeared organically and we haven't wrestled with
it enough. We have discussed it though.

There are many libraries that use this kind of technique today, and it has
a lot of appeal because it's an easier way to on-ramp people into
web-components without hitting them over the head with shadow dom right
away.

There was originally some zeal that this would solve inheritance issues wrt
declarative shadow dom, but all it really does is shift the problems around.


On Wed, Apr 10, 2013 at 2:47 PM, Rafael Weinstein <rafaelw@google.com>wrote:

> On Wed, Apr 10, 2013 at 2:45 PM, Rafael Weinstein <rafaelw@google.com>
> wrote:
> > FWIW, I think it's a design mistake to make element registration a
> > concern of <template>.
>
> Sorry. I over-stated my conviction here. Let me walk that back: I'm
> not yet hearing sufficient justification for making element
> registration a concern of <template>
>
> >
> > I'd be more persuaded by the developer ergonomics argument if this was
> > a cost that was incurred with the usage of custom elements, but it's
> > not. It's only incurred with the element definition.
> >
> > Separately, I may have missed it, but it seems to me that allowing
> > custom elements to stamp out light DOM is a new semantic, that isn't
> > obviously solving a problem which is either identified, or related to
> > web components. Did I miss earlier discussion about this?
> >
> > On Wed, Apr 10, 2013 at 12:40 PM, Scott Miles <sjmiles@google.com>
> wrote:
> >> No, strictly ergonomic. Less nesting and less characters (less nesting
> is
> >> more important IMO).
> >>
> >> I would also argue that there is less cognitive load on the author then
> the
> >> more explicit factoring, but I believe this is subjective.
> >>
> >> Scott
> >>
> >>
> >> On Wed, Apr 10, 2013 at 12:36 PM, Rafael Weinstein <rafaelw@google.com>
> >> wrote:
> >>>
> >>> On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov <dglazkov@google.com
> >
> >>> wrote:
> >>> > Dear Webappsonites,
> >>> >
> >>> > There's been a ton of thinking on what the custom elements
> declarative
> >>> > syntax must look like. Here, I present something has near-ideal
> >>> > developer ergonomics at the expense of terrible sins in other areas.
> >>> > Consider it to be beacon, rather than a concrete proposal.
> >>> >
> >>> > First, let's cleanse your palate. Forget about the <element> element
> >>> > and what goes inside of it. Eat some parsley.
> >>> >
> >>> > == Templates Bound to Tags ==
> >>> >
> >>> > Instead, suppose you only have a <template>:
> >>> >
> >>> > <template>
> >>> >     <div>Yay!</div>
> >>> > </template>
> >>> >
> >>> > Templates are good for stamping things out, right? So let's invent a
> >>> > way to _bind_ a template to a _tag_. When the browser sees a tag to
> >>> > which the template is bound, it stamps the template out. Like so:
> >>> >
> >>> > 1) Define a template and bind it to a tag name:
> >>> >
> >>> > <template bindtotagname="my-yay">
> >>> >     <div>Yay!</div>
> >>> > </template>
> >>> >
> >>> > 2) Whenever <my-yay> is seen by the parser or
> >>> > createElement/NS("my-yay") is called, the template is stamped out to
> >>> > produce:
> >>> >
> >>> > <my-yay>
> >>> >     <div>Yay!</div>
> >>> > </my-yay>
> >>> >
> >>> > Cool! This is immediately useful for web developers. They can
> >>> > transform any markup into something they can use.
> >>> >
> >>> > Behind the scenes: the presence of "boundtotagname" triggers a call
> to
> >>> > document.register, and the argument is a browser-generated prototype
> >>> > object whose readyCallback takes the template and appends it to
> >>> > "this".
> >>> >
> >>> > == Organic Shadow Trees  ==
> >>> >
> >>> > But what if they also wanted to employ encapsulation boundaries,
> >>> > leaving initial markup structure intact? No problem, much-maligned
> >>> > <shadowroot> to the rescue:
> >>> >
> >>> > 1) Define a template with a shadow tree and bind it to a tag name:
> >>> >
> >>> > <template bindtotagname="my-yay">
> >>> >     <shadowroot>
> >>> >         <div>Yay!</div>
> >>> >     </shadowroot>
> >>> > </template>
> >>> >
> >>> > 2) For each <my-yay> created, the template is stamped out to create a
> >>> > shadow root and populate it.
> >>> >
> >>> > Super-cool! Note, how the developer doesn't have to know anything
> >>> > about Shadow DOM to build custom elements (er, template-bound tags).
> >>> > Shadow trees are just an option.
> >>> >
> >>> > Behind the scenes: exactly the same as the first scenario.
> >>> >
> >>> > == Declarative Meets Imperative ==
> >>> >
> >>> > Now, the developer wants to add some APIs to <my-yay>. Sure, no
> problem:
> >>> >
> >>> > <template bindtotagname="my-yay">
> >>> >     <shadowroot>
> >>> >         <div>Yay!</div>
> >>> >     </shadowroot>
> >>> >     <script runwhenbound>
> >>> >         // runs right after document.register is triggered
> >>> >         this.register(ExactSyntaxTBD);
> >>> >     <script>
> >>> > </template
> >>> >
> >>> > So-cool-it-hurts! We built a fully functional custom element, taking
> >>> > small steps from an extremely simple concept to the full-blown thing.
> >>> >
> >>> > In the process, we also saw a completely decoupled shadow DOM from
> >>> > custom elements in both imperative and declarative forms, achieving
> >>> > singularity. Well, or at least a high degree of consistence.
> >>> >
> >>> > == Problems ==
> >>> >
> >>> > There are severe issues.
> >>> >
> >>> > The <shadowroot> is turning out to be super-magical.
> >>> >
> >>> > The "bindtotagname" attribute will need to be also magical, to be
> >>> > consistent with how document.register could be used.
> >>> >
> >>> > The "stamping out", after clearly specified, may raise eyebrows and
> >>> > turn out to be unintuitive.
> >>> >
> >>> > Templates are supposed to be inert, but the whole <script
> >>> > runwhenbound> thing is strongly negating this. There's probably more
> >>> > that I can't remember now.
> >>>
> >>> The following expresses the same semantics:
> >>>
> >>> <element tagname="my-yay">
> >>>   <template>
> >>>     <shadowroot>
> >>>       <div>Yay!</div>
> >>>     </shadowroot>
> >>>   </template>
> >>>   <script runwhenbound>
> >>>   </script>
> >>> </element>
> >>>
> >>> I get that your proposal is fewer characters to type. Are there other
> >>> advantages?
> >>>
> >>> >
> >>> > == Plea ==
> >>> >
> >>> > However, I am hopeful that you smart folk will look at this, see the
> >>> > light, tweak the idea just a bit and hit the homerun. See the light,
> >>> > dammit!
> >>> >
> >>> > :DG<
> >>
> >>
>