Re: Why can't we just use constructor instead of createdCallback?

[Adam Klein]

On Tue, Feb 18, 2014 at 3:26 PM, Dimitri Glazkov  wrote:
> On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking  wrote:
> > On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov  
> > wrote:
> > > The thing that really bothers me is that this approach is contradicting
> > > itself. We go to into pretty elaborate lengths to enable running
> > > constructors during parsing, but the key performance lesson developers 
> > > will
> > > immediately learn is to avoid constructors on custom elements, because 
> > > they
> > > will trigger the two-phase code path during parsing. Here's a thing that 
> > > you
> > > can use, but you probably don't want to ever use it.
> >
> > The above paragraph appears to assume that creating this list is slow.
> > Do you have data to back that up?
>
> No, of course not :) It's a first intuitive reaction.

One example that seems intuitively problematic about this approach (to
me, anyway) are those parts of the parser that inspect the tree during
parsing: foster parenting. I'm not sure it's a performance issue so
much as a complexity issue. Consider:


  

  

When following the spec
(http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#appropriate-place-for-inserting-a-node),
any text in that algorithm which says "parent node" need to be patched
to say something about this new list of to-be-attached nodes.

Patching all such references seems likely to be difficult and
error-prone, but I admit that I can't quantify those worries.

- Adam

[Bug 24658] [imports]: The fetch readiness shouldn't block fetching.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24658

Morrita Hajime  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Morrita Hajime  ---
See
https://github.com/w3c/webcomponents/commit/220b817d705f483b978b765f24244287d8ca28f9
and following changes.
I should've done this in branch to make the diff easy to read :-(

This is an attempt to reduce blocking.

The main changes are:

- Now the import dependencies are explained as a DAG.
  The dependency for each import is explicitly spec-ed as "import dependent" 
  using the DAG topology.

- The "import fetching" algorithm no longer spins until unblock.
  Only place to spin is before 

Re: Why can't we just use constructor instead of createdCallback?

[Dimitri Glazkov]

On Tue, Feb 18, 2014 at 2:59 PM, Jonas Sicking  wrote:

> On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov 
> wrote:
> >
> >
> >
> > On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking  wrote:
> >>
> >>
> >> What I mean is that for nodes that doesn't have a constructor, and
> >> whose parent doesn't have a constructor, no need to add them to the
> >> above arrays. Just insert them into their parent. That means that when
> >> that the constructor of an element runs, the element doesn't have any
> >> parents or children.
> >>
> >> So no need to hide parents or children anywhere.
> >
> >
> > Okay, let me see if I got this right. The list is effectively a
> serialized
> > representation of a document subtree. The parent + order in the list
> > provides all the necessary information. We use this list to separate tree
> > construction into two stages: one before custom element constructors are
> > called, and one after.
>
> Yes
>
> > In cases when the custom element is just a like button widget (a leaf in
> the
> > tree), the list is short and just contains the widgets.
>
> Yes
>
> > In cases like " ... the entire doc tree ...
> > ", the list contains the entire subtree of ,
> which
> > is effectively the document.
>
> Well. With the optimization I mentioned you only need to make the
>  element and it's immediate children into the list. Any
> grand-children of  can immediately be inserted into their
> parent.
>
> So I guess you could say that the list contains basically the whole
> document. But most nodes would only indirectly be in the list. I.e.
> the list would be short, but each entry could contain large subtrees.
>
> > In cases like ". ... more siblings
> > ... ", the list will contain at least all siblings of ,
> > because they can't be inserted into tree until after 's
> constructor
> > runs.
>
> Yes
>
> > When run, the constructors are free to explore the partially-completed
> tree,
> > which enables interesting hacks like this:
> >
> > in document:
> >  lots more markup...
> >
> > in my-bar constructor:
> > var myFutureParent = document.querySelector("#a");
> > // redirect tree construction to resume at a new point.
> > document.body.appendChild(myFutureParent);
> >
> > Or, in my-bar constructor:
> > var myFutureParent = document.querySelector("#a");
> > var iframe = document.body.appendChild(document.createElement("iframe"));
> > // teleport the tree into another frame
> > iframe.contentDocument.body.appendChild(myFutureParent);
>
> Yup
>
> > I can't immediately tell whether these hacks are cool or scary.
>
> You can already do exactly this with 

Re: Why can't we just use constructor instead of createdCallback?

[Erik Arvidsson]

On Tue, Feb 18, 2014 at 5:59 PM, Jonas Sicking  wrote:

> On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov 
> wrote:
> >
> >
> >
> > On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking  wrote:
> >>
> >>
> >> What I mean is that for nodes that doesn't have a constructor, and
> >> whose parent doesn't have a constructor, no need to add them to the
> >> above arrays. Just insert them into their parent. That means that when
> >> that the constructor of an element runs, the element doesn't have any
> >> parents or children.
> >>
> >> So no need to hide parents or children anywhere.
> >
> >
> > Okay, let me see if I got this right. The list is effectively a
> serialized
> > representation of a document subtree. The parent + order in the list
> > provides all the necessary information. We use this list to separate tree
> > construction into two stages: one before custom element constructors are
> > called, and one after.
>
> Yes
>
> > In cases when the custom element is just a like button widget (a leaf in
> the
> > tree), the list is short and just contains the widgets.
>
> Yes
>
> > In cases like " ... the entire doc tree ...
> > ", the list contains the entire subtree of ,
> which
> > is effectively the document.
>
> Well. With the optimization I mentioned you only need to make the
>  element and it's immediate children into the list. Any
> grand-children of  can immediately be inserted into their
> parent.
>
> So I guess you could say that the list contains basically the whole
> document. But most nodes would only indirectly be in the list. I.e.
> the list would be short, but each entry could contain large subtrees.
>

Would that cause issues with the order of the mutation record reported by
mutation observers?


>
> > In cases like ". ... more siblings
> > ... ", the list will contain at least all siblings of ,
> > because they can't be inserted into tree until after 's
> constructor
> > runs.
>
> Yes
>
> > When run, the constructors are free to explore the partially-completed
> tree,
> > which enables interesting hacks like this:
> >
> > in document:
> >  lots more markup...
> >
> > in my-bar constructor:
> > var myFutureParent = document.querySelector("#a");
> > // redirect tree construction to resume at a new point.
> > document.body.appendChild(myFutureParent);
> >
> > Or, in my-bar constructor:
> > var myFutureParent = document.querySelector("#a");
> > var iframe = document.body.appendChild(document.createElement("iframe"));
> > // teleport the tree into another frame
> > iframe.contentDocument.body.appendChild(myFutureParent);
>
> Yup
>
> > I can't immediately tell whether these hacks are cool or scary.
>
> You can already do exactly this with 

Re: Why can't we just use constructor instead of createdCallback?

[Jonas Sicking]

On Tue, Feb 18, 2014 at 10:35 AM, Dimitri Glazkov  wrote:
>
>
>
> On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking  wrote:
>>
>>
>> What I mean is that for nodes that doesn't have a constructor, and
>> whose parent doesn't have a constructor, no need to add them to the
>> above arrays. Just insert them into their parent. That means that when
>> that the constructor of an element runs, the element doesn't have any
>> parents or children.
>>
>> So no need to hide parents or children anywhere.
>
>
> Okay, let me see if I got this right. The list is effectively a serialized
> representation of a document subtree. The parent + order in the list
> provides all the necessary information. We use this list to separate tree
> construction into two stages: one before custom element constructors are
> called, and one after.

Yes

> In cases when the custom element is just a like button widget (a leaf in the
> tree), the list is short and just contains the widgets.

Yes

> In cases like " ... the entire doc tree ...
> ", the list contains the entire subtree of , which
> is effectively the document.

Well. With the optimization I mentioned you only need to make the
 element and it's immediate children into the list. Any
grand-children of  can immediately be inserted into their
parent.

So I guess you could say that the list contains basically the whole
document. But most nodes would only indirectly be in the list. I.e.
the list would be short, but each entry could contain large subtrees.

> In cases like ". ... more siblings
> ... ", the list will contain at least all siblings of ,
> because they can't be inserted into tree until after 's constructor
> runs.

Yes

> When run, the constructors are free to explore the partially-completed tree,
> which enables interesting hacks like this:
>
> in document:
>  lots more markup...
>
> in my-bar constructor:
> var myFutureParent = document.querySelector("#a");
> // redirect tree construction to resume at a new point.
> document.body.appendChild(myFutureParent);
>
> Or, in my-bar constructor:
> var myFutureParent = document.querySelector("#a");
> var iframe = document.body.appendChild(document.createElement("iframe"));
> // teleport the tree into another frame
> iframe.contentDocument.body.appendChild(myFutureParent);

Yup

> I can't immediately tell whether these hacks are cool or scary.

You can already do exactly this with 

Re: Why can't we just use constructor instead of createdCallback?

[Ryosuke Niwa]

On Feb 18, 2014, at 10:35 AM, Dimitri Glazkov  wrote:
> On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking  wrote:
> 
> What I mean is that for nodes that doesn't have a constructor, and
> whose parent doesn't have a constructor, no need to add them to the
> above arrays. Just insert them into their parent. That means that when
> that the constructor of an element runs, the element doesn't have any
> parents or children.
> 
> So no need to hide parents or children anywhere.
> 
> Okay, let me see if I got this right. The list is effectively a serialized 
> representation of a document subtree. The parent + order in the list provides 
> all the necessary information. We use this list to separate tree construction 
> into two stages: one before custom element constructors are called, and one 
> after.
> 
> In cases when the custom element is just a like button widget (a leaf in the 
> tree), the list is short and just contains the widgets.
> 
> In cases like " ... the entire doc tree ... 
> ", the list contains the entire subtree of , which is 
> effectively the document.
> 
> In cases like ". ... more siblings ... 
> ", the list will contain at least all siblings of , because 
> they can't be inserted into tree until after 's constructor runs.
> 
> When run, the constructors are free to explore the partially-completed tree, 
> which enables interesting hacks like this:
> 
> in document:
>  lots more markup...
> 
> in my-bar constructor:
> var myFutureParent = document.querySelector("#a");
> // redirect tree construction to resume at a new point.
> document.body.appendChild(myFutureParent);
> 
> Or, in my-bar constructor:
> var myFutureParent = document.querySelector("#a");
> var iframe = document.body.appendChild(document.createElement("iframe"));
> // teleport the tree into another frame
> iframe.contentDocument.body.appendChild(myFutureParent);

You can already do this in a regular script element so this isn't a new issue 
custom element's constructor is introducing.


> The thing that really bothers me is that this approach is contradicting 
> itself. We go to into pretty elaborate lengths to enable running constructors 
> during parsing, but the key performance lesson developers will immediately 
> learn is to avoid constructors on custom elements, because they will trigger 
> the two-phase code path during parsing. Here's a thing that you can use, but 
> you probably don't want to ever use it.

Have you tried implementing this and found that you can't implement it 
efficiently?  Could you quantify the runtime or memory cost?

> Here's an alternative proposal:
> 
> 1) The Web developers are already aware of the fact that you can create new 
> instances of JS objects without running their constructors with Object.create
> 
> 2) Let's make sure that when they call constructors directly (as in var b = 
> new MyB(arg1,arg2);), the constructor is actually called.
> 
> 3) When the parser instantiates the element, it does the equivalent of 
> Object.create, so no constructor is called.

