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

On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner <daniel@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.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<
>>>>>
>>>>
>>>>
>>>
>>
>