dom
dom copied to clipboard
whatwg
Adoption and DocumentFragment, part two
This reverts commit c825ceaf3cb77943f487f85533d8be79bccd2fe3 and adds a new solution for DocumentFragment adoption on top. See #813 and #814 for context.
HTML: https://github.com/whatwg/html/pull/5413
Tests: https://github.com/web-platform-tests/wpt/pull/22504
jsdom: https://github.com/jsdom/jsdom/pull/2925
Bugs (still the same):
- https://bugzilla.mozilla.org/show_bug.cgi?id=1602200
- https://bugs.webkit.org/show_bug.cgi?id=204980
- https://bugs.chromium.org/p/chromium/issues/detail?id=1031811
Anything I can help with on the jsdom side, or on reviews, to land this and the associated HTML/WPT PRs?
Verifying that this is correct would help as well as a review. Perhaps @mfreed7 is interested in prototyping in Chromium?
Verifying that this is correct would help as well as a review. Perhaps @mfreed7 is interested in prototyping in Chromium?
The change looks reasonable, but from #814 it might be tricky to get exactly right. I'm happy to prototype in Chromium, but I'd prefer to do that after jsdom has had a chance to confirm the change passes existing WPTs... @TimothyGu?
FWIW, I've implemented this new behavior in https://commits.webkit.org/252098@main
Sorry for coming back on this again and again, but we have a problem in production with Safari and it seems that we got stuck... Just ignoring it doesn't solve anything. I think a decision has to be made here soon...
Is there a process that I need to follow or do I just create a PR to fix this? The easiest option is to revert the change and find a more reasonable one later.
It's been awhile without answer, where can I shoot my concerns over this issues? It's breaking both apps and hearts.
It's been awhile without answer, where can I shoot my concerns over this issues? It's breaking both apps and hearts.
I believe you're referring to the WebKit/Safari behavior described here, correct? https://bugs.webkit.org/show_bug.cgi?id=246899
If so, that bug is the better place to raise the issue, since this issue is about the spec. That bug is informative about the direction the spec needs to take, though, since it seems the proposed direction isn't web compatible.
so adoptNode behavior has been reverted in WebKit https://github.com/WebKit/WebKit/pull/11347 because of https://github.com/aurelia/framework/issues/1003 WebKit being the only to have adopted the new behavior, it was having the burden of the breakage.
There is a need for a better path forward.
There is a need for a better path forward.
What we want is the ability to adopt the document fragment. Currently adopting the template element doesn't adopt the document fragment itself. What if we do that?
I dont know all the reasons why the fragment of the template element isn't associated with the document that created it, but if calling adoptNode explicitly on template does it then maybe this behavior is safe to go in?