- From: Daniel Buchner <daniel@mozilla.com>
- Date: Wed, 10 Apr 2013 13:38:23 -0700
- To: Rick Waldron <waldron.rick@gmail.com>
- Cc: Scott Miles <sjmiles@google.com>, Rafael Weinstein <rafaelw@google.com>, Dimitri Glazkov <dglazkov@google.com>, public-webapps <public-webapps@w3.org>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>, Boris Zbarsky <bzbarsky@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Steve Orvell <sorvell@google.com>
- Message-ID: <CAHZ6zJEp_x6O9BKD0sbx0LvmyxicrOuUP2YLRETtp0PmUvdhhw@mail.gmail.com>
*What about CSP that forbids inline scripts?https://wiki.mozilla.org/Apps/Security#Default_CSP_policy * Is there any reason developers wouldn't just modify the script tag under either method proposed to use src="link-to-non-inline-script" to satisfy CSP requirements? The proposal I submitted certainly doesn't exclude that ability/use case (or so I thought - correct if wrong) Daniel J. Buchner Product Manager, Developer Ecosystem Mozilla Corporation On Wed, Apr 10, 2013 at 1:27 PM, Rick Waldron <waldron.rick@gmail.com>wrote: > > > > On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner <daniel@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 <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< >>>> >>> >>> >> >
Received on Wednesday, 10 April 2013 20:39:22 UTC