| 03:05 | <Hixie> | well bummer, i can't very well call the comparator function from within the sort algorithm, the comparator could do all kinds of crazy things to the DOM |
| 04:16 | <zewt> | Hixie: run the whole sort (leaving the DOM elements in-place--just figure out the order they'd end up being in), then apply the DOM changes at the end all at once only if the DOM order is the same? |
| 04:16 | <zewt> | (precisely what "the same" means I'm not sure) |
| 04:17 | <Hixie> | the definiton of "the same" is what matters, really |
| 04:17 | <Hixie> | i mean, with that definition, i could abort whenever |
| 04:19 | <zewt> | if you're sorting nodes [a,b,c,d,e], only apply the result if at the end of the sort algorithm, the nodes would still produce the pre-sorted list [a,b,c,d,e] |
| 04:20 | <Hixie> | what does that mean? |
| 04:20 | <Hixie> | you mean, do the node collection twice? |
| 04:21 | <Hixie> | what if the nodes change contents during the comparator? |
| 04:21 | <Hixie> | or the page is navigated? |
| 04:22 | <zewt> | i mean, run the entire sort algorithm without applying any changes, just sorting the nodes out-of-band, then once that's complete, check if the nodes are still where they were and apply the changes atomically |
| 04:23 | <Hixie> | define "where they were". What if the table is now in a different document? Or the trs are still in the same tbodies but the tbodies are in different tables? or the <th>s that we're using to determine the sort order have all been moved around? |
| 04:24 | <zewt> | that's what i mean by comparing the list of nodes you're sorting: if the table results in three groups that need to be sorted, check that the table still gives the same results before applying |
| 04:25 | <Hixie> | what if the <tr>s are still there but the cells have all changed? |
| 04:25 | <Hixie> | it's the cell contents we use to compare the rows, after all |
| 04:25 | <zewt> | if it's a user comparison function, then it might make sense to not care about that |
| 04:26 | <Hixie> | it's user comparison for one column, but the other column might not be |
| 04:26 | <Hixie> | i'm fast reaching the conclusion that a comparator here is a terrible idea |
| 04:26 | <Hixie> | js one, i mean |
| 04:27 | <zewt> | well i've said that explicit sort keys can handle most cases :) |
| 04:31 | <zewt> | are there any particular cases you have in mind where a function is needed and a sort key won't work? |
| 04:31 | <zewt> | there are some cases where they work but are a bit awkward (like natural sorts) |
| 04:34 | <Hixie> | the main reason for having it is that the libs have them |
| 04:35 | <Hixie> | ok. bye bye comparator. |
| 04:36 | <Hixie> | if people want to manually sort they can do so on onsort |
| 08:15 | <Krinkle> | annevk: Hi again |
| 08:16 | <Krinkle> | Ms2ger: annevk: For when either of you get back, I updated my implementation according to your updates to the spec. However it appears TreeWalker.nextNode is still broken / failing tests. |
| 08:17 | <Krinkle> | In this commit I update my implementation: https://github.com/Krinkle/dom-TreeWalker-polyfill/commit/7cc08f400bdc5bca405040e7ec3877ff668cae48 |
| 08:17 | <Krinkle> | Based on recent commits in https://github.com/whatwg/dom/commits |
| 08:17 | <Krinkle> | In particular there is a problem with 'result' not being assigned when filtering the "following" node. |
| 08:18 | <Krinkle> | causing the next iteration of the running the steps to use the old result again |
| 08:18 | <Krinkle> | If you clone my repo, and change the conditional block for "nextNodeW3" from if-false to if-true you'll see the failing test (the test fails when there is an accepted node inside a rejected parent that is following an accepted parent) |
| 08:19 | <Krinkle> | so the next iteration is looking in a child it shouldn't be looking into |
| 08:20 | Krinkle | files a bug |
| 08:40 | <Krinkle> | nvm, it was fixed already (looking at an outdated version) |
| 08:58 | <annevk> | good |
| 10:38 | <Jasper> | notjasper, hi |
| 10:39 | <notjasper> | hello |
| 10:39 | <notjasper> | are you jasper? |
| 10:39 | <Jasper> | i am Jasper |
| 10:39 | <notjasper> | I was trying to connect through mibbit a second ago, and it gave me the name jasper and then imediately asked me to change my name, and then booted me out |
| 10:39 | <notjasper> | lol |
| 10:39 | <Jasper> | heh |
| 22:31 | <gsnedders> | SamB: Expose sharp corners for people to injure themselves upon, basically. (Exposing behaviour where non-specified behaviour can become relied upon, basically.) |
| 22:32 | <zewt> | exposing GC behavior isn't so much a sharp corner as a hidden blade |
| 22:45 | <gsnedders> | Just found out that "if x, do optimized code, else y" is too expensive for compiled JS. TIL. |
| 22:45 | <gsnedders> | Oh well, let's ignore that everyone has done that for years. |
| 22:47 | <SamB> | TIL? |
| 22:49 | <gsnedders> | Today I learned. |
| 22:49 | <gsnedders> | Someone claimed this in an argument about the feasibility of JS optimizations with me. |
| 22:49 | <gsnedders> | I should step away from the internet. |
| 23:09 | <annevk> | gsnedders: don't argue the Internet man, it's exhausting |
| 23:14 | <gsnedders> | annevk: I know, I mostly ignore it. |