I don't see why we want to make the edge case like the one you described above 
prevent us from making common cases easy to use and understand.

Just call constructor whenever a custom element is created.  If you're doing 
weird stuff in constructor, then weird things happen.

- R. Niwa

Re: [webcomponents] Switch for Selection Isolation

[Kenji Baheux]

Hi,

I've been thinking more about selection, and I think we need a flag/switch
> to indicate whether we want a isolated selection or not
> since it's highly desirable to have a separate selection for creating
> custom form controls like input, text area,


Would you mind elaborating what you mean by "isolated selection" and its
opposite?
Additionally, concrete use cases + expectations for both the with and
without isolated selection would be extremely helpful.


Best,



-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan

Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

[Alex Russell]

On Tue, Feb 18, 2014 at 4:59 AM, Arthur Barstow wrote:

> On 2/17/14 9:17 AM, ext Jungkee Song wrote:
>
>  On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow 
> > art.bars...@nokia.com>> wrote:
>>
>> The only process requirement for a FPWD is that the group record
>> consensus to publish it. However, it's usually helpful if the FPWD
>> is feature complete from a breadth perspective but there is no
>> expectation the FPWD is complete from a depth perspective. As
>> such, if there are missing features, it would be good to mention
>> that in the ED and/or file related bugs.
>>
>> I believe things are mostly addressed in a breadth perspective albeit
>> quite a few issues are still being discussed and sorted out. We are
>> currently drafting the ED and thought the F2F is sort of a right time to
>> have a consensus for FPWD but think it'll be nicer if we can make it even
>> before that to get a wider review as soon as possible.
>>
>
> Given the broad interest in this spec, I think it would be helpful to move
> toward FPWD "as soon as possible". Would you please give a "rough
> guestimate" on when you think spec can ready for a CfC to publish a FPWD?
>

