State-preserving atomic move integration #10657
Conversation
source
Outdated
| @@ -72810,7 +72874,10 @@ customElements.define("x-foo", class extends HTMLElement { | |||
| <li><p>When it <span>becomes disconnected</span>, its <code data-x="">disconnectedCallback</code> | |||
| is called, with no arguments.</p></li> | |||
|
|
|||
| <li><p>When it is <span data-x="concept-node-adopt">adopted</span> into a new document, its <code | |||
| <li><p>When it is <span data-x="concept-node-move-ext">moved</span>, its <code | |||
| data-x="">connectedMoveCallback</code> is called, with no arguments.</p></li> | |||
There was a problem hiding this comment.
Shouldn't callback get the old subtree owner as an argument, so that one can know easily where one was.
There was a problem hiding this comment.
This would require holding a reference to the old tree which might be gone by the time the CE callbacks are fired. Perhaps we can consider this as a future enhancement? I think we should be able to do that in a compatible way.
There was a problem hiding this comment.
We've generally been quite conservative with supplying context to custom element callbacks and nobody has complained so I agree we should continue that trend.
There was a problem hiding this comment.
Can this comment be resolved?
domfarolino
added
impacts documentation
There was a problem hiding this comment.
I don't think you mentioned connectedMoveCallback everywhere connectedCallback is mentioned (and it's relevant).
- https://html.spec.whatwg.org/#custom-element-reactions
- https://html.spec.whatwg.org/#element-definition (this one seems especially important)
- It could do with some examples as well.
This was there already, see https://whatpr.org/html/10657/custom-elements.html#custom-element-reactions ("When it is moved"). Not sure what's missing?
Done
Added non-normative note and an example |
|
Seems like #10828 should be addressed here too? |
This reverts commit f6e9fbe.
…ons from removing steps
domfarolino
force-pushed
the
atomic-move-patches
branch
from
05e204b to
9ee1673
Compare
| data-x="">attributeChangedCallback</code>" → null ]».</p> | ||
| null, "<code data-x="">connectedMoveCallback</code>" → null, "<code | ||
| data-x="">adoptedCallback</code>" → null, "<code data-x="">attributeChangedCallback</code>" → | ||
| null ]».</p> |
There was a problem hiding this comment.
The order here is different from the order in list above. After adopted seems reasonable?
There was a problem hiding this comment.
To me as well. Done.
| <var>oldParent</var>, are:</p> | ||
|
|
||
| <ol> | ||
| <li><p>If <var>movedNode</var>'s next sibling was an <code>img</code> element and |
There was a problem hiding this comment.
"was"? So somehow this algorithm needs to get the old sibling as argument?
There was a problem hiding this comment.
Hmm yes I guess, but the same goes for the removing steps which pre-date this PR and this API. I think fixing that is best left to a follow-up where we evaluate and perhaps overhaul the inputs to these steps.
For example, we could hack together a single parameter hot fix for this hook, but that's not ideal. Rather we need to do something consistent with what's desired in whatwg/dom#1288, where we teach the various hooks to take in a bundle of contextual information (ChildrenChange and ContainerNode in Chromium).
So I think I'd prefer to fix this and removing steps in one swoop after this, since it's easy, ensures nothing diverges, and this doesn't make the problem any worse. How does that sound?
Furthermore, I am actually skeptical that the spec has been doing the right thing in this case anyways. For example, Chromium doesn't track the "old next sibling" of the removed source, and trigger a relevant mutation on it. It triggers relevant mutations on all image children of the picture (https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/html/html_picture_element.cc;l=26-29;drc=a7096322ab1e5c9e70ae7b773faed492ed8461cb) so maybe implementations are compatible with that, and we can simplify all of this anyways. Regardless, I'd prefer it not block this.
This PR is a supplementary PR to whatwg/dom#1307. It provides the HTML-overrides for the DOM Standard's "moving steps" extension, to allow pieces of the HTML Standard to react to atomic DOM moves without the use of the "insertion steps" or "removing steps", which by default, intentionally fail to preserve most state. The changes in this PR are inspired by the audit carried out in https://docs.google.com/document/d/1qfYyvdK4zhzloABKeh0K1lHPm-SpnEcsWEE9UdDuoMk/edit.
Node.prototype.moveBefore) WebKit/standards-positions#375Node.prototype.moveBefore) mozilla/standards-positions#1053moveBefore()API mdn/mdn#613 & theimpacts-documentationlabel(See WHATWG Working Mode: Changes for more details.)
/custom-elements.html ( diff )
/embedded-content.html ( diff )
/form-control-infrastructure.html ( diff )
/form-elements.html ( diff )
/images.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/media.html ( diff )