| 06:42 | <yoav> | A localName of an element is its tag name, right? |
| 06:42 | <yoav> | Specifically, HTMLTrackElement's local name is not `texttrack`, right? |
| 06:43 | <yoav> | Chromium's resource timing initiatorType implementation says it is, and I want to make sure before changing |
| 06:47 | <annevk> | yoav: it's "track" |
| 06:47 | <annevk> | (I wouldn't say tag name though, since that's rather ambiguous and incorrect depending on context) |
| 06:48 | <annevk> | yoav: having said that, resource timing shouldn't have access to element names |
| 06:48 | <annevk> | yoav: that's a pretty big layering violation |
| 06:48 | <yoav> | annevk: it's also useless, but this is what current implementations do... |
| 06:49 | <annevk> | yoav: I think that basically means we have to pass that information to Fetch too... |
| 06:49 | <annevk> | pretty gross |
| 06:54 | <yoav> | annevk: we can try to deprecate it, but it's being used and currently there's no alternative |
| 06:54 | <yoav> | What the use case really needs is destination + some form of Fetch ID to point at an initiator resource |
| 06:55 | <yoav> | the tag name helps no one, other than being a heuristic for the destination |
| 06:56 | <yoav> | annevk: I wonder if we could have a simple mapping of destination to some element name that will be compliant enough for this to work without referring to the local name |
| 06:56 | <yoav> | s/compliant/compatible/ |
| 06:59 | <yoav> | tbh, this is what I'm currently doing in the implementation to support the "audio" and "video" initiators (instead of piping the local name through half a dozen abstraction layers) |
| 07:02 | <annevk> | yoav: that would be nice |
| 07:02 | <annevk> | yoav: could maybe use initiator for the remainder |
| 07:02 | <yoav> | yeah |
| 07:03 | <yoav> | images would be tricky, as currently they report differently if they were triggered by HTMLImageElement, HTMLInputElement or as CSS background images :/ |
| 07:04 | <annevk> | Right, so you'd need initiator for that |
| 07:05 | <annevk> | Still doable. Most tricky thing with all of that is that image loading isn't properly abstracted yet and CSS doesn't define fetching in any kind of detail... |
| 07:06 | <annevk> | We could start tackling some of that though, at least reverse the initators we know we need, add them to the spec, change resource timing around a bit to say what it actually exposes |
| 07:07 | <yoav> | yeah... |
| 07:07 | <yoav> | I'd be happier if we could avoid all that busy work and just remove initiatorType altogether |
| 07:08 | <yoav> | Maybe I'll add a use counter to see how feasible this pipe dream is |
| 07:15 | <annevk> | sg |
| 12:11 | <smaug____> | a bit annoying the style to put scripts to separate file even in some very small wpt tests |
| 12:17 | <annevk> | smaug____: for view source? |
| 12:17 | <annevk> | smaug____: I've been wondering if we should improve that for any.js and window.js; it seems that sometimes we could just inline the script instead of referencing it |
| 12:23 | <smaug____> | annevk: yeah, for view-source, for debugging |
| 14:19 | <JakeA> | wanderview: ah, thanks for catching that |
| 14:21 | <wanderview> | JakeA: np... I only mentioned it since I think you said you didn't like the cleanup handler stuff since it doesn't wait for async functions right now... so I wanted to give you a chance to r- it |
| 14:21 | <wanderview> | personally I'm happy to use the cleanup handler stuff even without async waiting as long as there is a unique scope |
| 14:21 | <JakeA> | wanderview: I think it pushes the need for async cleanup support |
| 14:22 | <JakeA> | but yeah, if it works, fiiiine :D |
| 14:22 | <wanderview> | JakeA: maybe if you need a break from google io... |
| 14:37 | <smaug____> | annevk: ping |
| 14:38 | <smaug____> | annevk: https://github.com/w3c/web-platform-tests/blob/master/dom/events/relatedTarget.window.js#L47 why is that right? |
| 14:38 | <smaug____> | event is dispatched to body and listener is in shadowchild |
| 14:38 | <smaug____> | am I missing something |
| 14:52 | <annevk> | smaug____: looks wrong indeed |
| 14:53 | <smaug____> | I could fix it while looking this stuff on gecko side |
| 14:53 | <smaug____> | just wondering how... |
| 14:53 | <smaug____> | add another shadowchild |
| 14:54 | <smaug____> | add listener there |
| 14:54 | <smaug____> | and dispatch event to that |
| 14:54 | <annevk> | smaug____: add listener on body instead? |
| 14:54 | <smaug____> | something like that |
| 14:54 | <smaug____> | or that |
| 14:54 | <smaug____> | with {once: true} |
| 14:54 | <annevk> | smaug____: also did we resolve all open questions here? Is only window.event unclear still? |
| 14:55 | <smaug____> | well, gecko doesn't have that yet |
| 14:55 | <smaug____> | and touch.target handling is still ongoing in impl (and there are spec issues on touch stuff) |
| 14:58 | <annevk> | Yeah, but it seems there's no issues left in DOM |
| 14:58 | <annevk> | Well, there's event issues, just not related to dispatch |
| 14:59 | <annevk> | smaug____: if you want I can fix these tests too, but would appreciate an issue somewhere |
| 14:59 | <smaug____> | annevk: well, perhaps easier if I just fix this minor issue while fixing gecko impl to follow the spec |
| 14:59 | <annevk> | k |
| 15:00 | <smaug____> | but I can file a testing issue if that is needed for some tracking |
| 15:00 | <annevk> | smaug____: it's not |
| 15:00 | <annevk> | hayato: kochi: if you're fixing event dispatch in Blink see above and let smaug____ know please |
| 15:04 | <smaug____> | ah, that activation behavior is tricky to fix in gecko |
| 15:04 | <smaug____> | clearing targets before activation behavior |
| 15:06 | <annevk> | Iām glad I put effort into writing that test š |
| 15:38 | <smaug____> | annevk: ah, another issue with that test with event listener on wrong target |
| 15:38 | <smaug____> | relatedTarget is retargeted to host |
| 15:38 | <smaug____> | which is not in shadow dom |
| 15:39 | <smaug____> | I guess I need to keep the event shadow dom |
| 15:42 | <smaug____> | but then the test doesn't test what it is supposed to test |
| 15:44 | <smaug____> | but don't know anything better now |
| 15:46 | <annevk> | Issue? I also vaguely recall wondering if not clearing when not composed would be better |
| 21:45 | <JakeA> | annevk: just seen <!--FETCH--> in the media elements section of the HTML spec. Does this have any kind of special meaning? |
| 22:35 | <MikeSmith> | JakeA: that looks like one of the topic markers that Hixie added years ago to enable people to get notified when he made changes to particular part of the spec |
| 22:35 | <MikeSmith> | he set up some related tooling back then |
| 22:35 | <JakeA> | Gotcha, cheers! |