I've been waiting until we have all the algorithms filled in. It's a
non-sensical document until then.

Re: Why can't we just use constructor instead of createdCallback?

[Dimitri Glazkov]

On Tue, Feb 18, 2014 at 11:24 AM, Erik Arvidsson  wrote:

>
> On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov wrote:
>
>> Here's an alternative proposal:
>>
>> 1) The Web developers are already aware of the fact that you can create
>> new instances of JS objects without running their constructors with
>> Object.create
>>
>
> These are not the instances you are looking for.
>
> We need to have real instances here. @@create gives us the semantics for
> doing this.
>

Ah, yes. Sorry :)


>
>
>> 2) Let's make sure that when they call constructors directly (as in var b
>> = new MyB(arg1,arg2);), the constructor is actually called.
>>
>> 3) When the parser instantiates the element, it does the equivalent of
>> Object.create, so no constructor is called.
>>
>
> That would not set the internal state as needed. It would not know how to
> associate the instance object with the C++ backing object for example.
> Also, all the DOM methods are using brand checks (and not instanceof
> checks) so the brand needs to be setup as well.
>
> The solution is to call `MyElement[Symbol.create]()` which would setup the
> internal state as needed. We can make this non writable, non configurable
> which allows the implementation to skip calling any js code at that point
> because the semantics is unobservable.
>
>
>> It seems simple and easy to understand.
>>
>
> With ES6 it is possible to create instance objects without ever calling
> the constructor (this is NOT possible in ES5) so maybe we should just give
> up on having the parser calling the constructor?
>

