Re: [whatwg/dom] Add convenient, ergonomic, performant API for sorting siblings (#586)

> Why not doing an extra step to handle also removed nodes and eventual new nodes

As couple of examples/ideas around this:

  * `parentEl.reorderChildren(parentEl.childNodes)` would basically be a no-op
  * `parentEl.reorderChildren([...parentEl.childNodes, document.createElement('p')])` adds last P to the list
  * `parentEl.reorderChildren([...parentEl.childNodes].slice(1))` drops first node
  * `parentEl.reorderChildren([....childNodes].sort(byAttribute))` does what's being proposed in here but it doesn't limit the feature to a single attribute
  * `parentEl.reorderChildren([document.createElement('p')])` would basically replace children with just the P element

Maybe `reorderChildren` is not the most semantic way to describe this variant but it will solve all diffing and ordering issues we have (yesterday) today and tomorrow without requiring attributes all over the place to keep track of the reordering ... wouldn't this be better? the described behavior of a single MO record with addedNodes or removedNodes still makes sense, no synchronous old style mutation events should be fired, iframes can do iframes things, but everything else will be just natively "*diffed*" and we won't need to ask again for this in the future.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/586#issuecomment-1415792385
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/586/1415792385@github.com>