| 01:10 | <Domenic> | MikeSmith: I think we could also unblock the MDN work by temporarily reverting to URL segments instead of titles. Then the blocker is "just" review bandwidth. |
| 01:13 | <MikeSmith> | Domenic: good point, yeah |
| 01:14 | <MikeSmith> | and that’s a relatively easy revert, so I can do it right now and push it soonish |
| 01:17 | <Domenic> | Great. I *hope* to make time to review tomorrow in that case, but this week has been really crammed, so I can't promise. |
| 01:20 | <MikeSmith> | no worries, since it’s just an enhancement change and lack of it’s not blocking anybody else’s work |
| 01:21 | <MikeSmith> | and I should say thanks much for the review you’ve done so far ー I really appreciate it |
| 03:54 | <MikeSmith> | Domenic: OK, wattsi code switched back to using the URL segment, and output pushed to https://arcane-cove-57093.herokuapp.com/ |
| 05:18 | <domfarolino> | annevk: https://github.com/whatwg/html/pull/3656 Also changes the default classic worker credentials mode correct? |
| 05:19 | <domfarolino> | I believe it does, just didn't see it mentioned in the thread |
| 05:43 | <domfarolino> | annevk: Nope it doesn't nvm |
| 07:38 | <MikeSmith> | annevk: about https://developer.mozilla.org/en-US/docs/Web/API/WorkerLocation |
| 07:38 | <MikeSmith> | > https://developer.mozilla.org/en-US/docs/Web/API/WorkerLocation |
| 07:38 | <MikeSmith> | oofs |
| 07:39 | <MikeSmith> | > The WorkerLocation interface doesn't inherit any property, but implements properties defined in the URLUtilsReadOnly interface. |
| 07:39 | <MikeSmith> | is the above true? |
| 07:40 | <MikeSmith> | if so I don’t see where it’s specified that it inherits properties defined in URLUtilsReadOnly |
| 07:41 | <MikeSmith> | https://html.spec.whatwg.org/multipage/workers.html#worker-locations doesn’t state anything about that |
| 07:42 | <MikeSmith> | oh, or is it because WorkerGlobalScope inherits? |
| 07:48 | <Ms2ger> | MikeSmith, that used to be true, but not anymore |
| 07:49 | <MikeSmith> | ah |
| 07:49 | <Ms2ger> | Does URLUtilsReadOnly even exist anymore? |
| 07:49 | <MikeSmith> | hmm, no |
| 07:49 | <MikeSmith> | I see that it actually does not exist anymore |
| 07:53 | <Ms2ger> | Well there we are :) |
| 07:57 | <MikeSmith> | Ms2ger: btw I’m curious what the WPT interface test for the Window object does, as far as checking the IDL from the spec |
| 07:57 | <Ms2ger> | Can you elaborate? :) |
| 07:58 | MikeSmith | looks at https://web-platform-tests.live/html/browsers/the-window-object/window-prototype-chain.html |
| 07:59 | <MikeSmith> | Ms2ger: I mean in that the properties aren’t exposed from the prototype the way they are for other IDL interfaces/objects |
| 08:01 | <MikeSmith> | yesterday Domenic and annevk clarified for me a bit about how it works, but I still don’t understand how we could test what was described to me |
| 08:01 | <Ms2ger> | MikeSmith, there's branches like this one: https://github.com/web-platform-tests/wpt/blob/8a062c149e4581de0cd92cb51f316247e9514e5d/resources/idlharness.js#L2117 |
| 08:02 | MikeSmith | looks |
| 08:02 | <MikeSmith> | aha |
| 08:02 | <MikeSmith> | OK, that makes sense |
| 08:03 | <annevk> | MikeSmith: you can only observe it through WindowProxy |
| 08:04 | <annevk> | MikeSmith: so I guess you can study how that behaves (it's well defined) |
| 08:04 | <annevk> | MikeSmith: and if you then study the behavior for global objects in IDL you should have an idea how "window" works |
| 08:04 | <annevk> | (and how to poke at it) |
| 08:05 | <MikeSmith> | annevk: OK |
| 08:05 | <annevk> | MikeSmith: that leaves some complicated cases still, e.g., https://github.com/whatwg/html/issues/3997 |
| 08:05 | <MikeSmith> | annevk: OK yeah I started to understand that from what you had pointed out yesterday. Was mostly left wondering how WPT idlharness handled it |
| 08:05 | MikeSmith | looks at https://github.com/whatwg/html/issues/3997 |
| 08:06 | <annevk> | MikeSmith: ah okay, I'm not sure about idlharness unfortunately |
| 08:06 | <MikeSmith> | god this stuff is so messy |
| 08:06 | <MikeSmith> | e.g., teh https://github.com/whatwg/html/issues/3997 things |
| 08:06 | <MikeSmith> | *thing |
| 08:06 | <annevk> | uhuh |
| 08:07 | <annevk> | folks must have been really worried about their job 20 years ago, but then they moved on and left us with their job security/technical debt |
| 08:07 | <MikeSmith> | I can’t imagine any other runtime comes close to this in terms of complications like this, and quirks |
| 08:07 | <MikeSmith> | hahah |
| 08:07 | <annevk> | I hear Windows is pretty bad |
| 08:08 | <MikeSmith> | ah yeah maybe only that is anywehre close to being in the same class |
| 08:10 | <MikeSmith> | but I guess with development of most other runtimes, after the people who dumped all the bad designed stuff in there have moved on, the others who come in after can still (with enough time ane work) rip it out and replace it with something better |
| 08:10 | <MikeSmith> | and break some legacy APIs I guess |
| 08:11 | <MikeSmith> | I suppose that’s what it comes downto, other runtimes developers have the luxury of being able to break backward compat |
| 08:15 | <MikeSmith> | but what’s also depressing to think about it is that, rightly, all the web platform’s messiness should be clearly documented, along with being specced |
| 08:15 | <MikeSmith> | and there is nobody who gets up in the morning looking forward to writing good documentation for that kind of stuff |
| 08:15 | <Ms2ger> | Anne does! |
| 08:16 | <MikeSmith> | hahah |
| 08:16 | <Ms2ger> | Or I choose to believe that |
| 08:16 | <MikeSmith> | thank heavens we got Anne |
| 08:16 | <MikeSmith> | maybe we can talk Anne into writing docs along with speccing everything |
| 08:17 | <MikeSmith> | but short of that, at least reviewing |
| 08:17 | <Ms2ger> | Do we really need these intricacies documented outside the spec, though? |
| 08:17 | Ms2ger | would be fine with "here be dragons" |
| 08:18 | <MikeSmith> | I dunno |
| 08:18 | <MikeSmith> | yeah maybe so |
| 08:18 | <Ms2ger> | Might be worth putting a stack of motivating examples in the spec, if we don't have them yet |
| 08:19 | <MikeSmith> | well partly that’s what we have MDN for |
| 08:19 | <MikeSmith> | I personally don’t think loading the spec itself down with yet more non-normative stuff is the optimal solution |
| 08:20 | <MikeSmith> | but the particular problem that concerns me right now is that after we add MDN annotations to the spec, readers following the links in the annotations and reading the MDN content are going to expect that it clarifies their understanding |
| 08:20 | <MikeSmith> | and the vast majority of cases, the MDN docs do that, quite well |
| 08:21 | <MikeSmith> | but the existing MDN docs for these cases like Window are a different matter |
| 12:45 | <gsnedders> | MikeSmith: by way of contrast, I'm in favour of adding non-normative text to the spec if it helps people who don't already know the area intimately be able to read it |
| 13:35 | <JakeA> | https://heycam.github.io/webidl/#idl-dictionaries - The identifier is the key name of the key–value pair. If the Type is an identifier followed by ?, then the identifier must identify an interface, enumeration, callback function or typedef. If the dictionary member type is an identifier not followed by ?, then the identifier must identify any one of those definitions or a dictionary. |
| 13:35 | <JakeA> | I keep reading this, but I have no idea what it means :D |
| 13:36 | <JakeA> | Can anyone help? What does ? mean in a dictionary? |
| 13:43 | <zcorpan> | JakeA: if you use a ? you can't use a dictionary type |
| 13:45 | <JakeA> | zcorpan: As in a dictionary within a dictionary? What's the benefit of ? then, other than asserting the type isn't a dictionary? |
| 13:46 | <zcorpan> | right |
| 13:46 | <zcorpan> | the ? means that null is allowed |
| 13:46 | <JakeA> | Riiiiight! |
| 13:46 | <zcorpan> | but you can't use nullable together with a dictionary |
| 13:47 | <zcorpan> | since dictionaries are implicitly present if you say null |
| 13:47 | <JakeA> | I think it'd have taken me a few months of reading that paragraph over and over again to figure that out |
| 13:47 | <JakeA> | Thanks for clearing that up |
| 13:47 | <zcorpan> | happy to help. I'll send you the bill :-P |
| 13:47 | <JakeA> | \o/ |
| 14:20 | <Domenic> | annevk: TabAtkins: any remaining concerns about "htmlsvg-global/nonce" for https://github.com/whatwg/html/pull/4032 ? Would like to merge if not. |
| 14:21 | <annevk> | Domenic: I'm pushing a nit |
| 14:21 | <TabAtkins> | Nah go for it |
| 14:21 | <annevk> | (autowrapping tooling would be really nice) |
| 14:22 | JakeA | grumbles something about soft wrapping being better |
| 14:22 | <Domenic> | 3... 2... 1... |
| 14:22 | <Domenic> | (that's my countdown for TabAtkins telling us how semantic wrapping is better.) |
| 14:23 | <TabAtkins> | :bursts in, gasping and out of breath: |
| 14:23 | <annevk> | (spaces) |
| 14:24 | <Domenic> | (oh nooooo) |
| 14:24 | <TabAtkins> | :somehow bursts in a second time: |
| 14:24 | <annevk> | 🍿 |
| 14:34 | <astearns> | (rgb is the best way to specify colors) |
| 14:36 | annevk | papayawhips astearns |
| 14:46 | <nox> | astearns: #rgb only of course, no one needs #rrggbb. |
| 14:51 | <annevk> | zcorpan: do we have tests for a fieldset with multiple legend elements where the first legend element is floated or positioned? |
| 14:51 | <annevk> | zcorpan: no need for a pointer, just curious |
| 14:52 | <zcorpan> | annevk: yes. also with dynamically changing the style |
| 14:53 | <annevk> | zcorpan: good times were had I'm sure |
| 14:53 | <zcorpan> | I didn't find any bugs with that test actually |
| 14:53 | <zcorpan> | surprisingly |
| 15:29 | <Domenic> | If we make <ul> support type="", should it also support start=""? /cc TabAtkins |
| 15:29 | <Domenic> | Firefox apparently supports the content attribute but not the IDL attribute |
| 15:29 | <domfarolino> | annevk: Is the total reach of changing default classic script fetch options in https://github.com/whatwg/html/pull/3656 just making imports from classic workers be same-origin credentials, or is that inaccurate |
| 15:30 | <TabAtkins> | Meh, no opinion |
| 15:30 | <TabAtkins> | Start comes with value on the li, of course |
| 15:31 | <annevk> | domfarolino: it shouldn't affect class workers as they were same-origin bound anyway |
| 15:31 | <annevk> | classic workers* |
| 15:33 | <Domenic> | domfarolino: this is mainly about <script type=module> |
| 15:35 | <domfarolino> | Indeed, but I noticed `fetch a classic worker script` uses same-origin credentials (of course), but returns a script made from default classic script fetch options (omit creds). Is this the options that "referencing script" will have, when import()ing? |
| 15:36 | <domfarolino> | If so, I'm wondering if changing that will change the credentials mode that these imports() will be fetched with? (sorry, I could easily be getting lost in the cross-linking) |
| 16:03 | <domfarolino> | Domenic: would that apply if a classic worker has a cross-origin import? |
| 16:08 | <Domenic> | Hmm I aww |
| 16:08 | <Domenic> | *Hmm I see |
| 16:08 | <Domenic> | It seems like it would impact import()s from workers too, yeah |
| 16:08 | <Domenic> | But it should |
| 16:08 | <Domenic> | The idea is to just have same-origin credentials mode everywhere |
| 16:09 | <Domenic> | Unless changed via <script type=module crossorigin="use-credentials"> or new Worker(url, { credentials: "include" }) |
| 16:15 | <domfarolino> | Domenic: the latter actually wouldn’t have an effect I think, since the credentials member is only used for module workers IIRC. But yes that makes sense, I was just trying to see if we’ll need another intent for chrome, since changing default classic worker creds is different from changing <script type=module>. |
| 16:18 | <domfarolino> | s/default classic worker creds/default classic script fetch options (and therefore classic worker descendent imports) |
| 16:31 | <domfarolino> | We'll also probably need descendent worker credentials tests (they seem missing) |
| 16:41 | <annevk> | domfarolino: aah well spotted, it does affect that and maybe importScripts()? That used to use “include” like regular scripts. Hmm |
| 16:44 | <domfarolino> | importScripts() yes |
| 16:45 | <domfarolino> | Oh interesting. Also I guess it’s a little odd that descendant classic worker scripts can’t be fetched with “include” credentials |
| 16:48 | <domfarolino> | Ugh, descendant classic worker imports** |
| 17:33 | <annevk> | That also goes for some other fetch options, but perhaps this one is particularly annoying… |
| 17:34 | <annevk> | Perhaps we need to change classic back to include |
| 17:35 | <annevk> | I might not have considered “subfetches” carefully enough, sigh |
| 17:36 | <annevk> | Why all this infrastructure is to be managed by only a couple people is beyond me, it could really use more attention |
| 17:50 | <domfarolino> | annevk: I'll write a comment on the PR attempting to summarize all of the changes introduced, and link to whatever tests exists, and whatever tests need written etc. |
| 17:51 | <domfarolino> | Yeah, it's very "gnarly" infra. Cool though |
| 18:54 | <annevk> | domfarolino: that’s great, thanks! |