| 13:34 | <annevk> | Ms2ger: yt? |
| 13:34 | <annevk> | Ms2ger: I'm looking at "To determine the value of a named property name in a Window, the user agent must return the value obtained using the following steps:" |
| 13:34 | <Ms2ger> | annevk, did you see the comment I made on the PR? |
| 13:34 | <annevk> | Ms2ger: step 2 there says "If objects contains a nested browsing context, then return the WindowProxy object of the nested browsing context corresponding to the first browsing context container in tree order whose nested browsing context is in objects." |
| 13:34 | <annevk> | Ms2ger: it doesn't talk about names |
| 13:34 | <annevk> | (of bcs) |
| 13:34 | <Ms2ger> | Lemme grab the spec |
| 13:35 | <Ms2ger> | Step one refers to "named objects", which does talk about names: https://html.spec.whatwg.org/multipage/window-object.html#dom-window-nameditem-filter |
| 13:36 | <annevk> | I guess the question is if "objects contains a nested browsing context" is worded poorly |
| 13:36 | <annevk> | Perhaps it meant to say "if objects contains a browsing context"? |
| 13:37 | <annevk> | That is, I was assuming step 2 did some unwrapping, but maybe it doesn't |
| 13:37 | <annevk> | And on reflection it wouldn't make much sense if it did |
| 13:38 | <annevk> | Ms2ger: okay, I guess I can fix the wording there as part of https://github.com/whatwg/html/pull/4404 or some such |
| 13:39 | <Ms2ger> | Yeah, step 2 looks worse every time you read it :) |
| 13:49 | smaug____ | tries to recall how .window.js get run... |
| 13:50 | <annevk> | smaug____: replace .js with .html |
| 13:51 | <smaug____> | but keep window? |
| 13:51 | <annevk> | smaug____: yes |
| 13:54 | <smaug____> | how surprising, I don't see Event-dispatch-listener-order.window.js in mozilla-central |
| 14:01 | <smaug____> | need to just wait for a merge, I guess |
| 15:12 | <annevk> | that's weird |
| 15:12 | <annevk> | I thought that was automated these days |
| 15:13 | <annevk> | jgraham: ^^ |
| 15:15 | <jgraham> | annevk: Yeah, it's automated, the automation has been behind for a while and some maintainance is needed to address the root causes |
| 16:11 | <smaug____> | is https://wpt.fyi/ down? |
| 16:12 | <Ms2ger> | smaug____, it was just updating, I think |
| 16:13 | <smaug____> | aha |
| 18:43 | <jyasskin> | https://html.spec.whatwg.org/multipage/iana.html tries to register a bunch of things with IANA, but most of them haven't made it to the relevant registries, like https://www.iana.org/assignments/media-types/media-types.xhtml and https://www.iana.org/assignments/message-headers/message-headers.xhtml. How's that process supposed to work? |
| 18:43 | <jyasskin> | (I noticed because of https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0197.html) |
| 18:46 | <jyasskin> | The ones that made it seem to be the ones that got copied to https://www.w3.org/TR/html/iana.html. |
| 19:04 | <annevk> | jyasskin: it hasn’t really been worked on post-cooperation |
| 19:05 | <annevk> | jyasskin: though I did try to register Refresh at one point |
| 19:05 | <jyasskin> | "It" being the relationship between the WHATWG and IANA? |
| 19:06 | <annevk> | jyasskin: IANA registry post-cooperation between W3C and WHATWG |
| 19:06 | <annevk> | Maybe once that is fully resolved this would be easier to pick up again |
| 19:07 | <annevk> | Those registries also have not been super useful generally |
| 19:09 | <jyasskin> | I guess MDN can replace a lot of their use. |
| 19:10 | <annevk> | jyasskin: and standards you can revive |
| 19:13 | <jyasskin> | That makes sense. Still, for standards like HTTP that are not living, it'd be useful to at least make HTML's claims about what's in the registries match the registries themselves. :) |