4 ms·

In typical Chrome fashion, they shipped an API that is in status "Specification currently under development in a Working Group" I don't understand the need for

by sureIy 2y ago

In typical Chrome fashion, they shipped an API that is in status "Specification currently under development in a Working Group" I don't understand the need for this awkward API. Ok, `otherParent.append(existingIframe)` reloads the iframe, but that's just a legacy behavior. Why not toggle the new behavior by calling `existingIframe.holdMyBeer()`? This way I could just continue using .prepend/.append/.before/.after et — which by the way support multiple elements at once, unlike moveBefore. Ridiculous choice, but I'm not even surprised anymore.

spankalee 2y ago
> I don't understand the need for this awkward API. Well, it's clear you didn't take the time to try. There are multiple threads on this and related topics, with inputs from all browser vendors. This has been a high-priority standards request from framework and rendering library maintainers for many, many years. Chrome is not at all being ridiculous.
- sureIy 2y ago
  You didn't read my comment. I know what it's for, I don't agree with the API itself. Read my third paragraph.
- notnullorvoid 2y ago
  Shipping it in its current state does seem premature. The spec still hasn't addressed a major concern from rendering library authors, which was that an explicit check to see if a node is connected is now required to branch between using moveBefore or insertBefore, since moveBefore throws if used to place a disconnected node.
  - mary-ext 2y ago
    isn't it only on disconnected-disconnected case? it'd still require a separate path but it seems like something you can just check once (the parent)
    - notnullorvoid 2y ago
      According to the spec it throws in the following cases: Parent - Moved Node disconnect - connected connected (Doc A) - connected (Doc B) connected - disconnected The last one is the most concerning one. Most of the top performing frameworks do child node reconciliation something like this https://github.com/WebReflection/udomdiff/blob/e58db3ad28b72ade55a14452a73331a0db4d0871/index.js#L46 https://github.com/WebReflection/udomdiff/blob/e58db3ad28b72.... Each node could be unmoved (no-op), new (disconnected), or moved from within the parent (connected). Now if one wants to leverage moveBefore each of these nodes needs to be checked for it's connection state.
AlexErrant 2y ago
It's stage 3... and "the existence of stage 4 is basically a formality" > [stage 3] basically means "finished, pending editorial nit review---but since multiple implementations haven't happened yet, there's a reasonable chance that we'll discover something is broken, and need to fix the normative content https://github.com/whatwg/meta/issues/336#issuecomment-24874 https://github.com/whatwg/meta/issues/336#issuecomment-24874...
spartanatreyu 2y ago
There are plenty of reasons to be upset with chrome. This is not one of them.

by sureIy 2y ago

spankalee 2y ago

> I don't understand the need for this awkward API. Well, it's clear you didn't take the time to try. There are multiple threads on this and related topics, with inputs from all browser vendors. This has been a high-priority standards request from framework and rendering library maintainers for many, many years. Chrome is not at all being ridiculous.

sureIy 2y ago
You didn't read my comment. I know what it's for, I don't agree with the API itself. Read my third paragraph.
notnullorvoid 2y ago
Shipping it in its current state does seem premature. The spec still hasn't addressed a major concern from rendering library authors, which was that an explicit check to see if a node is connected is now required to branch between using moveBefore or insertBefore, since moveBefore throws if used to place a disconnected node.
- mary-ext 2y ago
  isn't it only on disconnected-disconnected case? it'd still require a separate path but it seems like something you can just check once (the parent)
  - notnullorvoid 2y ago
    According to the spec it throws in the following cases: Parent - Moved Node disconnect - connected connected (Doc A) - connected (Doc B) connected - disconnected The last one is the most concerning one. Most of the top performing frameworks do child node reconciliation something like this https://github.com/WebReflection/udomdiff/blob/e58db3ad28b72ade55a14452a73331a0db4d0871/index.js#L46 https://github.com/WebReflection/udomdiff/blob/e58db3ad28b72.... Each node could be unmoved (no-op), new (disconnected), or moved from within the parent (connected). Now if one wants to leverage moveBefore each of these nodes needs to be checked for it's connection state.

AlexErrant 2y ago

It's stage 3... and "the existence of stage 4 is basically a formality" > [stage 3] basically means "finished, pending editorial nit review---but since multiple implementations haven't happened yet, there's a reasonable chance that we'll discover something is broken, and need to fix the normative content https://github.com/whatwg/meta/issues/336#issuecomment-24874 https://github.com/whatwg/meta/issues/336#issuecomment-24874...

spartanatreyu 2y ago

There are plenty of reasons to be upset with chrome. This is not one of them.