On Apr 11, 2013, at 12:04 PM, Boris Zbarsky wrote:
> On 4/11/13 12:55 PM, Boris Zbarsky wrote:
>> On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote:
>>> Yes ES6 has "class-side" inheritance
>>
>> OK. Should we be doing that with WebIDL interface objects, perhaps? It
>> would certainly make sense to
On 4/11/13 12:55 PM, Boris Zbarsky wrote:
On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote:
Yes ES6 has "class-side" inheritance
OK. Should we be doing that with WebIDL interface objects, perhaps? It
would certainly make sense to me to do that, as long we we don't run
into web compat issues.
I
On 4/11/13 12:50 PM, Allen Wirfs-Brock wrote:
Yes ES6 has "class-side" inheritance
OK. Should we be doing that with WebIDL interface objects, perhaps? It
would certainly make sense to me to do that, as long we we don't run
into web compat issues.
-Boris
ES6 defines class side inheritance. We should update WebIDL to do the same
to align them.
On Thu, Apr 11, 2013 at 12:50 PM, Allen Wirfs-Brock
wrote:
>
> On Apr 11, 2013, at 9:32 AM, Boris Zbarsky wrote:
>
> > On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote:
> >> So why don't you make "register" a st
On Apr 11, 2013, at 9:32 AM, Boris Zbarsky wrote:
> On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote:
>> So why don't you make "register" a static method on HTMLElement and then
>> define the semantics so it automatically does:
>> MyElement.register()
>>
>> This would normally invoke the inheri
On 4/11/13 12:23 PM, Allen Wirfs-Brock wrote:
So why don't you make "register" a static method on HTMLElement and then
define the semantics so it automatically does:
MyElement.register()
This would normally invoke the inherited static method
I lost track of something here. Why would it
On Thu, Apr 11, 2013 at 7:57 AM, Erik Arvidsson wrote:
> The problem here is how do you register `My_yay` as the class that goes
> with the tag name `my_yay`. One option could be to use the completion
> value but it seems too magical/unreliable. It also does not scale well. I
> would like us to b
Hi Allen,
Fortunately the state of this is pretty close to what you are suggesting.
We started of with the imperative solution and then went to look at a
declarative version. At this point, the discussion got a bit side tracked.
Lets back up and see what we have for the imperative version:
class
*"Shouldn't we prevent such a thing? I can't redefine a 's
"template. There should be some guarantee I'm getting the same
(API, look and feel) after it's been registered. What's the use case for
swapping in a new template?"*
We've come across various occasions where we have a custom element, let
Have to lean towards Raf and Daniel on this one. Making a element
registation a concern of doesn't feel right. In this case, explicit
structure and a few more characters is worth it.
On Wed, Apr 10, 2013 at 9:00 PM, Daniel Buchner wrote:
> It's incredibly important that we agree that associatio
cc Allen Wirfs-Brock, Dave Herman
Allen, Dave
Would you mind reading back through the thread to provide some deeper
insight? Thanks
Rick
On Wednesday, April 10, 2013, Daniel Buchner wrote:
> Here are a few (compelling?) answers/arguments:
>
>1. Style elements had never done this before,
On Wed, Apr 10, 2013 at 6:38 PM, Rick Waldron wrote:
> Everyone's answer to this should be "no"; changing the expected value of the
> top level "this", in some magical way, simply won't work.
Can you explain why you feel this way?
:DG<
Here are a few (compelling?) answers/arguments:
1. Style elements had never done this before, yet it rocks socks:
It's incredibly important that we agree that association of a
with happens on the element side, something like: (or by placing the template inside element, if
that is the API we want). I don't think this part is opinion, but because
doing the reverse - marking on the which it refers to
- hinde
On Wed, Apr 10, 2013 at 8:19 PM, Daniel Buchner wrote:
> Here are a few (compelling?) answers/arguments:
>
>1. Style elements had never done this before, yet it rocks socks:
>
On Wed, Apr 10, 2013 at 3:30 PM, Daniel Buchner wrote:
> @John - in my opinion, is the wrong
> direction. You should be declaring which *template* an *element* uses, not
> which element a template captures. Having templates latch onto element
> types from afar breaks the one-to-many case, preven
> how that specific script tag knows what its "this" value is
I think I'm probably not answering your question, but I believe the notion
was that that script tag is handled specially by , so it's a
> mistake to make element registration a concern of .
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
On Wed, Apr 10, 2013 at 5:35 PM, Daniel Buchner wrote:
> One thing I'm wondering re elements and the association of a
> specific script with them, is what is it really doing for me? From what I
> see, not much. It seems the only thing it does, is allows you to have the
> generic, globally-scoped
On Wed, Apr 10, 2013 at 2:45 PM, Rafael Weinstein wrote:
> FWIW, I think it's a design mistake to make element registration a
> concern of .
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
FWIW, I think it's a design mistake to make element registration a
concern of .
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 m
One thing I'm wondering re elements and the association of a
specific script with them, is what is it really doing for me? From what I
see, not much. It seems the only thing it does, is allows you to have the
generic, globally-scoped script run at a given time (via a new runwhen___
attribute) and
On Wed, Apr 10, 2013 at 4:43 PM, Rick Waldron wrote:
> 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
>
+1
I'm not sure that `this` was supposed to be the [[Global]] object? But
agree with you, this is someth
On Wed, Apr 10, 2013 at 4:38 PM, Daniel Buchner 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-inlin
Averting thread-hijacking...
CSP is something we'll need to discuss with WebAppsSec peeps at the
upcoming F2F.
:DG<
-- Forwarded message --
From: Daniel Buchner
Date: Wed, Apr 10, 2013 at 1:38 PM
Subject: Re: [webcomponents]: Platonic form of custom elements
declarativ
*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 certa
On Wed, Apr 10, 2013 at 4:15 PM, Daniel Buchner 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:/
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
I can explain the advantages a bit more in an hour or so, I just got pulled
into a meeting...le sigh.
Daniel J. Buchn
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 wrote:
On Wed, Apr 10, 2013 at 11:47 AM, Dimitri Glazkov 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.
> Consi
Thank you for distilling all that down into digestible content (yum,
distillates).
A couple of notes:
The 'magic script' problem has been difficult to reconcile with ,
so there is willingness to continue to use , but ideally without
nesting . In other words, perhaps can be a subtype of
.
Where
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 c
32 matches
Mail list logo
