On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner <dan...@mozilla.com> wrote:
> I have a counter proposal that takes into a count both the > easy-to-declare, 1-to-1 case, as well as the 1-template-to-many-elements > case: https://gist.github.com/csuwldcat/5358039 > What about CSP that forbids inline scripts? https://wiki.mozilla.org/Apps/Security#Default_CSP_policy Rick > > > I can explain the advantages a bit more in an hour or so, I just got > pulled into a meeting...le sigh. > > Daniel J. Buchner > Product Manager, Developer Ecosystem > Mozilla Corporation > > > On Wed, Apr 10, 2013 at 12:40 PM, Scott Miles <sjmi...@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 <rafa...@google.com>wrote: >> >>> On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov <dglaz...@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< >>> >> >> >
