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

> you're suggesting that the accessor function/attribute would need to return an integer index? Or at least numeric? 

Yeah, that was the idea.

> Could the method be overloaded, so that if the sort key parameter is a function, it gets called for each element, otherwise it's used as the name of an attribute to parse? Or is that too much of a JS thing for a DOM API?

Right, that overload was what I was implying with my "Perhaps even this" sample.

> What about the idea of taking a list of different keys, for tie-breaker values (so that, for static content like a data table, you could calculate out the sort order for each key separately, and store in different element attributes/properties)?

I'm hesitant about this kind of scope creep, but it might be doable. However, note that it's easy to do on top of the simpler API: `el => getKey1(el) * el.parentNode.childElementCount + getKey2(el)`

>  And/or having an easy built-in way to reverse the sort order?

Again I'm unsure on the scope creep. For example JS's `sort()` doesn't have such a facility; you have to modify the sorting comparator. Here, similarly, you'd modify the sorting comparator: `el => -getKey(el)`.

----

Great survey of existing libraries.

I also forgot to mention that your concern about non-element children is a real one and I'm not sure what the right answer is. I do think for most use cases there won't be any, but does that justify making an API that does something strange like shuffling them to the end?

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