On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner <dan...@mozilla.com> wrote:
> *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) > > There is nothing stopping that at all. A bigger issue with proposal is that the global object appears to be the element's instance object itself, which isn't going to work Rick > > Daniel J. Buchner > Product Manager, Developer Ecosystem > Mozilla Corporation > > > On Wed, Apr 10, 2013 at 1:27 PM, Rick Waldron <waldron.r...@gmail.com>wrote: > >> >> >> >> 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< >>>>> >>>> >>>> >>> >> >
