| 12:55 | <nox> | smaug____: We have yet to support all that composedPath stuff in Servo, I guess we should wait for your new algo to land, right? |
| 13:25 | <smaug____> | nox: right |
| 13:30 | <annevk> | smaug____: once you have something you'll update the DOM issue? |
| 13:31 | <nox> | annevk: I saw you mention O(1) event firing btw, |
| 13:31 | <smaug____> | yeah. Just got back, so will on that soonish |
| 13:31 | <nox> | annevk: and I think we do that in Servo, IIRC. Last time I wanted to update that code, I quickly went away because the spec wasn't nearly as simple as last time I remember reading it. :) |
| 13:32 | <annevk> | nox: shadow trees complicated it quite a bit |
| 13:32 | <nox> | Yep, and we don't have that. |
| 13:32 | <nox> | So I have to squint at the spec to detect which parts are irrelevant for us. |
| 13:34 | <smaug____> | nox: oh, you could implement composedPath just fine now, if you don't expect to have shadow DOM soon. |
| 14:22 | <annevk> | smaug____: cool, I'll have more time to work on things now, about 4h each day for a month, then mostly back to full-time |
| 14:24 | <smaug____> | FWIW, I think annotating the tuples should be super simple, but it is creating sane composedPaths afterwards in a not too slow way requires some thinking. I need to ensure my ideas from last night actually work there... |
| 14:24 | <smaug____> | but first some code reviews |
| 16:56 | <TabAtkins> | gsnedders: Quite a bit, yeah. You're deep in tests; from the outside, keeping track of which tests map to what text, so you even *know* when "a test needs to be moved", is already quite a task. |
| 17:00 | <Domenic> | nox: it seems like the existence of composedPath() makes O(1) event firing impossible. I'm curious if you find otherwise. |
| 17:02 | <gsnedders> | TabAtkins: I meant under the assumption that we have the tests organised such that they're grouped by section, and hopefully have clear enough filenames to know what maps to what text |
| 17:02 | <gsnedders> | TabAtkins: I mean, most things aren't as bad as much of the CSS tests with hundreds of files per directory :) |
| 17:03 | <nox> | Domenic: Yeah I was saying we have O(1) event firing because we don't support this method. |
| 17:04 | <nox> | Domenic: Also every time I look at the method, all I see is word salad, but that's probably because I'm not familiar with shadow DOM terminology. |
| 17:04 | <smaug____> | Domenic: how does existence of composedPath affect to event firing O() ? |
| 17:04 | <nox> | smaug____: Have to precompute the path even if no one calls composedPath. |
| 17:05 | <smaug____> | no |
| 17:05 | <smaug____> | well, event firing is always O(n) |
| 17:05 | <smaug____> | n being the number of event targets in the path |
| 17:05 | <smaug____> | and path needs to be created before event propagation |
| 17:06 | <smaug____> | but composedPath can be different for each target in the path |
| 17:06 | <smaug____> | so it should be calculated lazily |
| 17:06 | <nox> | Mmh… |
| 17:06 | <nox> | Oh right, even if the event isn't bubbling there is still stuff to do on each target in the path. |
| 17:06 | <smaug____> | but calculating it lazily should lead to same result as if it was calculated eagerly for each target |
| 17:06 | <smaug____> | there is always capture phase |
| 17:07 | <nox> | Yeah, that. |
| 17:07 | <TabAtkins> | annevk: "Outlawing a style of test" isn't the goal at all. The more granular your tests, the more benefit you'll get from putting them inline next to the granular thing they're testing, but if you've got a single mega-test file, that's fine. It's just no real benefit to you in that case; there's nothing to move or track, you've just got the one spec and the one test. |
| 17:08 | <annevk> | TabAtkins: yeah, that's why I just gave high-level feedback here |
| 17:09 | <annevk> | TabAtkins: I'm supportive of more experiments in this area |
| 17:09 | <annevk> | TabAtkins: the one we did for XHR with detailed annotations kinda failed, but perhaps this one will go differently |
| 17:09 | <TabAtkins> | I'd love to see details on that, I missed it entirely. |
| 17:13 | <annevk> | TabAtkins: basically all tests were annotated with XPath expressions pointing to the statements in the spec; there was some scraper to collect all those expressions into a JSON thing that the spec then used to reference all the tests once you clicked a checkbox from the matched statements |
| 17:14 | <annevk> | TabAtkins: however, I didn't do a good job of keeping it in sync, since we didn't do spec-test development in tandem yet |
| 17:14 | <annevk> | TabAtkins: and the unmaintained scripts started breaking, etc. |
| 17:14 | <TabAtkins> | Ah, kk, and it was done in the other direction, too. |
| 17:29 | <Domenic> | smaug____: nox: no need to do the capture phase if there are no capture listeners |
| 17:29 | <smaug____> | Domenic: well, fine. Browsers can always optimize |
| 17:29 | <smaug____> | like, not firing events at all |
| 17:29 | <Domenic> | Yes... when we're talking about O() we're definitely talking about optimizations. |
| 17:29 | <smaug____> | if there are no listeners |
| 17:29 | <smaug____> | why? |
| 17:30 | <smaug____> | when we're talking about O(), we're talking about the spec level algorithms, I would have thought |
| 17:35 | <Domenic> | I guess that was a misunderstanding then |
| 17:35 | <Domenic> | I'm much more interested in efficient implementations (and specs that enable efficient implementations) than I am in efficient specs |
| 17:36 | <Domenic> | My understanding is that before composedPath, a browser could optimize to O(1). But after its introduction, that's impossible. |
| 17:41 | <smaug____> | Domenic: browser can optimize to O(1) with composed path too |
| 17:41 | <smaug____> | need to deal with DOM mutations |
| 17:42 | <Domenic> | OK, it seemed impossible to me, but happy to be told I'm wrong |
| 17:42 | <smaug____> | and if such is happening, capture the path |
| 17:42 | <smaug____> | and then do the dom mutation |
| 17:42 | <smaug____> | not fun thing to implement, but doable |
| 17:43 | <smaug____> | of course, then listeners shouldn't modify dom too much |
| 17:43 | <smaug____> | but without composedPath there are also limitations, like not having capturing listeners everywhere etc |
| 17:45 | <smaug____> | Domenic: oh, and even without composedPath, what if you have listener on target only, but that listener adds another (bubble) listener to the root of the tree |
| 17:45 | <smaug____> | you need to know that root |
| 17:45 | <smaug____> | so it isn't clear to me which O(1) case we're talking about here |
| 21:00 | <Domenic> | smaug____: this is the case I repeated 3-4 times in the thread, non-bubbling events where there are no capture listeners for that event type |
| 21:06 | <smaug____> | Domenic: so you'd like to get rid of composedPath altogether ? |
| 21:06 | <smaug____> | to make it easier for implementations to optimize event dispatch |
| 21:06 | <Domenic> | I mean, implementers don't seem to care about O(1) event dispatch, so I'm not going to stand on it. |
| 21:07 | <smaug____> | (it is still possible to optimize out path creation with composedPath, but just trickier) |
| 21:07 | <smaug____> | the current setup isn't O(1) either |
| 21:20 | <annevk> | Domenic: have folks been able to quantify the cost somehow? Mutation evens vs observers for instance |
| 21:21 | <Domenic> | Yeah, I'm not sure, I guess hayato is looking in to some of this stuff. |
| 22:18 | <Domenic> | rniwa: in https://github.com/w3c/webcomponents/issues/688#issuecomment-341567895 you said "We're going with ${~}", which is probably a typo, but a pretty confusing one. |
| 22:19 | <rniwa> | Domenic: oops, it's missing "if". Fixed. |
| 22:19 | <Domenic> | \o/ |