Sounds good to me.

:DG<

Re: Why can't we just use constructor instead of createdCallback?

[Erik Arvidsson]

On Tue, Feb 18, 2014 at 1:35 PM, Dimitri Glazkov wrote:

> Here's an alternative proposal:
>
> 1) The Web developers are already aware of the fact that you can create
> new instances of JS objects without running their constructors with
> Object.create
>

These are not the instances you are looking for.

We need to have real instances here. @@create gives us the semantics for
doing this.


> 2) Let's make sure that when they call constructors directly (as in var b
> = new MyB(arg1,arg2);), the constructor is actually called.
>
> 3) When the parser instantiates the element, it does the equivalent of
> Object.create, so no constructor is called.
>

That would not set the internal state as needed. It would not know how to
associate the instance object with the C++ backing object for example.
Also, all the DOM methods are using brand checks (and not instanceof
checks) so the brand needs to be setup as well.

The solution is to call `MyElement[Symbol.create]()` which would setup the
internal state as needed. We can make this non writable, non configurable
which allows the implementation to skip calling any js code at that point
because the semantics is unobservable.


> It seems simple and easy to understand.
>

With ES6 it is possible to create instance objects without ever calling the
constructor (this is NOT possible in ES5) so maybe we should just give up
on having the parser calling the constructor?


-- 
erik

Re: Why can't we just use constructor instead of createdCallback?

[Dimitri Glazkov]

On Fri, Feb 14, 2014 at 3:58 PM, Jonas Sicking  wrote:

>
> What I mean is that for nodes that doesn't have a constructor, and
> whose parent doesn't have a constructor, no need to add them to the
> above arrays. Just insert them into their parent. That means that when
> that the constructor of an element runs, the element doesn't have any
> parents or children.
>
> So no need to hide parents or children anywhere.
>

Okay, let me see if I got this right. The list is effectively a serialized
representation of a document subtree. The parent + order in the list
provides all the necessary information. We use this list to separate tree
construction into two stages: one before custom element constructors are
called, and one after.

In cases when the custom element is just a like button widget (a leaf in
the tree), the list is short and just contains the widgets.

In cases like " ... the entire doc tree ...
", the list contains the entire subtree of , which
is effectively the document.

In cases like ". ... more siblings
... ", the list will contain at least all siblings of ,
because they can't be inserted into tree until after 's constructor
runs.

When run, the constructors are free to explore the partially-completed
tree, which enables interesting hacks like this:

in document:
 lots more markup...

in my-bar constructor:
var myFutureParent = document.querySelector("#a");
// redirect tree construction to resume at a new point.
document.body.appendChild(myFutureParent);

Or, in my-bar constructor:
var myFutureParent = document.querySelector("#a");
var iframe = document.body.appendChild(document.createElement("iframe"));
// teleport the tree into another frame
iframe.contentDocument.body.appendChild(myFutureParent);

I can't immediately tell whether these hacks are cool or scary.

The thing that really bothers me is that this approach is contradicting
itself. We go to into pretty elaborate lengths to enable running
constructors during parsing, but the key performance lesson developers will
immediately learn is to avoid constructors on custom elements, because they
will trigger the two-phase code path during parsing. Here's a thing that
you can use, but you probably don't want to ever use it.

