Hacker News Reader

Comment by sureIy | Hacker News Reader

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.

View on HN

> 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.

You didn't read my comment.

I know what it's for, I don't agree with the API itself. Read my third paragraph.

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.

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)

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/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.

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...

There are plenty of reasons to be upset with chrome.

This is not one of them.

Reply on news.ycombinator.com