Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
> On Feb 26, 2016, at 3:36 PM, Elliott Sprehn wrote:
>
>
>
> On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa wrote:
>>
>> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn wrote:
>> >
>> >
>> >
>> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote:
>> >>
>> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn
>> >> > wrote:
>> >> >
>> >> > Can you give a code example of how this happens?
>> >>
>> >> For example, execCommand('Delete') would result in sequentially deleting
>> >> nodes as needed.
>> >> During this compound operation, unload events may fire on iframes that
>> >> got deleted by this operation.
>> >>
>> >> I would like components to be notified that they got removed/disconnected
>> >> from the document
>> >> before such an event is getting fired.
>> >>
>> >
>> > I'd rather not do that, all the sync script inside editing operations is a
>> > bug, and you shouldn't depend on the state of the world around you in
>> > there anyway since all browsers disagree (ex. not all of them fire the
>> > event sync).
>>
>> I don't think that's a bug given Safari, Chrome, and Gecko all fires unload
>> event before finishing the delete operation. It's an interoperable
>> behavior, which should be spec'ed.
>
> Firefox's behavior of when to fire unload definitely doesn't match Chrome or
> Safari, but maybe it does in this one instance. I don't think it's worth
> trying to get consistency there though, unload is largely a bug, we should
> add a new event and get people to stop using it.
I strongly disagree with the assessment and oppose to adding a new event.
>> Anyway, this was just an easy example I could come up with. There are many
>> other examples that involve DOM mutation events if you'd prefer seeing those
>> instead.
>
> I'm not interested in making using mutation events easier.
And I'm not interested in pushing your agenda to deprecate mutation events
either.
>> The fact of matter is that we don't live in the future, and it's better for
>> API to be consistent in this imperfect world than for it to have weird edge
>> cases. As a matter of fact, if you end up being able to kill those sync
>> events in the future, this will become non-issue since end-of-nano-task as
>> you (Google) proposed will happen before dispatching of any event.
>>
>> As things stand, however, we should dispatch lifecycle callbacks before
>> dispatching these (legacy but compat mandating) events.
>
> I disagree. Mutation events are poorly speced and not interoperably
> implemented across browsers. I don't think we should run nanotasks down there.
It doesn't matter how poorly things are spec'ed. The reality is that unload
events and DOM mutation events are required for Web compatibility, and as such,
should be considered when designing new API.
Anyhow, I'm going to invoke lifecycle callbacks before dispatching events in
WebKit for now since we can't seem to come to consensus on this matter.
- R. Niwa
Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa wrote:
>
> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn
> wrote:
> >
> >
> >
> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote:
> >>
> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn
> wrote:
> >> >
> >> > Can you give a code example of how this happens?
> >>
> >> For example, execCommand('Delete') would result in sequentially
> deleting nodes as needed.
> >> During this compound operation, unload events may fire on iframes that
> got deleted by this operation.
> >>
> >> I would like components to be notified that they got
> removed/disconnected from the document
> >> before such an event is getting fired.
> >>
> >
> > I'd rather not do that, all the sync script inside editing operations is
> a bug, and you shouldn't depend on the state of the world around you in
> there anyway since all browsers disagree (ex. not all of them fire the
> event sync).
>
> I don't think that's a bug given Safari, Chrome, and Gecko all fires
> unload event before finishing the delete operation. It's an interoperable
> behavior, which should be spec'ed.
>
Firefox's behavior of when to fire unload definitely doesn't match Chrome
or Safari, but maybe it does in this one instance. I don't think it's worth
trying to get consistency there though, unload is largely a bug, we should
add a new event and get people to stop using it.
>
> Anyway, this was just an easy example I could come up with. There are
> many other examples that involve DOM mutation events if you'd prefer seeing
> those instead.
>
I'm not interested in making using mutation events easier.
>
> The fact of matter is that we don't live in the future, and it's better
> for API to be consistent in this imperfect world than for it to have weird
> edge cases. As a matter of fact, if you end up being able to kill those
> sync events in the future, this will become non-issue since
> end-of-nano-task as you (Google) proposed will happen before dispatching of
> any event.
>
> As things stand, however, we should dispatch lifecycle callbacks before
> dispatching these (legacy but compat mandating) events.
>
I disagree. Mutation events are poorly speced and not interoperably
implemented across browsers. I don't think we should run nanotasks down
there.
- E
Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
> On Feb 26, 2016, at 3:22 PM, Elliott Sprehn wrote:
>
>
>
> On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote:
>>
>> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn wrote:
>> >
>> > Can you give a code example of how this happens?
>>
>> For example, execCommand('Delete') would result in sequentially deleting
>> nodes as needed.
>> During this compound operation, unload events may fire on iframes that got
>> deleted by this operation.
>>
>> I would like components to be notified that they got removed/disconnected
>> from the document
>> before such an event is getting fired.
>>
>
> I'd rather not do that, all the sync script inside editing operations is a
> bug, and you shouldn't depend on the state of the world around you in there
> anyway since all browsers disagree (ex. not all of them fire the event sync).
I don't think that's a bug given Safari, Chrome, and Gecko all fires unload
event before finishing the delete operation. It's an interoperable behavior,
which should be spec'ed.
Anyway, this was just an easy example I could come up with. There are many
other examples that involve DOM mutation events if you'd prefer seeing those
instead.
The fact of matter is that we don't live in the future, and it's better for API
to be consistent in this imperfect world than for it to have weird edge cases.
As a matter of fact, if you end up being able to kill those sync events in the
future, this will become non-issue since end-of-nano-task as you (Google)
proposed will happen before dispatching of any event.
As things stand, however, we should dispatch lifecycle callbacks before
dispatching these (legacy but compat mandating) events.
- R. Niwa
Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa wrote:
>
> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn
> wrote:
> >
> > Can you give a code example of how this happens?
>
> For example, execCommand('Delete') would result in sequentially deleting
> nodes as needed.
> During this compound operation, unload events may fire on iframes that got
> deleted by this operation.
>
> I would like components to be notified that they got removed/disconnected
> from the document
> before such an event is getting fired.
>
>
I'd rather not do that, all the sync script inside editing operations is a
bug, and you shouldn't depend on the state of the world around you in there
anyway since all browsers disagree (ex. not all of them fire the event
sync).
- E
Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
> On Feb 24, 2016, at 9:06 PM, Elliott Sprehn wrote:
>
> Can you give a code example of how this happens?
For example, execCommand('Delete') would result in sequentially deleting nodes
as needed.
During this compound operation, unload events may fire on iframes that got
deleted by this operation.
I would like components to be notified that they got removed/disconnected from
the document
before such an event is getting fired.
```html
ElementWithInDocumentFlag extends HTMLElement {
constructor(...args) {
super(...args);
this.inDocument = false;
}
connectedWithDocument() {
this.inDocument = true;
}
disconnectedWithDocument() {
this.inDocument = false;
}
}
document.defineElement('hello-world', ElementWithInDocumentFlag);
sucks
var helloWorld = document.querySelector('hello-world');
var container = document.getElementById('editor');
setTimeout(function () {
document.querySelector('iframe').contentWindow.onunload = function () {
console.log(container.innerHTML); // This does not contain hello-world
console.assert(!helloWorld.inDocument); // This should be false!
}
container.focus();
getSelection().selectAllChildren(container);
setTimeout(function () {
document.execCommand('Delete');
}, 500);
}, 500);
```
- R. Niwa
Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
Can you give a code example of how this happens? On Feb 24, 2016 8:30 PM, "Ryosuke Niwa" wrote: > > > On Feb 23, 2016, at 1:16 AM, Anne van Kesteren wrote: > > > > On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa wrote: > >> Hi, > >> > >> We propose to change the lifecycle callback to be fired both before > invoking author scripts (e.g. for dispatching events) and before returning > to author scripts. > >> > >> Without this change, event listeners that call custom elements' methods > would end up seeing inconsistent states during compound DOM operation such > as Range.extractContents and editing operations, and we would like to avoid > that as much as possible. > > > > These are the events we wanted to try and delay to dispatch around the > > same time lifecycle callbacks are supposed to be called? > > Yeah, I'm talking about focus, unload, etc... and DOM mutation events. > It's possible that we can make all those event async in the future but > that's not the current state of the world, and we would like to keep the > custom elements' states consistent for authors. > > - R. Niwa > > >
Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
> On Feb 23, 2016, at 1:16 AM, Anne van Kesteren wrote: > > On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa wrote: >> Hi, >> >> We propose to change the lifecycle callback to be fired both before invoking >> author scripts (e.g. for dispatching events) and before returning to author >> scripts. >> >> Without this change, event listeners that call custom elements' methods >> would end up seeing inconsistent states during compound DOM operation such >> as Range.extractContents and editing operations, and we would like to avoid >> that as much as possible. > > These are the events we wanted to try and delay to dispatch around the > same time lifecycle callbacks are supposed to be called? Yeah, I'm talking about focus, unload, etc... and DOM mutation events. It's possible that we can make all those event async in the future but that's not the current state of the world, and we would like to keep the custom elements' states consistent for authors. - R. Niwa
Re: [custom-elements] Invoking lifecycle callbacks before invoking author scripts
On Tue, Feb 23, 2016 at 5:26 AM, Ryosuke Niwa wrote: > Hi, > > We propose to change the lifecycle callback to be fired both before invoking > author scripts (e.g. for dispatching events) and before returning to author > scripts. > > Without this change, event listeners that call custom elements' methods would > end up seeing inconsistent states during compound DOM operation such as > Range.extractContents and editing operations, and we would like to avoid that > as much as possible. These are the events we wanted to try and delay to dispatch around the same time lifecycle callbacks are supposed to be called? -- https://annevankesteren.nl/
[custom-elements] Invoking lifecycle callbacks before invoking author scripts
Hi, We propose to change the lifecycle callback to be fired both before invoking author scripts (e.g. for dispatching events) and before returning to author scripts. Without this change, event listeners that call custom elements' methods would end up seeing inconsistent states during compound DOM operation such as Range.extractContents and editing operations, and we would like to avoid that as much as possible. - R. Niwa