Here's an alternative proposal:

1) The Web developers are already aware of the fact that you can create new
instances of JS objects without running their constructors with
Object.create

2) Let's make sure that when they call constructors directly (as in var b =
new MyB(arg1,arg2);), the constructor is actually called.

3) When the parser instantiates the element, it does the equivalent of
Object.create, so no constructor is called.

It seems simple and easy to understand.

:DG<

Re: "Officially" deprecating main-thread synchronous XHR?

[Scott González]

I believe Beacon will address the use cases for developers currently using
sync XHR in beforeunload/unload/pagehide. I don't think any browser should
warn about sync XHR in these cases until they support Beacon.

I've discussed this will Olli in IRC, but I've been pushing for jQuery to
deprecate jQuery.ajax() and replace it with transport-specific methods such
as jQuery.xhr() and jQuery.jsonp(). jQuery.xhr() would not have support for
sync requests. After a few years of pushing for this, it looks like it
might finally happen. This would go a long way toward evangelizing the
avoidance of sync requests.


On Fri, Feb 7, 2014 at 12:38 PM, Boris Zbarsky  wrote:

> On 2/7/14 12:32 PM, Scott González wrote:
>
>> What about developers who are sending requests as the page is unloading?
>>
>
> Does Beacon address their use cases?  If not, what are the use cases?
>
> -Boris
>
>

Re: Clipboard API: Enable `copy` event simulation with user's express permission (domain-wide)?

[Hallvord R. M. Steen]

So, the story so far is that the spec has added something it labels 
"semi-trusted events" - that is an event triggered from a trusted event of a 
whitelisted type. The precedence here is popup blocking - browsers already have 
rules for which events are "more trusted than others" in terms of likely 
expressing user intent. (An example makes this clearer: scripts are typically 
allowed to call window.open() from a click event listener, but are typically 
not allowed to call window.open() from an load or mouseover listener.)

However..

> Also, will there be any way for us to feature detect when this is available?

I've still not really been able to come up with a nice way to feature detect 
these "semi-trusted events".

Good ideas requested and appreciated..

> I'm thinking that just using `document.queryCommandSupported("copy")` and
> `document.queryCommandEnabled("copy")` could return some false positives
> (i.e. the feature is not yet implemented but returns `true` anyway) when
> the user is working within a "contenteditable" element, right?

No idea what the current implementation state of these calls are..
-Hallvord

Re: WebKit interest in ServiceWorkers (was Re: [manifest] Utility of bookmarking to home screen, was V1 ready for wider review)

[Arthur Barstow]

On 2/17/14 9:17 AM, ext Jungkee Song wrote:
On Mon, Feb 17, 2014 at 9:38 PM, Arthur Barstow > wrote:


The only process requirement for a FPWD is that the group record
consensus to publish it. However, it's usually helpful if the FPWD
is feature complete from a breadth perspective but there is no
expectation the FPWD is complete from a depth perspective. As
such, if there are missing features, it would be good to mention
that in the ED and/or file related bugs. 



I believe things are mostly addressed in a breadth perspective albeit 
quite a few issues are still being discussed and sorted out. We are 
currently drafting the ED and thought the F2F is sort of a right time 
to have a consensus for FPWD but think it'll be nicer if we can make 
it even before that to get a wider review as soon as possible.


Given the broad interest in this spec, I think it would be helpful to 
move toward FPWD "as soon as possible". Would you please give a "rough 
guestimate" on when you think spec can ready for a CfC to publish a FPWD?


-Thanks, ArtB

Re: [webcomponents] Imperative API for Insertion Points

[Erik Bryn]

On Mon, Feb 17, 2014 at 11:03 AM, Edward O'Connor wrote:

> I think Ryosuke's .add/remove are a better base layer than
> . In fact,  is straightforwardly
> implementable / explainable on top of MO + .add/remove, but
> there are several use cases that .add/remove address that are
> difficult or impossible with  (as described in Maciej's
> recent email on this thread).
>

I agree. As a contributor to a major JS framework, I was shocked by the
lack of an imperative API and that  was even a thing.

- Erik

[Bug 24708] New: [Shadow]: Wrong spelling

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24708

Bug ID: 24708
   Summary: [Shadow]: Wrong spelling
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: dh20...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

"The folowing set of relationships hold in the figure:"

-- 
You are receiving this mail because:
You are on the CC list for the bug.