` [03:18:04.0411] (the place for non-existing feature requests is on GitHub) [03:19:32.0239] I really like this highlighting, I wished it worked on https://w3c.github.io/webappsec-csp/ [03:19:51.0677] OK, then fetch spec request: I wish fetch was updated to work with this feature :p [03:20:20.0298] > <@jgraham_:matrix.org> OK, then fetch spec request: I wish fetch was updated to work with this feature :p the place for fetch spec requests is on GitHub :) [03:21:38.0926] Yep, I can of course file a GitHub issue. Although apparently moaning here was effective in that it quickly identified the source of the problem. [03:28:43.0419] > <@annevk:matrix.org> Domenic: were you going to take on the `hgroup` thing? I don't think I'll get to it before somewhere next week, but there's a small chance I have enough time later today to give it a go. I can give it a try but higher priority things might interrupt. If you could chip in and upload whatever progress you make that'd be great. [03:28:55.0009] I won't work on it for at least another 16 hours. [07:15:21.0736] > <@domenicdenicola:matrix.org> Cut and paste is what I use That is an awful lot of additional clicks to wrap changes in a PR like: https://github.com/whatwg/html/pull/8447/files [07:16:06.0088] Or are the rules for wrapping written out somewhere so I can do them as I go? I'm thinking, how to properly split element across boundary, etc. It does not seem obvious where splits are allowed or not. [08:47:03.0477] I think we just split wherever the latest space character is before 100 lines [08:48:40.0023] FWIW we've been working to port the great rewrapper to a tool that you can run on the spec file itself. It will (soon) only impact the diff of your current branch: https://github.com/domfarolino/specfmt [09:16:44.0572] Dominic Farolino: will that work for Bikeshed and Wattsi? [09:17:51.0437] Dominic Farolino: seems like it might, wow, thank you so much for tackling that. I hope it works well as that would indeed help contributors (and reviewers!) quite a bit. [09:19:54.0314] Jake Archibald: ^^ [09:20:33.0835] ohhhh very nice! [09:20:55.0278] Yeah it doesn't discriminate on any kind of file type really, but for right now at least it is basically just the rewrapper in non-website form + some "automatically find the spec file to format in this directory" logic. I'm now working on making it only apply to the changes in your current branch [09:21:14.0917] And later ideally it would do more than just rewrapping, but not sure how far we want to go with that heh [09:22:24.0314] Dominic Farolino: it'd be great if it could support annevk-style wrapping, where it never wraps in the middle of terms (like definitions or references), so ctrl+f still finds stuff [09:25:31.0472] Yeah honestly that is very nice, having to \s+ everywhere is somewhat tiresome and something one easily forgets [09:31:39.0504] Dominic Farolino: if we can get to the point where we can enforce it in CI (or make it do fixups) that would be the best. Would essentially remove an entire category of review feedback and churn. [10:02:19.0950] I do personally prefer annevk-style rewrapping, but IIRC there is some disagreement around that more generally. I guess even if we use it from here on out, we'd still have to use \s+ for all the old lines that we aren't changing....unless we go back and do those. [10:02:38.0429] Something like a "CI" mode sounds like a very good idea [10:13:28.0564] Dominic Farolino: at least for my specs I'd want this to apply to the whole file as some kind of Meta reformat commit and then enforce the tooling for all commits [10:24:50.0671] Makes sense, that could be configurable [11:51:27.0351] this future automated world sounds very nice, thanks for working on it! [11:52:30.0302] for now, though, it sounds like I can split at any space character, except in the middle of a span or dfn because we want to ctrl-f terms? [11:52:46.0211] * for now, though, it sounds like I can split at any space character, except in the middle of a span or dfn because we want to ctrl-f terms? [13:27:40.0788] wanderview: for HTML you make the longest possible string and split on the first space before 100 columns [13:27:53.0336] (or at 100 columns, I suppose) [13:28:01.0506] even if its in the middle of a span reference? [13:28:18.0373] wanderview: yeah HTML is one of the specs where you need to litter your searches with \s+ [13:28:27.0579] ok, thanks [13:28:36.0894] I've been searching for the concept-document-foo tags instead [13:28:44.0498] wanderview: it's documented at https://github.com/whatwg/html/blob/main/CONTRIBUTING.md#source-formatting [13:28:56.0635] wanderview: that works if there's a data-x, but that isn't always the case [13:29:15.0660] thanks again 2022-11-04 [02:34:28.0380] https://duckduckgo.com/mac [03:10:06.0604] Hey, I'm wondering if this is an appropriate place to ask about the implications of COOP and pop ups in general? [03:11:58.0267] I see Matrix has threads now, so I'll just drop my question here [03:14:20.0478] * We have an extension that we use to open two windows side by side and then record the screen for user research. One of these windows opens an arbitrary document. With the move to Manifest V3 and the evolution of the web standards we are working on moving away from the extension in favour of just using a website. [03:20:38.0678] Hmm, Matrix seemed to duplicate my message here but then it didn't. Anyway: We have an extension that opens two windows side-by-side and records the screen for user research. One of these windows opens an arbitrary document. With Manifest V3 coming and improvements to web standards we are looking to move away from the extension in favour of just a website. We've had good initial success with `window.open` to open and position the two windows side by side. However, we've recently realised that COOP(when the origin sets same-origin) puts a spanner in the works. We really only need the ability to open popups, position them, close them, and change their URL. It seems that with COOP we are dead in the water on the closing and changing URL components of this however. So I guess my question is: With a more widespread deployment of COOP there is no way to achieve our goals here(outside of keeping an extension?). [03:21:05.0376] * Hmm, Matrix seemed to duplicate my message here but then it didn't. Anyway: We have an extension that opens two windows side-by-side and records the screen for user research. One of these windows opens an arbitrary document. With Manifest V3 coming and improvements to web standards we are looking to move away from the extension in favour of just a website. We've had good initial success with `window.open` to open and position the two windows side by side. However, we've recently realised that COOP(when the origin sets same-origin) puts a spanner in the works. We really only need the ability to open popups, position them, close them, and change their URL. It seems that with COOP we are dead in the water on the closing and changing URL components of this however. So I guess my question is: With a more widespread deployment of COOP there is no way to achieve our goals here(outside of keeping an extension?). [03:26:49.0593] * Hmm, Matrix seemed to duplicate my message here but then it didn't. Anyway: We have an extension that opens two windows side-by-side and records the screen for user research. One of these windows opens an arbitrary document. With Manifest V3 coming and improvements to web standards we are looking to move away from the extension in favour of just a website. We've had good initial success with `window.open` to open and position the two windows side by side. However, we've recently realised that COOP(when the origin sets same-origin) puts a spanner in the works. We really only need the ability to open popups, position them, close them, and change their URL. It seems that with COOP we are dead in the water on the closing and changing URL components of this however. So I guess my question is: With a more widespread deployment of COOP is there no way to achieve our goals here(outside of keeping an extension?). [03:42:33.0001] * I see Matrix has threads now, so I'll just drop my question here, I can delete the whole thread if the question isn't appropriate here [08:36:05.0903] annevk: Should I rewrap adjacent lines to the ones I'm touching (like if they end up significantly under 100 chars, etc) or should I prefer to leave untouched lines alone to reduce conflicts? [11:49:09.0508] hmm, anyone familiar with these conformance failures I'm getting in my html PR build? running build.sh locally doesn't produce these errors [11:49:10.0798] https://github.com/whatwg/html/actions/runs/3396297480/jobs/5647202077 2022-11-05 [17:15:04.0627] > <@k0nserv:matrix.org> Hmm, Matrix seemed to duplicate my message here but then it didn't. Anyway: > > We have an extension that opens two windows side-by-side and records the screen for user research. One of these windows opens an arbitrary document. With Manifest V3 coming and improvements to web standards we are looking to move away from the extension in favour of just a website. > > We've had good initial success with `window.open` to open and position the two windows side by side. However, we've recently realised that COOP(when the origin sets same-origin) puts a spanner in the works. We really only need the ability to open popups, position them, close them, and change their URL. It seems that with COOP we are dead in the water on the closing and changing URL components of this however. > > So I guess my question is: With a more widespread deployment of COOP is there no way to achieve our goals here(outside of keeping an extension?). In general, if a website does not want you to control their content, you cannot. In particular if they use COOP to deny you from having such control. One day we might even make COOP the default, like it should have been from the beginning, so that websites have to give up such control affirmatively. [17:15:33.0276] > <@wanderview:matrix.org> annevk: Should I rewrap adjacent lines to the ones I'm touching (like if they end up significantly under 100 chars, etc) or should I prefer to leave untouched lines alone to reduce conflicts? I generally rewrap per "paragraph", i.e. `\n\n`-delimited chunk [17:16:11.0141] > <@wanderview:matrix.org> https://github.com/whatwg/html/actions/runs/3396297480/jobs/5647202077 This is due to https://github.com/whatwg/whatwg.org/issues/401 . Not your fault, don't worry about it, and we'll hope to have it fixed soon. 2022-11-06 [05:44:20.0460] HTML spec question: I can't find where it's defined (if at all) which `submitter` is chosen when e.g. the user presses `enter` in a text input field. Am I missing something? An old conversation that I don't have context for? [05:44:33.0330] * HTML spec question: I can't find where it's defined (if at all) which `submitter` is chosen when e.g. the user presses `enter` in a text input field. Am I missing something? An old conversation that I don't have context for? [06:00:53.0132] > <@noamr:matrix.org> HTML spec question: I can't find where it's defined (if at all) which `submitter` is chosen when e.g. the user presses `enter` in a text input field. Am I missing something? An old conversation that I don't have context for? https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission [06:23:49.0324] > <@abotella:igalia.com> https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#implicit-submission OK so what I found is a WebKit bug and not a spec bug, will file. Many thanks! 2022-11-07 [01:21:35.0496] annevk: I'm done for the night, but I think I've teed up all the PRs at https://github.com/whatwg/whatwg.org/issues/401 . They should be ready to merge. If you merge the stylesheet and the specs aren't immediately re-built it looks fine, the subheading is just small and boring. So I think you should try to merge ASAP to unblock the various PRs across the ecosystem. I'll be back in some hours and can help then. I think we don't have access to merge https://github.com/tabatkins/bikeshed-boilerplate/pull/29 so hopefully TabAtkins can do so when he wakes up. [01:28:26.0103] Right, I think that makes sense. I found it surprising that APIs like `window.open` and the resulting `WindowProxy` are impacted by this(website controlling their content). I understand how changing the URL to load a different document after a site is loaded can be problematic(e.g. bankofamerica.com to bankofamerica.evil.com) but I don't see how positioning and closing the window is [01:29:04.0900] I tried to look for discussions around these changes to see if any of these concerns were raised but couldn't find anything, do you know if such context exists? [01:29:44.0049] * Right, I think that makes sense. I found it surprising that APIs like `window.open` and the resulting `WindowProxy` are impacted by this(website controlling their content). I understand how changing the URL to load a different document after a site is loaded can be problematic(e.g. bankofamerica.com to bankofamerica.evi..com) but I don't see how positioning and closing the window is [01:29:55.0648] * Right, I think that makes sense. I found it surprising that APIs like `window.open` and the resulting `WindowProxy` are impacted by this(website controlling their content). I understand how changing the URL to load a different document after a site is loaded can be problematic(e.g. bankofamerica.com to bankofamerica.evil.com) but I don't see how positioning and closing the window is [01:33:48.0023] * Right, I think that makes sense. I found it surprising that APIs like `window.open` and the resulting `WindowProxy` are impacted by this(website controlling their content). I understand how changing the URL to load a different document after a site is loaded can be problematic(e.g. bankofamerica.com to bankofamerica.evil.com) but I don't see how positioning and closing the window is. Neither of those three operations(positioning, closing the window, or changing the URL) feel like they meet the definition of "control their content" to me. From the perspective of the opener the opened website is a black box here [01:34:37.0394] * I tried to look for discussions around these changes to see if any of these concerns were raised but couldn't find anything, do you know if such context exists? [01:34:38.0229] Thanks, I'll have a look in a bit [01:52:43.0401] Domenic: I'm still on vacation, I won't be in the office until Friday [01:53:14.0654] Oh but I can do a merge [01:53:32.0202] TabAtkins: thanks and enjoy! [02:01:06.0073] Hugo Tunius: resizing and positioning a window is definitely pretty abuse-prone. Imagine taking trustedbank.example's window and making it fly around the screen like a ping-pong ball. Who do you think the user's going to blame? The bank, or the mysterious opener window which has some hidden programmatic connection to it the user is not aware of? [02:01:39.0232] Similarly imagine closing the window randomly, making it look like the site is crashy or broken... [02:03:15.0941] Domenic or annevk: actually I only have Internet on my phone, so I can't run the manifest regen. Could one of y'all run the generate/__init__.py script and add it to your pr? [02:03:22.0144] Also I'll give y'all edit rights [02:04:51.0568] Wait what's Anne's github [02:05:08.0959] It's annevk [02:05:20.0770] Weird, wasn't showing up. I'll try again [02:05:29.0842] Oh because I did the thing I always do [02:05:39.0870] And try to search for then among the existing collabs [02:06:08.0421] I have confirmed write access so can merge later tonight if necessary. Thanks so much! [02:06:32.0275] Np, just remember to run the regen or else Bikeshed won't pick up any changes. [02:06:44.0728] I need to put that into ci super bad [02:07:39.0933] Domenic: You're right that you could do that. I guess I didn't think of that from the "control of their content" angle though. Thanks for clarifying [02:08:21.0750] Do you know if there are any discussions from the COOP spec work that goes deeper into these motivations? [02:08:52.0753] I'm not aware, I think everyone just had it as background knowledge that allowing cross-origin opener control has been a mistake since the beginning of the web, and it's good to cut that off as much as possible. [02:09:23.0080] Aight. Thanks again for the explainer, it was helpful [02:09:38.0953] * I'm not aware, I think everyone just had it as background knowledge that allowing cross-origin opener control has been a mistake since the beginning of the web, and it's good to cut that off as much as possible. [02:38:52.0277] Hugo Tunius: there's a bunch of design discussion on whatwg/html; but as it essentially inverses rel=noopener, it was quite intentional [02:39:09.0607] Domenic: all reviewed and pushed some nits; Bikeshed PR merged [02:40:42.0569] I guess with the Bikeshed PR merged, specifications ought to be able to build again [02:46:25.0393] I keep typing https://w3c.github.io/csswg-drafts/indexes as "indices" [02:46:30.0933] maybe adding a redirect would help [02:51:37.0051] Hmm so bikeshed-data is updated, but it's not reflected by any tooling... [03:59:43.0908] Gotta run bikeshed update? [04:00:00.0620] Maybe the CSSWG CI server does not do that often... [04:17:38.0881] PRs should be working again now; they might need a rebase. [04:26:10.0258] As I said, the regen script needs to be run, to update the manifest file, before Bikeshed will pick up the new data. [04:26:55.0074] (And then the updated manifest checked in.) [05:15:51.0842] TabAtkins: I did that and bikeshed-data did pick it up; it's just api.csswg.org that hasn't yet at this point [05:16:19.0500] * TabAtkins: I did that and bikeshed-data did pick it up; it's just api.csswg.org that hasn't yet at this point 2022-11-08 [04:08:34.0441] So I'm trying to integrate WebDriver BiDi network events into fetch, and I'm struggling to work out where to call the various lifecycle update algorithms. The BiDi model is basically that you get the following events: `beforeRequest`, `responseStarted`, `responseCompleted`, `fetchError`. The invariants are that every request (including redirects etc.) gets a `beforeRequest` event and either `responseStarted`/`responseCompleted` or `fetchError` (and maybe `responseStarted` if the error happens after the response headers are received). I _think_ the end-of-lifecycle events can be handled in the "fetch response handover"? But what I'm less sure about is guaranteeing that there's always a matching `beforeRequest` event with the headers as-sent (or as seen by whatever prevents the request going over the wire e.g. serviceworker or cache). I think the headers requirement means that in the case where the request isn't blocked we need to emit it right before sending. But because the request may be blocked at various points before that, we can end up in "fetch response handover" without having emitted a `beforeRequest` event. But there can also be an error which occurs after it's sent, so we can end up there when we _have_ already emitted that event. Is there something simpler to do here than add extra state to the request, indicating whether we already emitted such an event? Obviously I'd prefer not to add more state if possible because state is complexity, but I'm not seeing an obvious alternative. [04:09:58.0281] * So I'm trying to integrate WebDriver BiDi network events into fetch, and I'm struggling to work out where to call the various lifecycle update algorithms. The BiDi model is basically that you get the following events: `beforeRequest`, `responseStarted`, `responseCompleted`, `fetchError`. The invariants are that every request (including redirects etc.) gets a `beforeRequest` event and either `responseStarted`/`responseCompleted` or `fetchError` (and maybe `responseStarted` if the error happens after the response headers are received). I _think_ the end-of-lifecycle events can be handled in the "fetch response handover"? But what I'm less sure about is guaranteeing that there's always a matching `beforeRequest` event with the headers as-sent (or as seen by whatever prevents the request going over the wire e.g. serviceworker or cache). I think the headers requirement means that in the case where the request isn't blocked we need to emit it right before sending. But because the request may be blocked at various points before that, we can end up in "fetch response handover" without having emitted a `beforeRequest` event. But there can also be an error which occurs after it's sent, so we can end up there when we _have_ already emitted that event. Is there something simpler to do here than add extra state to the request, indicating whether we already emitted such an event? Obviously I'd prefer not to add more state if possible because state is complexity, but I'm not seeing an obvious alternative. [04:44:05.0351] Domenic is so optimistic with https://github.com/whatwg/html/pull/6315#pullrequestreview-1158013824 🙂 no regressions with session history stuff? [04:44:38.0489] Session history is the one component where regressions are pretty much guaranteed whenever anything changes. [04:47:15.0794] /me just fixed yet another issue he caused 2 years ago. Some site did effectively: location.reload(); location.href = "newpage"; and that right after there were something like 5 http redirects [04:47:48.0201] /me * just fixed yet another issue he caused 2 years ago. Some site did effectively: location.reload(); location.href = "newpage"; and that right after there were something like 5 http redirects [15:37:16.0054] Is it preferred to have more small algorithms or fewer larger algorithms? [15:38:22.0592] I've been looking into splitting out https://w3c.github.io/FileAPI/#slice-method-algo into a algorithm so range requests can use it, and I'm uncertain if i should have slice-bytes and normalize-range or just a slice-blob algorithm [15:41:09.0519] * context: I've been looking into splitting out https://w3c.github.io/FileAPI/#slice-method-algo into a algorithm so range requests can use it, and I'm uncertain if i should have slice-bytes and normalize-range or just a slice-blob algorithm 2022-11-09 [00:09:47.0200] dlrobertson: I think whatever makes the spec clearer / easy to follow. Though there's also some value in matching implementations, if that is sufficiently easy to follow [00:14:21.0344] dlrobertson: I consider splitting something if it would end up with two callers, and definitely do it if there's more callers than that [00:15:15.0049] dlrobertson: and yeah, sometimes it can greatly benefit readability even if there's only a single caller, so as with most things there's a lot of "it depends" :-) [08:03:50.0187] zcorpan: annevk thanks for the tips... i'll give splitting it up a shot and we'll see what happens in review haha 2022-11-10 [02:33:44.0853] interesting paper, "WebSpec: Towards Machine-Checked Analysis of Browser Security Mechanisms" pre-print at https://arxiv.org/abs/2201.01649. They use proof assistant and formalized model to identify security invariants in the web platform [02:35:17.0143] Did they find any? 😅 [04:00:37.0698] Ms2ger 💉💉💉: freddy: " The mismatch between the access control policies in the DOM and the cookie jar allows a script running in an iframe to access the document.cookie property of the parent page when both pages set document.domain to the same value." [04:01:19.0458] not sure that's a novel attack though [04:03:07.0259] the next sentence is " Once the inner frame performs a set cookie of a host-prefix cookie through the parent page DOM, the browser uses the original domain value of the parent page to perform the host prefix checks, breaking the invariant." [04:06:17.0900] So, for academics, the title "towards" basically hints to that. I think the main achievement is being able to generate/deduce bugs, even if they are known edge cases. [04:10:59.0121] interesting point about restricting Trusted Types to secure contexts created an easy bypass [04:31:48.0060] How did that create an easy bypass? [06:03:17.0682] annevk: you can frame from unsecure context [06:03:42.0177] annevk: https://github.com/w3c/trusted-types/issues/259#issuecomment-630863753 [06:06:31.0016] TabAtkins: ping https://github.com/whatwg/html/pull/8175 :) [06:09:10.0017] I'm still on vacation until Friday [06:10:04.0231] TabAtkins: ok, enjoy your vacation :) Would you like a ping next week? [06:10:26.0664] Yes, please! [10:20:13.0492] anyone in here active on mastodon? I'm looking to increase my coverage of web standards discussion there as I'm less active on twitter... (I'm at wanderview@toot.cafe) [14:50:53.0634] Bocoup is looking to hire someone with experience in web standards: https://twitter.com/bocoup/status/1590754781358084097 [14:53:27.0961] wanderview: I'm https://mastodon.social/@zcorpan , maybe you've also seen this tool to find people from twitter https://glitch.com/~fedifinder 2022-11-11 [17:51:52.0625] Domenic: So I guess because of daylight-savings time, the HTML spec-triage meeting is now at 9am Tokyo time rather than 8am. So I didn’t attend because I can’t do 9am meetings any day of the week. I could still do 8am or else 9:30 [17:53:37.0322] Not that I’m essential but I just wanted to say my reason for not attending wasn’t lack of interest [17:56:03.0274] Aww OK, good to know. I think moving back might be nicer for all non-Tokyo people too, so maybe we should do so... Want to file an issue and tag the triage team? [17:57:42.0593] sure, will do [00:15:45.0983] Navigation API almost entirely rebased on new HTML infrastructure... time to work on a HTML PR for it, as promised. [03:29:37.0726] `popover` looks pretty good now 2022-11-13 [21:42:25.0477] does anyone have a pulse on csp for webrtc and webtransport [21:42:57.0915] the github issues do not look promising [01:16:21.0910] Seems like another case of people trying to use CSP for exfiltration prevention, which it isn't designed for? 2022-11-14 [23:37:51.0350] Well it is, it might not be maintained to the extent needed though. [02:26:26.0802] Domenic: as I was looking at reflect for ARIA I came across https://github.com/whatwg/html/issues/3238 again and was wondering if you changed your mind on doing it incrementally [02:27:20.0970] Domenic: not necessarily volunteering, but if we dropped enumerated attributes or did things one-by-one as we had time I think it would be much more tractable [02:58:50.0293] annevk: Yeah I think I've changed my mind, incrementally (especially if we do everything except enumerated attributes first) is reasonable [04:45:33.0987] Getting there... https://whatpr.org/html/8502/nav-history-apis.html#navigation-api [06:06:39.0407] > <@tabatkins:matrix.org> Yes, please! ping https://github.com/whatwg/html/pull/8175 :) [14:55:57.0134] thanks! 2022-11-15 [17:18:44.0898] does anyone know what happened to the chromium codebase? it says access denied to me for some reason https://source.chromium.org/chromium [17:28:24.0783] > Could not load project* [19:03:46.0848] does anyone else see that too? [19:37:24.0301] It loads for me [20:50:41.0552] Hmm 🤔 [01:39:10.0723] annevk: FYI https://stackoverflow.com/questions/74308367/how-to-protect-api-from-domain-manipulation-in-hosts-file/74443117#74443117 — lemme know if I’m off in any way on what I say there (or just comment there) [01:47:25.0895] I'm not sure I understand what OP is describing there, seems a bit contradictory to have all users be anonymous but not essentially have public data [02:06:21.0729] > <@annevk:matrix.org> I'm not sure I understand what OP is describing there, seems a bit contradictory to have all users be anonymous but not essentially have public data yeah that part of the question I didn’t try to address — but instead just the general part about what effect editing the Hosts file would have [03:56:34.0723] https://i.imgflip.com/70twbz.jpg [04:28:37.0561] Two origins, both alike in dignity; on the open web, we lay our scene… [05:43:56.0199] rego: https://github.com/whatwg/html/pull/8496 [05:44:30.0332] > <@annevk:matrix.org> rego: https://github.com/whatwg/html/pull/8496 I have it on my radar but haven't find time to check it yet, sorry 2022-11-16 [21:00:42.0665] > <@domenicdenicola:matrix.org> Seems like another case of people trying to use CSP for exfiltration prevention, which it isn't designed for? out of curiosity do you have any ideas on alternatives? it seemed to me that CSP was intended for this (among other things) so if there's something else i should be looking at instead i'd be very interested [21:04:18.0440] Don't run untrusted code on your page? [21:04:23.0799] lol [21:04:31.0027] CSP is designed to prevent XSS, so that you can achieve that goal [21:04:32.0634] thats generally my philosophy as well [21:05:02.0678] Once there's untrusted code on your page though through XSS (including self-XSS), there's no good technology to prevent it from doing various network requests [21:05:38.0967] looks like they added a `connect-src` check to chromium's webtransport code [21:05:42.0150] * looks like they added a `connect-src` check to chromium's webtransport code [21:05:45.0943] so that's nice [21:06:25.0160] guess its just down to webrtc [21:07:11.0800] Some discussion on https://blog.compass-security.com/2016/10/bypassing-content-security-policy-with-dns-prefetching/ , not a primary source though [21:07:52.0317] i guess i'm sort of being the person i always hate, some random guy from a company trying to do something that is probably a dumb idea :) [21:07:52.0637] https://www.cse.chalmers.se/~andrei/asiaccs16.pdf is better [21:09:29.0612] That paper gives quite a good overview actually, in section 2.2 [21:11:19.0055] discord has an interesting feature called activities which is basically little games and stuff you can play with your friends. the problem is that these games are written as web apps, so currently we can't really open them up to random third party developers. i'm exploring some ways to make things better, and i really don't want my endpoint to be "full wasm sandbox that draws to a canvas" cuz that sucks in many many ways [21:42:14.0723] Sandboxed iframes? [21:42:33.0512] I guess that doesn't really have exfiltration controls either, sorry, forgot the threat model [21:42:55.0659] If you ensure no interesting information gets into the sandboxed iframe to exfiltrate, maybe [21:45:39.0036] yeah the iframes are already pretty locked down. the interesting thing i discovered is that you can work around it _slightly_ by creating an iframe (inside the sandbox iframe) with no src, which gives you a fresh window instance somehow? so none of our safety scripts have run yet [21:47:55.0381] * yeah the iframes are already pretty locked down. the interesting thing i discovered is that you can work around it _slightly_ by creating an iframe (inside the sandbox iframe) with no src, which gives you a fresh window instance somehow? so none of our safety scripts have run yet [22:22:51.0653] lol this makes me sad https://csplite.com/csp/test368 [22:24:21.0937] i have no idea who runs this site [22:25:46.0417] hah same thing https://github.com/web-platform-tests/wpt/blob/master/content-security-policy/frame-src/frame-src-about-blank-allowed-by-default.sub.html [23:47:38.0424] annevk: https://github.com/mdn/content/issues/22333 [00:00:24.0002] sideshowbarker: the spec is pretty clear, the getter invokes https://url.spec.whatwg.org/#url-path-serializer [00:02:41.0107] Yeah the MDN wording just needs to be fixed [00:03:09.0021] I hope some contributor picks up the issue so that I don't have to [00:03:31.0303] It should be a quick fix [00:03:52.0915] * I hope some contributor picks up the issue so that I don't have to [01:05:03.0564] Domenic: I think you're right that it'll be awkward at best to define content attributes for ElementInternals... One problem with doing [Reflect] is that ARIA really needs enumerated attributes and we don't have a thing for that as of yet. But maybe a structured table in prose could be sufficient. [03:34:49.0090] Right... ideally ARIA would define its various content attributes as enumerated attributes, and the ElementInternals part could delegate to those definitions? [03:35:00.0204] But so far ARIA doesn't really have that level of rigor anyway [14:49:19.0163] Why does `new URL("https://developer.mozilla.org").pathname` give `"/" `? Based on https://url.spec.whatwg.org/#url-path-serializer, I would expect it to be the empty string instead. …in that, if the URL has no path segments, the `pathname` value should be the empty string. What path segments does `https://developer.mozilla.org` have? 2022-11-17 [16:31:51.0398] Pretty sure it has a "" path segment... let's see [16:33:17.0199] Yes: [16:44:12.0466] I see [16:44:27.0848] That's... unintuitive [16:46:53.0823] So then the other question is, what's an example of a hierarchical URL which has the empty string for its `pathname`? [16:47:50.0582] Is it possible for a hierarchical URL to ever have the empty string for its `pathname`? [17:13:23.0051] I don't think so [18:38:39.0705] annevk: hsivonen: Is XML5 actually feasible to replace XML parsers in browsers, or would introducing it run into the same problems of cross-ecosystem parser algorithm drift that causes us to disprefer making changes to the HTML parser? Is the idea that XML is used very little so we're less worried about the security issues? Or that the benefit is so large that it'd be worth the one-time churn? Or was the idea always for XML5 to be a third parser that sits alongside HTML and XML? [22:39:32.0068] so now I’m wondering if there’s _any_ real-world URL — for any scheme — that’ll ever have the empty string for its `pathname` [22:40:28.0518] anything I can imagine that would have any real use is gotta have _something_ after the `:` — and so, have a `pathname` [22:40:41.0452] …I mean, any URL that identifies some real resource [23:18:00.0404] Domenic: my idea was always that it would replace the XML parser and because it's generic and doesn't have language-specific knowledge it would be a one-time ecosystem cost [02:05:08.0708] annevk: https://stackoverflow.com/questions/74301267/are-browser-credentials-resubmitted-when-a-javascript-fetch-redirects [05:33:48.0516] > <@domenicdenicola:matrix.org> annevk: hsivonen: Is XML5 actually feasible to replace XML parsers in browsers, or would introducing it run into the same problems of cross-ecosystem parser algorithm drift that causes us to disprefer making changes to the HTML parser? Is the idea that XML is used very little so we're less worried about the security issues? Or that the benefit is so large that it'd be worth the one-time churn? Or was the idea always for XML5 to be a third parser that sits alongside HTML and XML? It would replace the XML parser. Since XML5 doesn't involve rules like what autocloses HTML `p` or HTML void elements, it wouldn't be subject to the same kind of drift. However, considering the general way of how people working on the Web Platform perceive XSS holes arising from syntax issues these days, perhaps the way XML 1.0 vs. XML5 is perceived has shifted a bit back towards XML 1.0. [07:45:44.0864] It would also move away from browser XML parsers being compatible with the rest of the ecosystem, which leads to potential exploits based on differential behaviour, which seems… likely bad. [07:46:25.0794] I don't expect realistically we'd be able to move the entire XML ecosystem, beyond browsers. For enough applications strict error-handling is viewed as a feature. [07:52:42.0538] Is there anything the specifications can do to prevent sites from detecting browser developer tools and refusing to serve content if detected. [07:55:53.0856] No [07:56:31.0513] Oh okay. [07:57:25.0733] For WebDriver-ish tools being detectable is considered a feature. For general devtools it seems highly likely that you'll always be able to figure out that they're running somehow if you're sufficiently motivated. [07:59:08.0281] Shouldn't browsers try to prevent such detection? [08:00:57.0020] Or are you saying that no matter what a browser does, devtools could always be detected? [08:02:19.0486] I think you could always detect them. [08:02:45.0104] That is sad. Thanks for the info! [12:39:46.0313] Hi there. I'm new here but, as I'm designing a principled CORS middleware, I have some questions. annevk suggested I ask them here (see https://github.com/whatwg/fetch/issues/1517#issuecomment-1291627075). Would that be alright? [12:40:07.0577] * Hi there. I'm new here but, as I'm designing a principled CORS middleware library for Go, I have some questions. annevk suggested I ask them here (see https://github.com/whatwg/fetch/issues/1517#issuecomment-1291627075). Would that be alright? [12:43:56.0188] howdy jub0bs — yup, you should go ahead and ask [12:45:02.0424] I've got some concerns about this section of Jake's post about CORS: https://jakearchibald.com/2021/cors/#conditionally-serving-cors-headers [12:45:34.0989] In particular, this: > If a resource contains private data when it's requested with cookies, but you only want to expose the without-cookies data, then it's best to only include the `Access-Control-Allow-Origin: *` header if the request doesn't have a `Cookie` header. [12:45:49.0807] * In particular, this: > If a resource contains private data when it's requested with cookies, but you only want to expose the without-cookies data, then it's best to only include the Access-Control-Allow-Origin: \* header if the request doesn't have a Cookie header. [12:46:11.0667] * In particular, this: > If a resource contains private data when it's requested with cookies, but you only want to expose the without-cookies data, then it's best to only include the `Access-Control-Allow-Origin: *` header if the request doesn't have a `Cookie` header. [12:48:50.0440] This implies a CORS middleware library should vary the response based on the presence or absence of a cookie header, which is taken as a cue that the request is credentialed. This is problematic, as the absence of a `Cookie` header doesn't guarantee that the request was anonymous (e.g. it could use Basic Auth). [12:50:19.0780] Am I missing something? What do people think about this approach? [12:55:50.0924] There's more. Further down, we're encouraged to responds with `Vary: Cookie` in some circumstances. But isn't that terrible for CDNs / Web caches, since cookie values tend to differ from one user to the next? To quote https://fastly.com/blog/best-practices-using-vary-header#vary-cookie: > `Vary: Cookie` > > `Cookie` is probably one of the most unique request headers, and is therefore very bad. [12:56:10.0401] * There's more. Further down, we're encouraged to responds with `Vary: Cookie` in some circumstances. But isn't that terrible for CDNs / Web caches? To quote https://fastly.com/blog/best-practices-using-vary-header#vary-cookie: > `Vary: Cookie` > > `Cookie` is probably one of the most unique request headers, and is therefore very bad. [12:56:50.0182] * There's more. Further down, we're encouraged to responds with `Vary: Cookie` in some circumstances. But isn't that terrible for CDNs / Web caches, since cookie values tend to differ from one user to the next? To quote https://fastly.com/blog/best-practices-using-vary-header#vary-cookie: > `Vary: Cookie` > > `Cookie` is probably one of the most unique request headers, and is therefore very bad. [12:57:53.0210] Jake Archibald: ↑ [12:58:57.0813] * I've got some concerns about this section of Jake's (otherwise very instructive!) post about CORS: https://jakearchibald.com/2021/cors/#conditionally-serving-cors-headers [13:00:10.0536] * This implies a CORS middleware library should vary the response based on the presence or absence of a cookie header, which is taken as a cue that the request is credentialed. This is problematic, as the absence of a `Cookie` header doesn't guarantee that the request was anonymous (e.g. it could be using `Authorization: Basic xxx`). [13:00:42.0157] * Am I missing something? What do people think of this approach? [13:02:31.0302] * This implies that CORS middleware should vary the response based on the presence or absence of a cookie header, which is taken as a cue that the request is credentialed. This is problematic, as the absence of a `Cookie` header doesn't guarantee that the request was anonymous (e.g. it could be using `Authorization: Basic xxx`). [13:09:01.0008] I found a similar guideline in Brad Hill's W3C document from 2016: https://w3c.github.io/webappsec-cors-for-developers/#use-vary > If a resource is intended to be readable, truly regardless of the context of the request, first it should take care not to actually vary and reveal private information based on the presence and content of a cookie. Then it should send `Vary: Cookie, Origin` and either `Access-Control-Allow-Origin: *` for requests made without cookies or reflect the request’s `Origin` into the `Access-Control-Allow-Origin` header for credentialed requests. [13:44:27.0867] * This seems to imply that CORS middleware should vary the response based on the presence or absence of a cookie header, which is taken as a cue that the request is credentialed. This is problematic, as the absence of a `Cookie` header doesn't guarantee that the request was anonymous (e.g. it could be using `Authorization: Basic xxx`). [13:44:45.0407] * This seems to imply that CORS middleware should vary the response based on the presence or absence of a cookie header, which is taken as a cue that the request is credentialed. But this is problematic, as the absence of a `Cookie` header doesn't guarantee that the request was anonymous (e.g. it could be using `Authorization: Basic xxx`). [14:08:37.0705] > <@annevk:matrix.org> rego: https://github.com/whatwg/html/pull/8496 Hi Anne! Rego pointed me at this and I think I'm as close to understanding it as I can get now - would love to find a time to talk through it if you'd be up for that 2022-11-18 [01:17:49.0652] * There's more. Further down, we're encouraged to responds with `Vary: Cookie` in some circumstances. But isn't that terrible (in terms of cache segmentation) for CDNs / Web caches, since cookie values tend to differ from one user to the next? To quote https://fastly.com/blog/best-practices-using-vary-header#vary-cookie: > `Vary: Cookie` > > `Cookie` is probably one of the most unique request headers, and is therefore very bad. [01:19:12.0915] jub0bs: you have to know that Set-Cookie is never used for the response, whether middleware has that information depends [01:20:41.0799] Alice: happy to meet next week, I'm usually available 9-5 Berlin time. Could probably make 8:30 work. Earlier would be tricky, but maybe doable for a one-off. [02:33:14.0689] annevk: I guess what I'm trying to figure out is, under the assumption that there are legitimate cases to add `Vary: Cookie` to a response, should it be the responsibility of CORS middleware? Jake's answer (according to that section of his post) seems to be "yes". But that means CORS middleware must inspect the response to the actual request to decide what to do. None of the existing CORS middleware I've reviewed currently do that; they inspect the actual request, but not the response to it. That's why I'm surprised by Jake's post. [02:46:02.0053] annevk: Unless I missed something, the Fetch standard doesn't provide any guidance about that. The only relevant passage I found only mentions tuning the CORS headers according to the CORS request, not its response: > Ultimately server developers have a lot of freedom in how they handle HTTP responses \[...\] They can provide a dynamic response, _tuned to CORS request_. My emphasis. [02:46:09.0812] * annevk: Unless I missed something, the Fetch standard doesn't provide any guidance about that. The only relevant passage I found only mentions tuning the CORS headers according to the CORS request, not its response: > Ultimately server developers have a lot of freedom in how they handle HTTP responses \[...\] They can provide a dynamic response, _tuned to CORS request_. My emphasis. [03:04:55.0568] I don't think that sentence considers middleware as separate software from the server. [04:46:02.0413] annevk: I see, but I'm afraid I need more guidance 😀 [04:47:16.0007] Another element, which contradicts Jake's view, is this SO response by sideshowbarker : https://stackoverflow.com/a/53248240/2541573 > as far as the CORS protocol goes, the receiving server doesn’t change its behavior based on whether the request includes credentials or not. [04:49:18.0420] * annevk: I see, but I'm afraid I need more guidance :D [04:49:32.0806] * annevk: I see, but I'm afraid I need more guidance 😀 [05:32:59.0990] jub0bs: I don't think there's a contradiction there; again, that's assuming the entire non-client-side knows what it's doing [05:33:46.0409] jub0bs: the middleware situation is somewhat unique in that the middleware doesn't know whether a response flagged as * would also sometimes use Set-Cookie [05:34:50.0061] jub0bs: or even if it didn't use Set-Cookie itself, that it would take Cookie request headers into account somehow [06:07:57.0471] annevk: Now I'm no longer sure that a CORS middleware library can exist. 😟 It seems to require a lot of information about how the request is handled and the response composed. [06:54:14.0700] jub0bs: I think you can implement some kind of defaults and perhaps log a warning if they didn't explicitly declare they're not varying on Cookie headers [06:54:36.0138] jub0bs: cause in principle the origin server would have to use Vary: Cookie if they did indeed vary on Cookie, right? [06:59:57.0570] Domenic: I have questions about https://github.com/web-platform-tests/wpt/pull/37018#discussion_r1025934637 [07:00:40.0267] Per https://drafts.csswg.org/cssom-view/#scrolling-events: > If target is a [Document](https://dom.spec.whatwg.org/#document), [fire an event](https://dom.spec.whatwg.org/#concept-event-fire) named [scrollend](https://drafts.csswg.org/cssom-view/#eventdef-document-scrollend) that bubbles at target. > Otherwise, [fire an event](https://dom.spec.whatwg.org/#concept-event-fire) named [scrollend](https://drafts.csswg.org/cssom-view/#eventdef-document-scrollend) at target. [07:01:48.0450] I'm uncertain how we'd keep the event handler content attribute usable without keeping `onscrollend` where it is (with forwarding behavior) [07:02:46.0639] I guess we could change cssom-view to specify "If target is `Document` or `document.body`, ... that bubbles at target" [07:06:19.0099] Actually I think we'd want `document.scrollingElement` not `document.body` there [07:20:12.0928] dlrobertson: I don't really understand the problem? If the "otherwise" case has the target being the body, then, `` should call `foo()`. [07:29:41.0645] yeah, but it sort of requires breaking the first case right? If we expect `scrollend` for `document.scrollingElement.scroll(...)` to fire to `document.scrollingElement`, then I think the first case is never hit [07:30:13.0796] and as a result, `window.onscrollend` is never used [07:30:33.0737] I could be thinking too much on the implementation side [07:31:51.0707] Doesn't it bubble to eventually hit window.onscrollend? [07:32:14.0181] currently only if the target is `Document` [07:32:25.0554] I thought events on body bubbled to window eventually... [07:33:33.0535] > <@domenicdenicola:matrix.org> I thought events on body bubbled to window eventually... do you happen to know the relevant spec where I can read about this? [07:33:35.0476] Yeah, all events that bubble go from document to window [07:33:44.0347] And body to document [07:33:57.0060] Look at each instance of https://dom.spec.whatwg.org/#get-the-parent [07:35:52.0208] So it looks like if the viewport is scrolled, then the Document itself goes into pending scroll event targets. So it bubbles Document -> Window. If scrollingElement (= html element, I think) gets scrolled, then it bubbles html element -> Document -> Window. But event.target === the html element. Similarly if the body element gets scrolled, then it bubbles body -> html -> Document -> Window, with event.target === the body element. [07:36:37.0508] Oh wait, second case doesn't bubble [07:36:57.0371] So I guess only the Document -> Window case bubbles. Kinda strange, but whatever... [07:39:01.0226] I think that's because we currently expect forwarding behavior, I'm starting to think the first case should be expanded to `Document` or `Document.scrollingElement` [07:41:33.0385] Yeah, I guess it's strange that it's (according to that spec) possible to have some entries in the pending scroll event targets that are `Document`s, and some which are the scrolling element for the document. Not sure that distinction should exist. [07:45:56.0053] Ah that's a great point! [07:49:18.0638] I need to do a lot more reading to get a better grasp on it, but I might be headed in the right direction now [07:49:25.0372] key word _might_ [07:59:07.0106] If we're really ending up with `::part()` and `:--state` that's pretty sad [12:01:20.0415] Anybody know if there’s some reason for `dialog.showModal()` not working in Firefox Nightly despite working just fine in Firefox 107? [12:03:10.0180] see https://github.com/matrix-org/matrix-public-archive/issues/145 — I ran into this case where some code works as expected in Firefox 107, but in Firefox Nightly, it throws _Uncaught TypeError: this.dialogNode.showModal is not a function_ [12:08:28.0813] sefeng: ^ [12:16:53.0407] /me will talk to sideshowbarker privately to not spamming this room. 2022-11-20 [16:28:33.0342] PSA: #web-platform-dx:matrix.org is a newish relevant room that’s a piece of an ongoing effort “to improve the overall experience of developing for the Web platform” — in part by “enabling shared research on the pain points that developers face” https://www.w3.org/blog/2022/11/webdx-improving-the-experience-for-web-developers/ has an overview [04:24:47.0057] Hmm, do I understand correctly that there is no longer a way to send a full Referer (incl. path) on a cross-domain request? [04:25:17.0294] (even if both parties - both origins - agree that it is a good idea in this particular scenario) [05:37:40.0080] I think it's possible per spec using `referrer-policy: unsafe-url`. I think Safari decided to ignore this, so for them you have to use a query string or something. [05:43:23.0214] Hmm, I tried this in Firefox (via ). And received: `Referrer Policy: Ignoring the less restricted referrer policy “unsafe-url” for the cross-site request` [11:54:25.0686] Domenic: Heyo :) In "prepare the script element" step 32.1, we assert that el's result is "uninitialized". it seems to me that el's result could be e.g "null" at this point if "fetch an inline module script graph" returns early in step 31. Does that sound about right? [15:59:17.0135] Andreas Kling: yeah, that does sound right. Hmm, is there any better fix than just removing the assert? 2022-11-21 [16:00:59.0616] not sure [16:01:33.0510] filed https://github.com/whatwg/html/issues/8534 about it [23:24:48.0015] > <@sideshowbarker:matrix.org> PSA: #web-platform-dx:matrix.org is a newish relevant room that’s a piece of an ongoing effort “to improve the overall experience of developing for the Web platform” — in part by “enabling shared research on the pain points that developers face” > > https://www.w3.org/blog/2022/11/webdx-improving-the-experience-for-web-developers/ has an overview would be cool if there was a space for w3c+whatwg 2022-11-22 [00:11:33.0276] annevk: is there a way to forward things like `blocking` or `priority` through service workers without exposing them on `Request`? I.e. did you have some fix in mind for the latter part of https://github.com/WICG/priority-hints/issues/69#issuecomment-1322346634 besides adding a public `blocking` property? [00:12:48.0857] Oh, nevermind, it's kind of obvious how to do that. [00:13:49.0489] Right, you can take the private member and copy it to the new request created in the `Request` constructor [00:16:14.0522] I got confused between _init_ and _input_. [00:52:27.0787] Jake Archibald: https://stackoverflow.com/questions/74529733/are-all-these-multiple-checks-really-required-to-handle-a-new-service-worker-upd [02:19:37.0783] ta! [02:43:33.0236] > <@jakea:matrix.org> ta! Thanks for answering! [02:43:42.0046] No problem, thanks for flagging it [08:01:22.0442] Looking for a reviewer of straightforward Web IDL change: https://github.com/whatwg/webidl/pull/1235 [08:44:27.0380] krosylight: thanks for doing the diagram work; many people have asked for that over the years, hopefully this is something we can adopt WHATWG-wide as a thing [08:45:23.0556] > <@annevk:matrix.org> krosylight: thanks for doing the diagram work; many people have asked for that over the years, hopefully this is something we can adopt WHATWG-wide as a thing Oh, didn't know that! I was just looking at that and thought perhaps some diagram can help [08:45:47.0172] Some native Bikeshed support would be great indeed [08:46:36.0928] There's railroad stuff in Bikeshed for grammars; at one point I made an attempt for URL but it didn't really go anywhere [08:47:12.0487] For Fetch there's a request to have a diagram for how the various fetch algorithms call into each other [08:47:23.0333] It seems this ER thing can be used there [08:48:09.0862] Mermaid has several more types of diagram support, maybe worth looking at them https://mermaid-js.github.io/mermaid/#/entityRelationshipDiagram [08:50:05.0694] Given that this is an NPM stuff, not sure how Bikeshed could adopt it (if the grammar thing solves), maybe there's some useful Python implementation too [08:54:56.0026] /me *waves hands* Wasm [08:55:58.0326] Wasm. That reminds me whether we should get a common Wasm WebIDL parser [08:56:31.0349] (because plinss/widlparser doesn't seem too active) [08:57:03.0794] You should chat with TabAtkins I guess whenever they're back from vacation. [08:57:23.0406] I was back last week [08:57:31.0179] Mermaid's State Diagram looks useful for Fetch [08:57:50.0420] But yeah mermaid is unfortunately in js so I can't use it readily [08:58:27.0089] And widlparser is still active, is it missing changes? [08:58:59.0030] There's some pretty old issues [08:59:10.0724] It's not abandoned, I just looked https://github.com/plinss/widlparser/issues/79, not too old but not too active [08:59:44.0273] Given that Mozilla now has https://github.com/mozilla/uniffi-rs/tree/main/weedle2, maybe we could get some common library finally... [09:00:32.0322] * Given that Mozilla now has https://github.com/mozilla/uniffi-rs/tree/main/weedle2, maybe we could get some common library finally... [09:02:28.0940] (I don't think we necessarily need Mermaid support in Bikeshed btw. Given the state of accessibility in it using `` seems best at which point dedicated support is somewhat questionable.) [09:03:45.0855] Agreed. Let's revisit when more specs get Mermaid diagrams [09:03:52.0752] * Agreed. Let's revisit when more specs get Mermaid diagrams [09:06:23.0407] Having a more actively maintained Web IDL parser would be great though. The issue you pointed to is a month old, but there's others that are over half a year and actively blocking spec changes: https://github.com/plinss/widlparser/issues/70 [09:07:25.0315] (Me looking at webidl2.js issue tracker and feeling guilty) [09:07:32.0706] * (Me looking at webidl2.js issue tracker and feeling guilty) [09:11:54.0850] TabAtkins: If we ever get a wasm library for IDL, how much it would take to replace the current widlparser use, assuming that you have no objection? Is there some widlparser-specific feature dependency? [09:16:38.0625] One argument for a common library is to have a common linter. Currently autokagami bot is applying webidl2.js linter rules to every spec, but it should be more ideal if it could be caught by bikeshed level. [09:16:43.0130] I have absolutely no idea how to invite wasm from python [09:16:50.0573] But that's the only blocker, I suppose [09:18:36.0218] Wasm is old enough, there should be some established way... [09:20:41.0509] Perhaps this one? (I haven't tried it either): https://github.com/wasmerio/wasmer-python 2022-11-23 [21:54:11.0026] plinss/webidlparser being unmaintained is indeed starting to get quite painful. It'd be great to either maintain it or replace it. E.g. https://github.com/whatwg/webidl/pull/1211 has been blocked for over a month but multiple other specs are starting to build on it. [01:58:04.0873] We might have to bump actions/setup-python to 4 I think. The current one outputs a warning [01:58:46.0249] Per https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ we have until June next year [06:15:51.0913] This might be of interest to some people here: https://github.com/HTTPWorkshop/workshop2022/blob/main/report.md [06:24:31.0364] krosylight: Domenic: I don't think diagrams need to be part of the build. They're generated so rarely it seems kind wasteful. Having a script at hand to make changes easier should suffice in my opinion. [06:44:41.0053] > <@annevk:matrix.org> krosylight: Domenic: I don't think diagrams need to be part of the build. They're generated so rarely it seems kind wasteful. Having a script at hand to make changes easier should suffice in my opinion. As I responded there, I'm okay with that especially when the build script also has an ordering problem. [06:44:50.0448] Luca Casonato: does Deno care about https://github.com/whatwg/fetch/pull/1541? [06:51:46.0807] krosylight: that also makes me lean toward excluding `package.json`, but don't care too strongly. Although, if there's going to be dependency alerts then let's disable that and just review the output diff when needed? [06:52:15.0612] you mean package-lock? [06:52:39.0379] krosylight: that seems likely. :-) [06:53:09.0924] I just followed what webidl already does there, let's see what domenic thinks [06:53:30.0526] Well Web IDL is slightly different in that there it's part of the build [06:53:45.0434] But sure, waiting for Domenic makes a lot of sense [11:27:39.0972] Re: widlparser, I'm happy to start taking cracks at maintaining, since I've read into it enough at this point for some refactorings. I'll see what i can do. 2022-11-24 [07:10:34.0817] I would really love a "when was my spec last indexed" kinda feature. Or maybe "what's the latest version of my spec reflected on api.csswg.org" (which I think defaults to current Bikeshed) [07:11:08.0216] It used to be pretty reliable that 24h later it was done and for a while it was faster still, but that no longer appears to be the case 2022-11-25 [00:50:13.0540] Okay, it seems checking tabatkins/bikeshed-data works. And then if you don't see it appear there you ping plinss. [01:14:36.0039] Is a child browsing context ever not 1:1 with its navigable? [04:02:27.0579] > <@annevk:matrix.org> Is a child browsing context ever not 1:1 with its navigable? Always 1:1, indeed. [04:03:55.0615] (until everyone has out of process iframe tech and then we can start introducing cool stuff like BCG swaps for iframes?) [04:05:30.0374] I don't think that ends up having much meaning as a BCG only cares about top-level BCs. [04:06:41.0105] Perhaps this is something we can simplify then whereby we only have top-level BCs. [04:07:45.0157] Hmm. We'd still need WindowProxys for children, but maybe indeed the BC concept is not helpful... unsure. [04:08:58.0347] I guess a child browsing context might still be useful as a thing that can be targeted and end up with an opener. Even if we don't replace it. It feels very niche, but maybe I just need to get used to it. [04:09:40.0704] Ugh, children can have openers? That's gross. [04:10:05.0765] Name targeting is the original sin, but yes. [04:10:23.0537] I think navigables are the things that are targeted now, but sometimes we decide not to carry over their name when doing a navigation. [04:11:22.0129] Hmm, so COOP definitely wants fresh name and such. And name targeting in theory walks through the BCG's TLBCs. [04:11:27.0472] I was really hoping we could collapse "is auxiliary" and "has an opener" but it seems like if children can have an opener that's unlikely... [04:11:34.0059] * Hmm, so COOP definitely wants fresh name and such. And name targeting in theory walks through the BCG's TLBCs. [04:11:48.0535] Maybe moving name to navigable was a mistake then... [04:12:49.0649] Yeah, I'm also a little worried about this line: > Modern specifications should avoid using the browsing context concept in most cases, unless they are dealing with the subtleties of browsing context group switches and agent cluster allocation. Instead, the Document and navigable concepts are usually more appropriate. Because I wouldn't want anyone to be able to cast an even wider net than a browsing context. [04:13:10.0797] But if it's for traversal through the tree of documents it seems okay. [04:13:30.0209] It's very rare that a spec (besides HTML itself) wants to have different behavior after BCG swaps. [04:15:26.0282] Ah, I guess you're specifically referring to same-origin swaps. And that makes sense. But navigables can span many origins so putting state on them would be rather dangerous. [04:19:19.0017] Domenic: "is auxiliary" could maybe still be collapsed but you'd need "has opener" + "is top-level" [04:19:50.0690] Yeah, I guess. Not a big win. [04:20:47.0315] But at least the issue isn't wrong. :-) 2022-11-28 [01:42:30.0869] sideshowbarker: could you maybe ping Sam (W3C) somehow to get https://github.com/w3c/webappsec-subresource-integrity/pull/110 unstuck? [01:43:29.0719] > <@annevk:matrix.org> sideshowbarker: could you maybe ping Sam (W3C) somehow to get https://github.com/w3c/webappsec-subresource-integrity/pull/110 unstuck? Yup [06:21:31.0974] annevk: hi! Thinking about https://github.com/w3c/resource-hints/issues/74 (purpose header), how can we resolve this? Seems a bit of a bikeshed [06:24:43.0577] Noam Rosenthal: needs some commitment from Chromium and Gecko I think. You want to lowercase the value there btw as that is somewhat significant for request headers. [06:26:48.0212] Noam Rosenthal: (potentially the destination could be "prefetch", but maybe that doesn't make sense; been too long since I thought about this) [07:04:27.0208] annevk: I can tick the Chromium box, I'll see what Gecko folks say. thanks! Re. destination, yea I think it needs to be `prefetch`, will think it through a bit [07:05:16.0912] Noam Rosenthal: note that if that's the case we don't need a new request header [07:06:46.0959] annevk: because of `Sec-Fetch-Dest`? [07:07:11.0498] Yeah [08:27:39.0175] is there any index of (IDL-defined) APIs such that I could look for "HTMLDocument#xmlStandalone" and find where it is defined, if anywhere? ideally also including inheritance/mixins? [08:28:35.0801] https://dontcallmedom.github.io/webdex/ maybe? [08:30:22.0351] Sam Sneddon [:gsnedders]: it's removed: https://dom.spec.whatwg.org/#dom-document-xmlstandalone [08:30:54.0818] > <@annevk:matrix.org> Sam Sneddon [:gsnedders]: it's removed: https://dom.spec.whatwg.org/#dom-document-xmlstandalone I specifically mean "where is there a global index" and just used that as an example, rather than that case specifically [08:35:46.0772] Sam Sneddon [:gsnedders]: `grep -r someFeature interfaces/` in wpt? 2022-11-29 [16:00:27.0670] is there a `null` spec-internal value in HTML? [16:01:32.0586] i'd like a sentinel value for an internal field to mean "not present" in StructuredSerialize, and would like to avoid using JS undefined, as this value is never supposed to escape to script [16:02:01.0992] (i could also just make new [[Type]], with more branches) [16:02:07.0864] maybe that's preferable [22:35:04.0228] annevk: I checked and destination for `prefetch` is empty (like regular fetch). I think this makes some sense. Prefetch is not a destination in itself - we don't know where the request is going to be end up. It's kind of like fetching the resource in a service worker [02:30:40.0493] shu: I was wondering if that could be collapsed a bit more. It seems okay as-is, although the repetition irks me a bit. [02:31:33.0032] Noam Rosenthal: yeah, though I'm not convinced we want to expose initiator in its current state [02:32:14.0170] Noam Rosenthal: initiator just has a few values to match some known use cases, but it doesn't really have a design [02:35:01.0465] annevk: it irks me a bit too [02:35:25.0813] annevk: though it's like, extra explicit? and that seems like a plus [03:12:08.0479] > <@annevk:matrix.org> Noam Rosenthal: initiator just has a few values to match some known use cases, but it doesn't really have a design We just want to expose `prefetch` a a purpose, not the whole concept of initiator [03:12:56.0927] annevk: mainly because having it as a header is a concept that's been around for a while and has a good use case [03:18:07.0112] annevk: we can build on it later if we want to expand on the initiator concept, doesn't have to be all or nothing IMO [03:27:23.0731] Noam Rosenthal: what is the use case? [03:38:45.0990] annevk: it allows servers to opt-out of being prefetched, or to change their max-age so that a prefetched page doesn't expire, and also to not count prefetches towards "success rate" of loading a page [03:38:57.0200] I think the latter is perhaps the most common use case [03:49:07.0423] annevk: the latter is important for more than analytics... some web pages rely on "you visited this page last at..." for all sorts of things. without deferring between a prefetch and a regular document fetch, that kind of data gets messed up [04:55:11.0484] Does anyone know why I can suddenly no longer use [=origin=] or [=/origin=] to refer to the HTML origin concept in ReSpec? i.e. https://html.spec.whatwg.org/multipage/browsers.html#concept-origin [04:55:39.0710] The error message links to https://respec.org/xref/?term=origin&types=\_CONCEPT\_ where it does not seem to appear [04:57:42.0376] * The error message links to https://respec.org/xref/?term=origin&types=\_CONCEPT\_ where it does not seem to appear [05:11:46.0516]