> On Feb 26, 2016, at 3:36 PM, Elliott Sprehn <espr...@chromium.org> wrote:
>
>
>
> On Fri, Feb 26, 2016 at 3:31 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>>
>> > On Feb 26, 2016, at 3:22 PM, Elliott Sprehn <espr...@chromium.org> wrote:
>> >
>> >
>> >
>> > On Fri, Feb 26, 2016 at 3:09 PM, Ryosuke Niwa <rn...@apple.com> wrote:
>> >>
>> >> > On Feb 24, 2016, at 9:06 PM, Elliott Sprehn <espr...@chromium.org>
>> >> > 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
