Differentiate between "children change" steps and "children inserted" steps

[noamr]

See whatwg/html#12279

• At least two implementers are interested (and none opposed):
  • This is already implemented and was in the spec before
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/dom/nodes/insertion-removing-steps/script-does-not-run-on-child-removal.window.html?label=master&label=experimental&aligned&q=script-does-not-run-on-child-removal
• Implementation bugs are filed:
  • N/A

(See WHATWG Working Mode: Changes for more details.)

[shannonbooth]

Thanks! I have also now made a related WPT MR for the CharacterData mutation case web-platform-tests/wpt#58601 I believe this is also technically changing the normative behaviour of - Chromium and Webkit pass this test, but Gecko does not.

edit: Oops, I meant to comment on the HMTL MR here, but same difference!

[noamr]

Thanks! I have also now made a related WPT MR for the CharacterData mutation case web-platform-tests/wpt#58601 I believe this is also technically changing the normative behaviour of - Chromium and Webkit pass this test, but Gecko does not.

edit: Oops, I meant to comment on the HMTL MR here, but same difference!

Thanks! Mind opening a Gecko bug for this? I'll update the PRs to link to it.

[annevk]

Should this be an argument to children change in some way? This doesn't seem great though as modifications to text nodes are often insertions too and would be missed by this.

[noamr]

Should this be an argument to children change in some way?

That's also an option

This doesn't seem great though as modifications to text nodes are often insertions too and would be missed by this.

I think that's exactly the discrepancy in web-platform-tests/wpt#58601 no?

[annevk]

I think so, but I'm wondering if we should align with Firefox instead to avoid all these awkward cases just for the script element. (And then forever hope nobody (ab)uses these hooks in a similar manner.) Would also like to hear from @rniwa and @smaug----.

[noamr]

I dug up some archeological discussions about this: https://lists.w3.org/Archives/Public/public-whatwg-archive/2011Oct/0289.html. Apparently it was "children changed" before, but the concept of "children changed" wasn't well defined at the time, so this commit made it clearer that it's just an insert as a simplification.

In https://lists.w3.org/Archives/Public/public-whatwg-archive/2012May/0105.html, following the commit, Hixie says that the spec wording was to align with firefox/IE behavior at the time.

[rniwa]

It's probably not a common scenario but there could be still compatibility bug / regression if we changed the behavior.

Having said that, we could try changing WebKit's behavior and see if it sticks.

[noamr]

It's probably not a common scenario but there could be still compatibility bug / regression if we changed the behavior.

Having said that, we could try changing WebKit's behavior and see if it sticks.

If we align with Firefox the compat issue should be relatively safe no?

Though it's still a subset of children-changed as it excludes removals.

[rniwa]

It's probably not a common scenario but there could be still compatibility bug / regression if we changed the behavior.
Having said that, we could try changing WebKit's behavior and see if it sticks.

If we align with Firefox the compat issue should be relatively safe no?

Well, there are quite a bit of iOS specific content out there but we can still try.

[shannonbooth]

I can switch the WPT test case over if that direction is preferred. I suppose in that case DOM standard will need to be adjusted so that all of inserted/removed/mutated children change hooks are exposed