| 03:55 | <devsnek> | if i did a pr for https://github.com/whatwg/dom/issues/147 would anything implement it |
| 04:25 | <Domenic> | devsnek: it's unclear whether NodeIterator is considered legacy or part of the modern DOM at this point. I think you can replace uses of it with other, simpler APIs in general. That said, marcos (on that thread) works for Mozilla and might implement it. |
| 04:25 | <devsnek> | Domenic: interesting |
| 04:26 | <devsnek> | is that why you didn't mention it when i was trying to iterate over documents |
| 04:27 | <Domenic> | Yeah I suppose so |
| 04:28 | <Domenic> | In particular it's an awkward Java-ish API with lots of bad old design patterns. And the fundamental capability it gives seems to be ... it saves you from writing a DFS yourself? |
| 04:28 | <devsnek> | lol |
| 04:28 | <devsnek> | i'm not particularly invested in the api either |
| 04:29 | <devsnek> | just people were asking about it in ##javascript |
| 04:29 | <Domenic> | If we were to design a modern API for this I think Node.prototype.getNextNode/getPreviousNode would be it. |
| 04:29 | <devsnek> | Node[Symbol.iterator] which yields a single item :P |
| 04:30 | <Domenic> | Yeah I guess if you really want to for-of over something you could add Node.prototype.forwardIterator()/reverseIterator() which would repeatedly call getNextNode/getPreviousNode |
| 04:31 | <Domenic> | Anyway, bedtime, ttyl |
| 04:34 | <devsnek> | 👋🏻 |
| 08:50 | <annevk> | JakeA: is there a summary somewhere of what Chrome wants to do with URLs? |
| 08:51 | <annevk> | I find the Twitter conversations I've seen rather opaque |
| 09:33 | <zcorpan> | annevk: the twitter conversations seem pretty clear to me. Chrome wants to kill URLs |
| 09:33 | zcorpan | hides |
| 10:11 | <MikeSmith> | annevk: somebody pointed me at the Twitter replies from Emily Stark. |
| 10:11 | <MikeSmith> | https://mobile.twitter.com/estark37/status/1191473763172278272 |
| 10:11 | <MikeSmith> | or maybe you read those already |
| 10:48 | <annevk> | Yeah, I saw some of that, but a lot of it is rather vague as to what it might mean, which I guess is why you get people speculating |
| 15:52 | <lilltiger> | How about killing off google.. :D |
| 15:57 | <PiersW> | Hi. I've just implemented TreeWalker and NodeIterator using the whatwg spec. |
| 15:58 | <PiersW> | In TreeWalker.nextNode(), the spec says in step 3.4.3 "if sibling is non-null, then break". I think it needs to set node to sibling before the break. |
| 15:59 | <PiersW> | Otherwise the web-platform-tests for treewalker don't pass. |
| 16:00 | <PiersW> | Secondly, Acid3 can't pass with NodeIterator without modifications to the algorithm in the spec, because it removes the reference node from the collection inside the filter callback. |
| 16:19 | <annevk> | PiersW: there are some open spec issues, not sure if they cover this |
| 16:20 | <annevk> | PiersW: I’d be happy to look tomorrow. If there’s identified test coverage that’d help a lot |
| 16:22 | <PiersW> | Ah, I think it's this. https://github.com/whatwg/dom/issues/787 |
| 16:23 | <PiersW> | I get an infinite loop on some tests without the node=sibling line. But these all fail: dom/traversal-TreeWalker-previousNodeLastChildReject, dom/traversal-TreeWalker-walking-outside-a-tree, dom/traversal-TreeWalker-previousSiblingLastChildSkip and one subtest in dom/traversal-TreeWalker-traversal-skip |
| 16:24 | <PiersW> | These infinite loop: web-platform-tests/dom/traversal-TreeWalker-acceptNode-filter, web-platform-tests/dom/traversal-TreeWalker-currentNode, web-platform-tests/dom/traversal-TreeWalker-traversal-reject |
| 16:32 | <PiersW> | I'd not seen #787 before. There's a subtle difference between my suggestion and the one in #787, in that mine's one line :-) But it's clearly fixing the same bug and with it all relevant wpts pass (inc Acid3). |
| 16:47 | <annevk> | PiersW: please leave a comment there if you can |
| 16:48 | <annevk> | PiersW: and if there’s a way to test the difference in fixes I guess we might need more tests |
| 16:49 | <PiersW> | Why aren't the existing 7 enough? |
| 16:52 | <annevk> | PiersW: well, I’d like the shorter fix recorded |
| 16:53 | <PiersW> | The existing algorithm is obviously wrong (in hindsight) because step 3.2 and 3.3 create the variables 'sibling' and 'temporary'. Step 3.4 assigns them values, and then nothing ever access their values. |
| 16:54 | <PiersW> | I'll try to put these comments in the issue this evening (UK). |
| 16:54 | <annevk> | The other thing that helps is the tests you identified |
| 16:54 | <annevk> | Appreciate it! |
| 17:02 | <devsnek> | annevk: the idea is to isolate the authoritative part of the url and show only that part to the user |
| 17:03 | <devsnek> | the example I see a lot from chrome devs is bank.com/secure vs bank.com.secure.fake.net |
| 17:04 | <devsnek> | (but with longer URLs that go off the end of the url bar) |
| 17:05 | <devsnek> | I'm not sure I agree with this approach but phishing is definitely a problem |
| 17:08 | <devsnek> | I'm more concerned about the Google search results doing this, since then there won't be any trace of the actual link to a page on the results |
| 17:32 | <annevk> | devsnek: if they’re basically copying Safari it’d help a whole lot if someone said so |
| 17:34 | <devsnek> | I think jake might've mentioned safari at some point |
| 17:34 | <annevk> | Apart from EV and perhaps apart from using a positive security indicator Safari has been leading the way for quite a while here |
| 17:34 | <devsnek> | definitely would be nice to have more information though :( |
| 17:34 | <annevk> | devsnek: k |
| 17:36 | <annevk> | I don’t mind, I mostly find the communication rather confusing |
| 17:36 | <devsnek> | I'm sure there are oodles of design docs that just haven't been made public yet |
| 19:39 | <Domenic> | My take is that these are partially product/UX decisions and those parts of the org don't have the usual open communication styles of the eng parts. So confusion results as the eng people who want to communicate openly either have to stick to only certain publicly announced things, or (my case) don't know what the actual plans are, and have just seen a lot of papers/comments/mock-up designs/etc. |
| 20:59 | <PiersW> | I've updated #787 (TreeWalker). I'm not sure how you can test the algorithms in the specs (given they're English), but my C++ implementation shows it to work with my suggested modification. |