2019-08-01 [19:53:41.0000] Domenic: around 👀? [08:24:53.0000] cybai: http://www.nohello.com/ ^_^ Ask your question and just wait for the answer, or if it must be a synchronous conversation, give the subject (and if necessary, expected duration) so the other person can prepare for it. [08:27:55.0000] TabAtkins: oops sorry, I will ask question directly next time 😖 [08:28:18.0000] Heh, it's okay. [08:29:25.0000] /me will be offline later because it's around 12AM in his timezone; but he will ask question before being off! [08:31:16.0000] Domenic: I'd like to ask, in "resolve a module specifier" spec, it only says "return failure" in those fail cases (https://html.spec.whatwg.org/multipage/webappapis.html#resolve-a-module-specifier) but the wpt test says specifier error will lead to TypeError (https://github.com/web-platform-tests/wpt/blob/e234e61f0219efe0428c2361721d4d5c0831add7/html/semantics/scripting-1/the-script-element/module/specifier-error.html#L17) [08:31:31.0000] Should we say TypeError explicitly in spec? [08:35:11.0000] thanks m(_ _)m [08:40:05.0000] ugh I am sorry anyone who just got a review created by the wpt bot, I accidentally committed a wrong file O_o [08:52:52.0000] ..maybe.. sigh, idk [08:53:58.0000] cybai: look at the call sites of "resolve a module specifier". 2019-08-02 [17:34:08.0000] Domenic: oh!! I see! thanks! 2019-08-03 [14:10:06.0000] has deferred navigation ever been discussed? [14:10:21.0000] kind of like what amp does, but in a less evil google way 2019-08-04 [18:44:48.0000] devsnek: what do you mean by "deferred navigation"? [18:45:27.0000] Domenic: tell the UA you *might* navigate somewhere [18:45:35.0000] Who tells the UA that? [18:45:39.0000] the website [18:45:44.0000] like how amp preloads stuff [18:45:52.0000] it would let the UA preload the sites [18:46:01.0000] The problem with preloading in general is that the website then gets all your data [18:46:19.0000] well the browser is in a position to not run the js and etc [18:46:29.0000] Not running the JS isn't enough [18:46:39.0000] Simply making a HTTP request gives you a lot [18:46:50.0000] hmm [18:46:57.0000] maybe it just shouldn't exist then [18:47:00.0000] Thus, SXG [18:47:33.0000] cuz signed exchanges are kinda sketchy [18:47:38.0000] Can you explain what you mean? [18:47:48.0000] In particular, how they are more or less sketchy than CDNs? [18:48:44.0000] You may find https://developers.google.com/web/updates/2018/11/signed-exchanges helpful in how it explains both privacy-preserving prefetching and how SXGs are generally better than giving your signing keys to a CDN. [18:48:57.0000] they remove control from the origin and potentially bypass stuff like pi-hole [18:49:24.0000] I'd be very surprised if companies that serve amp don't take advantage of that [18:49:27.0000] Can you explain how they remove control from the origin? They do not bypass pi-hole as far as I know, assuming pi-hole looks at URLs. [18:49:46.0000] pi-hole blocks dns of advertisers and trackers and stuff [18:49:56.0000] My understanding is it also applied URL-based filtering. [18:50:06.0000] Otherwise it would be trivial to bypass by putting your ads on a different CDN. [18:50:24.0000] it can, but they always change URLs and stuff [18:50:31.0000] blocking IP ranges is more effective [18:50:57.0000] Well, there's nothing new in SXGs that makes that harder [18:51:28.0000] you'd have to block the person who serves the sxg [18:51:37.0000] Yes, similar to blocking the person that serves the ad. [18:51:57.0000] If your argument is that pi-hole is vulnerable to people locating ads on servers that people might not want to block, that applies regardless of SXG. [18:52:12.0000] But my understanding is pi-hole is not that dumb. [18:52:45.0000] I'm not saying it changes the game substantially [18:52:52.0000] its just another point [18:52:57.0000] I don't think it is. [18:54:34.0000] i also dislike that I'll still be on Google even though the URL bar might say something else [18:54:54.0000] Do you dislike it that currently the sites are on Cloudflare despite the URL bar saying something else? [18:55:23.0000] that's just using cloudflare as your host [18:55:36.0000] As your CDN [18:55:39.0000] yeah [18:55:56.0000] Alternate question, would you not-dislike it if people gave their private keys to Google, like they do to Cloudflare, in order to allow Google to sign their HTTPS certs and host their content like Cloudflare does? [18:56:03.0000] but with signed exchanges isn't Google still loaded on my client [18:56:31.0000] What do you mean by "Google still loaded". THe content you loaded is created entirely by the publisher. (And cryptographically signed to attest that.) [18:57:39.0000] The bytes physically come from Google (or wherever). But they are signed as created by the URL-bar URL. It's CDNs but using extra fancy crypto stuff instead of just giving the host/CDN your private key. [18:58:32.0000] I.e. with the current CDN setup you just give all control to your host/CDN, including the ability to sign HTTPS certs as example.com, so that the browser displays example.com in the address bar even though the content is ultimately from the CDN servers. [18:58:37.0000] isn't the site that loads a sxg still in control [18:58:41.0000] Nope [18:58:45.0000] hmm [18:58:46.0000] It would break the S part of SXG [18:58:49.0000] If you change the content [18:59:06.0000] I don't mean change the content [18:59:17.0000] What type of control are you thinking of, then? [18:59:21.0000] Google doesn't modify amp pages [18:59:29.0000] but it surrounds them in a frame [18:59:33.0000] that kind of thing [18:59:55.0000] SXG is a network protocol. It doesn't have some carvout where you can modify the content by surrounding it in an iframe. [19:00:18.0000] so if Google used signed exchanges they wouldn't be able to do that anymore [19:00:52.0000] I mean they can still load content in an iframe. (But, it will show the Google URL in the URL bar.) [19:01:05.0000] so they'd have to actually navigate away from google [19:01:13.0000] That's what they currently do with AMP [19:01:19.0000] Well, not really [19:01:22.0000] no, they wrap it in a frame [19:01:25.0000] They navigate to the publisher's content, hosted on Google [19:01:28.0000] and override input gestures [19:01:34.0000] it's horribly annoying [19:01:49.0000] I mean there might still be iframes [19:01:57.0000] but then it won't show the url [19:02:18.0000] The difference is that now we have a cryptographic guarantee that the content of the iframes is from the publisher, not just the promise that Google won't modify the contents of the iframes despite them being hosted on Google servers. [19:03:06.0000] so the thing I brought up before was trying to prevent Google's thing where navigating to a site is hijacked and I still remain on Google's property [19:03:17.0000] but now I understand that the interests are different [19:03:39.0000] Happy to help. 2019-08-05 [03:42:35.0000] is there a way for a websocket client (using the WebSocket browser API) to detect how/why did the http upgrade failed? 2019-08-06 [13:19:42.0000] Is there any issue with adding a [14:51:35.0000] innovati: it makes your page invalid HTML; not sure if that's what kind of issue you're wondering about. [14:51:57.0000] It generally will be bad for performance as then you'll need a restyle/etc., which is why it's suggested to keep style tags in the head. [14:52:45.0000] I have to add the CSS via JavaScript, but depending on when our JS runs, sometimes it's not coming after the CSS on the site, so I'm wondering the latest in the document I can add it so ours comes last [14:53:24.0000] I don't remember if document position or time of insertion is more important for CSS cascade [14:53:26.0000] it seems to work in the browsers where I would need to use it [14:53:50.0000] the order in DOM I believe [15:08:41.0000] Seems to work IE9+ 2019-08-07 [03:00:51.0000] Hi [03:38:25.0000] annevk, https://github.com/heycam/webidl/pull/675#issuecomment-503452334 [04:31:02.0000] Ms2ger: basically, I think that PR depends on the outcome of https://github.com/mozilla/standards-positions/issues/147#issuecomment-513274020 [04:32:49.0000] annevk, ok, can you put that in the PR? [04:34:36.0000] Ms2ger: added a comment [04:35:37.0000] Takk [05:13:04.0000] I wonder why the gray box moves when using ctrl+click: https://html.spec.whatwg.org/#history-traversal-task-source, click on the term, the gray box opens. Then ctrl+click on different entries to open them in new tabs [05:13:13.0000] gray box moves to bottom left [05:13:27.0000] happens at least in Nightly and some version of Chrome [05:13:43.0000] (looks like Chrome 77) [05:21:29.0000] smaug____: I think that is by design [05:21:35.0000] to move it out of the way [05:21:49.0000] huh [05:21:58.0000] while still persisting it so that you can follow further backlinks [05:22:14.0000] domfarolino: heya [05:22:33.0000] domfarolino: if I comment on an HTML PR, I don't endorse a particular design on behalf of Firefox [05:22:56.0000] domfarolino: in particular I'm not at all sure about this prefetch stuff [05:23:57.0000] smaug____: I think the rationale is that keeping the box in the middle of the text flow is more obtrusive [05:24:12.0000] the box moves after to navigate to one of them links [05:24:26.0000] annevk: hello. ok, sorry I failed to capture that. I was assuming you were reviewing the PR to get it in a direction you were comfortable with [05:24:46.0000] maybe it should not move it if you are not navigating. I mean for the Ctrl+Click open-in-new-tab case [05:25:32.0000] domfarolino: that would probably have been good, but I mostly gave high-level feedback (and it looks like only early feedback) and didn't do a design review [05:25:46.0000] it is odd for the UI to moves hundreds of pixels down [05:25:55.0000] domfarolino: while you're here, how much data do you all have on prefetching? [05:26:14.0000] I've always thought it is just a bug in some script [05:26:37.0000] domfarolino: afaik nobody does Vary: Cookie so you'll get all these weird cases where users are not logged in while they expected to be, right? [05:42:25.0000] annevk: Not much right now, but we plan on coming into TPAC with some numbers. Right now we're working on starting to experiment with the redirect mode changes, and we're hoping to ship the SW-mode change too. We're deferring the credentials mode bits until credential-less navigation is more clear, as it will likely be too problematic now [05:42:34.0000] cc yoav [05:46:46.0000] domfarolino: note that if you don't patch credentials you don't close the XSLeaks hole [05:54:31.0000] domfarolino: do you want to correct the blink-dev post or would it be better if I replied? [05:55:03.0000] annevk: we wouldn't be shipping a partial solution, we just don't think it makes sense to make the credentials mode change yet. [05:55:55.0000] annevk: you are referring to the prefetch request mode changes just to be clear right? I can correct it. Would you like me to mention that you don't fully endorse it, and that your review was not necessarily on behalf of Firefox/Mozilla? [05:56:57.0000] domfarolino: yeah, https://github.com/w3c/resource-hints/issues/82#issuecomment-519082099 has some initial thoughts [05:57:19.0000] domfarolino: thanks [06:20:17.0000] smaug____: Might be worth raising an issue. It arguably is a bug, if the user experience is surprising and unintuitive [06:28:57.0000] domfarolino: in general if it's not on standards-positions it's best to assume Firefox has no position [06:29:11.0000] domfarolino: unless someone explicitly said they were talking on behalf of Firefox [06:29:24.0000] (and even then...) [06:29:41.0000] annevk: That's the impression I've been getting [06:50:51.0000] annevk: Updated the thread. unfortunately i had sent it with my google email address, which I've never used to send a message before, so the post is "under moderation" for a bit lol [07:06:29.0000] heh 2019-08-08 [01:23:28.0000] MikeSmith: you might wanna look at the last couple of comments of https://bugzilla.mozilla.org/show_bug.cgi?id=1309358 [01:23:41.0000] MikeSmith: a bunch of MDN regarding CORS got updated [01:24:07.0000] (I saw Florian ping you in another bug as well, so you might have already seen it) [08:34:48.0000] Domenic: you missed a non- in https://github.com/w3ctag/promises-guide/issues/60#issuecomment-519569673 [09:21:57.0000] annevk: I'm not seeing it... [09:22:52.0000] Domenic: exceptional errors are the one thing you should use rejections for [09:23:21.0000] Domenic: you meant non-exceptional errors [09:24:39.0000] annevk: ah right, thank you, my eyes just kept sliding right over it... [13:10:38.0000] I observe that `new URL('http://a/%41').href` is 'http://a/A' in Chrome and 'http://a/%41' everywhere else, including Node. I am _pretty_ sure Chrome is wrong, but I'm having a little trouble following the URL parsing algorithm; does anyone know off the top of their head? [13:15:06.0000] You are correct [13:26:03.0000] thanks! [13:46:36.0000] https://quirks.spec.whatwg.org/#the-percentage-height-calculation-quirk tries to find the containing block for resolving %height of an element. The last step is Jump to the first step. But there's nothing in the steps that changes _element_, making the steps an infinite loop. Am I missing something? [14:57:33.0000] dgrogan: what about step 1? [14:57:39.0000] "Let element be the nearest ancestor containing block of element, if there is one." [14:58:53.0000] jenny-m: I do not know how I misread that. Thanks 2019-08-09 [20:40:12.0000] annevk: about https://bugzilla.mozilla.org/show_bug.cgi?id=1309358 (Add wildcard to Access-Control-Expose-Headers, Access-Control-Allow-Methods, and Access-Control-Allow-Headers), it seems like Florian is on top it? But I will review the changes [20:47:28.0000] MikeSmith: yeah think so too, just wanted to let you know as CORS interests you 😊 [20:48:01.0000] annevk: yup, thanks, I appreciate it 😀 [20:48:09.0000] annevk: https://stackoverflow.com/questions/57412098/does-fetchs-response-body-chunks-correspond-to-http-chunks [20:49:28.0000] MikeSmith: no such guarantee [20:50:40.0000] MikeSmith: e.g., if there’s a delay after half of an HTTP chunk I’d expect two or so [07:13:20.0000] TabAtkins: there's something weird with Shepherd I think [07:13:35.0000] TabAtkins: no IDL ref found for {{Window}}: https://travis-ci.org/whatwg/xhr/builds/569858947 [07:13:43.0000] TabAtkins: this was working fine a couple hours ago [07:14:00.0000] Hm, will check [09:11:10.0000] annevk: Looks like Window interface isn't in the spec anymore. I don't see it in the window-object.html page? [09:20:32.0000] We broke all the spec's IDL https://github.com/whatwg/html/issues/4832#issuecomment-519979077 [09:33:47.0000] I'm curious if highlighter is failing to return any data, or if something in wattsi is failing on what it was returning. [10:06:37.0000] Score one for Bikeshed's test suite, thank you @foolip https://github.com/whatwg/xhr/issues/251 [10:06:48.0000] (Only breakage I can find.) [10:08:05.0000] annevk or Domenic: ^^^ [10:08:24.0000] (I'm on vacation and shouldn't be doing work, but oh well.) [10:18:56.0000] In that case thank you very much for updating the highlighter, TabAtkins. [10:19:19.0000] I'm just watching She-Ra this morning, no big interruption. [10:21:16.0000] HTML is now missing HTMLScriptElement for the same reason (readonly attribute DOMString async) [10:22:00.0000] Hm, can you instrument to see what exactly highlighter's failure is? [10:22:16.0000] Like, is it returning the IDL block, or erroring somehow? [10:26:54.0000] Ah, looks like it is a highlighter error, the IDL syntax error is coming out as an Exception. That's a problem on my side, will fix. [10:33:50.0000] Domenic: Okay, highlighter just updated again, it'll now just print IDL errors to stdout instead of dying on them, so HTML should get its HTMLScriptElement back. (Just with the async line not highlighted until it's fixed.) [10:34:12.0000] Oh sweet, OK [10:34:29.0000] Well but actually we kind of want to have something in our tooling to detect invalid IDL [10:34:52.0000] So I kind of preferred the old version? We just need to fix Wattsi/html-build to not give exit code 0 if the highlighter fails [10:35:21.0000] Tracked as https://github.com/whatwg/html-build/issues/201 [10:36:08.0000] This should be the only thing highlighter outputs to stdout, so presumably you should be able to listen for that. [10:37:31.0000] The problem is that highlighter exited entirely on error; an IDL error anywhere would turn off highlighting for the rest of the spec, since wattsi uses highlighter as a daemon. [10:41:20.0000] Ah OK [12:01:45.0000] Thanks for fixing that! [12:26:59.0000] Does wpt have something like assert_equals_with_fuzz(some_variable, number, fuzz_value) [12:28:11.0000] perhaps assert_approx_equals [16:34:11.0000] TabAtkins: finally, I knew it'd spot something eventually :) [16:48:09.0000] Heh, it's spotted stuff before. [16:48:35.0000] And always gives me peace of mind when making any involved change. 2019-08-12 [05:22:21.0000] o/ Hey folks! [05:26:22.0000] Question: There is Subresource Integrity to check integrity of loaded resources. For the use case I have in mind, I also want to ensure integrity of the main resource file (HTML). Thereby, the integrity of the whole "app" can be verified. Is there a way to do this without an extension? Or are there any plans for this? [05:30:32.0000] Similar to this: https://github.com/tasn/webext-signed-pages [06:38:35.0000] Hello [06:48:11.0000] \o [08:32:21.0000] annevk: I'm back from vacation and I'd like to close off https://github.com/whatwg/html/pull/4617 I think it was pending your review [08:40:55.0000] dtapuska: thanks for the ping, I should have time tomorrow [08:41:18.0000] lgrahl: no, no [08:41:57.0000] lgrahl: you might wanna review the history around certificate pinning [08:46:43.0000] annevk: HPKP? Yeah, I know about that one. But this is more about not trusting the server that is delivering the web app. Similar to how I (AFAIK, and at least technically) don't need to trust the Play Store servers as the APK is signed. [08:47:17.0000] lgrahl: who is giving you the integrity metadata then? [08:47:42.0000] Good question. I honestly don't know how it works there. Tofu? [08:47:52.0000] oh my [08:48:33.0000] Let's not give users the broken default ssh experience [08:48:56.0000] Maybe there's a better example to dig up... [08:49:03.0000] (Instead of Play Store) [08:49:53.0000] Well, in the end you'll need something you can deploy on the web, so maybe it's best to start there instead of analogies 😃 [08:52:05.0000] Okay, so the alternative someone else brought up was to install a local webserver (go through all the hassle of doing this for every platform) that runs the backend of the app and the frontend then just connects to that. We can verify that the backend app does match some signature. [08:52:24.0000] Kind of like Electron but worse I guess [08:57:32.0000] annevk: And the signature metadata comes from some other central location. Does that improve the security properties? Dunno, perhaps. [09:07:11.0000] But I get your point. Maybe mobile apps and web apps actually are actually quite similar regarding those security properties and it just "feels" different. 2019-08-13 [05:10:37.0000] annevk: Is there a standard way to escape , in header values? As in, if I want , to be considered part of a value, not separating multiple values [05:32:40.0000] JakeA: use quotes [05:32:45.0000] JakeA: quoted string, that is [05:32:54.0000] JakeA: and the quoted string parser from Fetch [05:35:41.0000] ta! [05:36:27.0000] JakeA: so we're kinda stuck with Background Sync btw and I guess a similar thing applies to Background Fetch [05:37:50.0000] annevk: Because of https://github.com/WICG/BackgroundSync/issues/152? [05:37:55.0000] JakeA: and for Background Sync it also seems there's not much uptake so it's a bit unclear how much to invest [05:38:11.0000] JakeA: well, the issues mentioned therein, not the note 😃 [05:40:47.0000] (I'll try to dig up some stats on bg sync) [05:42:20.0000] annevk: Is the issue that Firefox would like to show a permission prompt on first usage? I think background fetch has that covered, unless I'm missing something [05:45:35.0000] JakeA: we're not sure there's sufficient value for a prompt or what exactly the prompt would say [05:46:41.0000] annevk: I get it with bg sync, but Firefox already allows downloads without prompts, so I don't see the issue with bg fetch [05:48:24.0000] JakeA: I might have missed how bg fetch is different from bg sync [05:49:23.0000] JakeA: I guess bg fetch is effectively keepalive + storage? [05:49:35.0000] JakeA: it might be diff then [05:49:54.0000] JakeA: might also benefit of a name that more clearly illustrates that [05:51:27.0000] annevk: bg fetch is more like `Content-Disposition: attachment`, in terms of resuming, visibility, user control. The difference is the developer has a little more control over what appears in the download notification (eg an icon), and the result isn't written to a place of the user's choosing, it goes into origin storage [05:52:15.0000] annevk: If naming is the blocker I'm sure we can do something about that, if we can get consensus around an alternative [05:55:27.0000] JakeA: do browsers resume downloads after a connection is cut and the new connection is from a different wi-fi spot? [05:55:54.0000] JakeA: if they do that kinda seems problematic to me [05:56:30.0000] JakeA: cause you could just start a slow download and track the user as they travel around [06:01:22.0000] annevk: I haven't tested across wifi spots (https://resumable-downloads-test.glitch.me/ might be useful here). But there's a sticky notification throughout the download. [06:01:49.0000] annevk: We see ~2.5 billion/week uses of bg sync fwiw [06:03:43.0000] JakeA: Firefox does show a prompt for the download there to me [06:05:10.0000] JakeA: I guess that means a few popular sites have to use it, if there was some way to talk to them about a flow that involves a dialog that'd be good [06:09:20.0000] annevk: I get a prompt on Desktop, but I think it's configurable. The bg fetch spec supports starting downloads in a "paused" state, so this behaviour is fully compatible (aside from asking the user where to save the file) [06:09:53.0000] annevk: The reason it starts in a paused state, rather than using a permission prompt, is it means the download can be accepted after the page has closed [06:11:14.0000] JakeA: yeah so with explicit UI there's much less of an issue for bg fetch, but maybe it shouldn't be "background" then 😃 [06:11:34.0000] JakeA: anyway, thanks for the personal explanation, much appreciated [06:12:56.0000] annevk: that's fair. It's 'background' because it doesn't require any active client to complete. Maybe naming similar to keepalive is better? Renaming and aliasing until usage drops doesn't feel like a huge deal if we can all agree on a new name [06:13:45.0000] JakeA: "Origin Downloads" is a thing that popped into my head, but not sure how great that is [06:14:11.0000] annevk: They can be cross-origin URLs though (as long as they're CORS) [06:14:22.0000] JakeA: I'm also not sure if we need to rename APIs for this and to what extent Fx wants to implement at this point (I'd need to ask around a bit more) [06:14:40.0000] JakeA: I meant Origin for the destination, but I see how that's confusing [06:14:47.0000] JakeA: maybe Storage Downloads then [06:15:29.0000] annevk: I've avoided 'downloads' because it can also be used to eg upload a gallery of images. Naming is hard. [06:17:46.0000] JakeA: and in that case there's no storage happening either? [06:19:21.0000] annevk: The storage part of bg fetch is only for the duration of the fetch, once the fetch is complete it goes "here's your responses" and if you don't do anything with them, they're gone. [06:19:59.0000] JakeA: but I assume you tell it ahead of time what to do? [06:20:47.0000] annevk: you give it the requests ahead of time, but you don't say what happens with the responses until the "complete" event [06:21:14.0000] JakeA: oh, so code is run, hmm [06:22:01.0000] annevk: yeah, that's true. If that's a sticking point we could look at stuff like deferring that event until the user revisits the site. That might be doable. [06:22:51.0000] I'm not sure if it is [06:23:01.0000] JakeA: why not only have this and also have bg sync? [06:23:58.0000] annevk: bg sync is invisible, but won't stay alive long enough for larger fetches [06:24:39.0000] annevk: I guess you could still use bg fetch for posting a chat message, but maybe a notification is overkill? [06:26:23.0000] JakeA: the problem is the "evil" sites [06:27:02.0000] JakeA: if we always had visual UI for activity beyond the lifetime of a tab I think the whole thing is much more acceptable [06:27:56.0000] JakeA: if the user closes mail.example and sees that bar (or something appear) that'd likely be fine with them and if it appears after visiting game.example they might close it down [06:28:46.0000] JakeA: this also makes it fully transparent when sites are using your battery or are potentially tracking you, which bg sync fails at [06:29:03.0000] JakeA: I rather like those aspects [06:30:39.0000] annevk: it seems reasonable for UAs to show a notification or something while there's a pending bg sync from an origin. Also seems reasonable for that notification to be cancellable. But yeah, it starts to merge with bg fetch at that point. Might not be a bad thing. [06:32:39.0000] Yeah, not sure we need both though [06:34:03.0000] annevk: if I had to pick one for Moz to implement, it'd be bg fetch, especially if a notification would be used for both. [06:37:01.0000] Yeah, in terms of how that works it seems much more aligned with how Mozilla "thinks" about these kind of things [11:05:20.0000] annevk: ping on https://github.com/whatwg/html/pull/4759 review, should be pretty straightforward [11:20:12.0000] Domenic: I cannot r+ from here, but looks good [11:21:27.0000] Domenic: does seem like we need an abstraction for hyperlink elements as we also forgot SVG a for :link and such right? [11:22:10.0000] Yeah, I mean, it's kind of unclear how much of that is our responsibility, but that's probably the right move [12:34:48.0000] I doubt anyone else will take it on, but that would be nice 2019-08-14 [17:30:01.0000] PSA, I see that the IETF is now exploring something they are calling “Evolving Documents”, which seem to be Living Standards by another name [17:30:04.0000] maybe [17:30:09.0000] https://mailarchive.ietf.org/arch/msg/ietf/O0okVR4_wqCh43QWtmJjNeYvsp8 [17:30:32.0000] https://www.ietf.org/mailman/listinfo/evolving-documents [17:30:47.0000] http://owl-stretching-time.com/presentations/slides_evolvingdocuments/#/ [17:31:32.0000] hmm, or maybe “Checkpoint Drafts” now [22:38:09.0000] Once https://developer.github.com/actions/managing-workflows/creating-and-cancelling-a-workflow/ is stable that might be a good fit for RD publication [22:38:59.0000] MikeSmith: is it more than non-substantive errata? [23:16:22.0000] “RFCs MAY NOT reference checkpoint docs” seems useless and also incorrect usage of 2119 [01:27:51.0000] annevk: Yeah, after looking through the presentation, I see it's not really what I'd assumed [01:28:37.0000] I now don't actually understand at all what the point of it is [06:16:25.0000] Yeah it seems like it's for non-specs mostly, sad. [06:34:44.0000] Domenic: https://github.com/whatwg/html/pull/4617 is still pending you to have a look [06:35:00.0000] dtapuska: on my list for today, thanks [06:36:59.0000] dtapuska: Domenic: is this blocked on the questions in https://github.com/whatwg/html/issues/4782? [06:38:43.0000] Hmm I thought yesterday you said it was good and I should just have a look [06:41:12.0000] Domenic: yeah, I think it's fine, and I don't think expanding on those scenarios will tell me something new, but I did mean to ask about it [06:46:16.0000] OK cool, will try to think about it [09:01:06.0000] dtapuska: do you feel like you have a plan for snapshotting/IPC issues in https://github.com/whatwg/html/pull/4787 ? [10:14:12.0000] domenic: I'd like to hear from smaug____ on that one... I don't think it is hard to snapshot it.. but I don't know if it would do much good.. I think really the stuff boris is thinking should be fixed via not processing the IPCs [11:26:01.0000] Would that be solved by grouping the IPC stuff so you don’t end up with races? 2019-08-16 [01:02:31.0000] So we have GitHub Actions for WHATWG, but they're also still in beta... [02:07:33.0000] Ms2ger: thanks for pinging about that dump() call [02:07:35.0000] I suck [02:08:56.0000] I blame the lint for not catching it [02:09:42.0000] wpt lint is a bit silly [02:09:50.0000] complaining about some web API usage [02:09:53.0000] like setTimeout [02:10:39.0000] smaug____: there's a reason for t.step_timeout though [02:11:14.0000] smaug____: two even, I think; making sure exceptions from the timeout call are attributed to the test and allowing for longer timeouts on slow architectures [02:11:33.0000] lint doesn't suggest using t.step_timeout, but the global setTimeout [02:11:48.0000] I always prefer using the stuff we ship for testing [02:11:54.0000] not some wrappers on the stuff [02:12:27.0000] (mochitest also complains about anything else but setTimeout(,0) ) [03:09:41.0000] Has anyone tested