| 00:50 | <sideshowbarker> | Dominic Farolino: Isn't https://github.com/whatwg/fetch/issues/1706 likely to break some percentage of sites that are currently relying on browsers not doing a preflight? |
| 00:56 | <sideshowbarker> | Is a null "origin or null" same origin with another null "origin or null"? |
| 01:00 | <ljharb> | sounds more like a NaN origin (half-serious) |
| 04:26 | <Domenic> | Sketch for the new feature/issue templates: https://github.com/annevk/temp-whatwg-new-issue/issues/new/choose cc Domenic keithamus muan zcorpan sideshowbarker |
| 04:36 | <sideshowbarker> | Domenic: For some reason, the order is different on mobile: |
| 04:37 | <Domenic> | Oh dear... |
| 04:37 | <sideshowbarker> | Maybe having Chat and StackOverflow first that way is actually better, I dunno |
| 04:37 | <Domenic> | Is that a result of my renames? |
| 04:37 | <Domenic> | Or is it an existing bug? |
| 04:37 | <sideshowbarker> | I don’t think it was the result of your renames — but I also don’t remember what the order was previously |
| 04:39 | <sideshowbarker> | anyway, I think we should keep the Stack Overflow link — because it’s helpful but also because we’d still be using up only ~2/3rds of the vertical space on a mobile screen, so users wouldn’t need to scroll to see anything. And it’d leave us plenty of room to add more links later, if/when we think of other stuff |
| 04:41 | <sideshowbarker> | nit: I think Stack Overflow is two words rather than one camelcased |
| 04:45 | <Domenic> | Fixed, thanks |
| 04:51 | <sideshowbarker> | and for the Stack Overflow text maybe something more like:
|
| 05:10 | <sideshowbarker> | Domenic: for the New issue template, maybe we should also have:
|
| 05:12 | <sideshowbarker> | …with part of the purpose being to preempt people filing issues that aren’t directly related to the content of the spec itself, but instead should be asked in Stack Overflow or somewhere. |
| 05:13 | <sideshowbarker> | …because if someone is unable to provide a URL for a spec section, and unable to identify a particular section of the spec that has a problem, and to describe what the specific problem is in the spec, then it’s likely not a spec issue |
| 05:17 | <sideshowbarker> | and a bonus would be that the spec URL could be used to automatically label the issue based on what spec section it’s about — for example, in the case of the HTML spec, the appropriate topic: label from https://github.com/whatwg/html/labels?q=topic%3A |
| 05:18 | <Domenic> | Oh, I like that idea. annevk , thoughts? |
| 05:23 | <annevk> | I worry a bit about making filing an issue overly laborious. Rephrasing the question seems reasonable, but I'm not sure about requiring a URL. Although having an optional URL field might be okay and could be used when we refactor zcorpan's script. (Of course, at that point my feature request to GitHub becomes moot too.) |
| 05:27 | <annevk> | Domenic: I guess you should do the newline thing on the New issue template too |
| 05:28 | <annevk> | (Opaque origin can sometimes be reused and it is same origin with itself so it's not quite like NaN I think.) |
| 05:30 | <Domenic> | Domenic: I guess you should do the newline thing on the New issue template too |
| 06:27 | <annevk> | Domenic: it has the same newline separating the Chat line |
| 06:30 | <Domenic> | Ah I see, it just linebreaked at exactly the right place. |
| 06:31 | <Domenic> | Done |
| 07:18 | <zcorpan> | Is it a problem that people are filing issues that aren't spec issues? |
| 07:22 | <annevk> | zcorpan: kinda |
| 07:23 | <annevk> | zcorpan: I think especially for HTML there's quite a bit of noise and at the same time not enough information for people who want to help fix things |
| 07:30 | <zcorpan> | annevk: ok yeah then maybe the template can ask for more details |
| 08:29 | <annevk> | Domenic: https://github.com/whatwg/url/pull/794 \o/ |
| 08:29 | <Domenic> | Nice! |
| 08:32 | <annevk> | I guess I'll create the remainder of PRs automatically and then if any need additional work I'll find out through self-review |
| 08:32 | <Noam Rosenthal> | Domenic: what happens to NavigationHistoryEntry on location.replace()? I am afraid that if we use history entries directly for the activation info we might lose some info |
| 08:33 | <annevk> | I'll land this URL one first and give it until after lunch at least before doing the remainder, just in case |
| 08:33 | <Domenic> | They get replaced with a new NavigationHistoryEntry |
| 08:34 | <Domenic> | This API would actually be the first time you could see a replaced entry |
| 08:34 | <Domenic> | Which we have for some time noted as a vaguely good idea to solve |
| 08:34 | <Domenic> | https://github.com/WICG/navigation-api/issues/41 |
| 08:38 | <annevk> | Okay, so currently "file issue about the selected text" bypasses the template. But it still works. We can look into fixing that, but given how seldom it's used I'm not motivated enough to do it myself. |
| 09:27 | <annevk> | Folks here might enjoy hober's https://tess.oconnor.cx/2023/09/polyglots-and-interoperability (if you make the time, maybe also budget some time for the cross-references, I especially enjoyed Ian Hickson's email referenced in the footnote about namespace prefixes) |
| 09:35 | <Ms2ger> | "something too terrible to actually use can be fixed by adding a level of indirection", I like that |
| 09:40 | <Noam Rosenthal> | Domenic: re https://github.com/whatwg/html/issues/9760, coming to think that the whole thing about activation info is a almost an entirely different use case from "initial load". I wonder if "initial load" has use-cases other than manipulating the spinner? |
| 09:43 | <annevk> | Hah, the most popular "whatwg" repo is node-fetch: https://github.com/topics/whatwg. That is kinda funny. |
| 09:44 | <annevk> | And Observable is more popular than Web IDL. Good times. |
| 10:50 | <sideshowbarker> | I guess we need to buy some more github stars |
| 15:18 | <Jeremy Roman> | time to make deprecate WebIDL and describe all APIs in terms of Observable |
| 15:18 | <Jeremy Roman> | If you want to know what the width of your canvas is, just subscribe to it once :) |
| 15:24 | <annevk> | dbaron: I think you should now have sufficient access for labels and reviewers and such; if it's still not working I can give you write access on some repositories if you want (still won't give you direct access to main, but would allow you to meddle with other people's PRs; up to you whether you want such power) |
| 15:27 | <annevk> | If everyone observed it, but nobody subscribed, did it really happen? |
| 15:54 | <annevk> | miketaylr: you get the honor of deploying the last set of issue templates (and fixing a Build error): https://github.com/whatwg/compat/pull/247 🎉 |
| 16:01 | <freddy> | annevk: I'm looking at potential interop isues where I know that Chrome is using an internal redirect but Firefox is replacing the request's URL scheme (s/HTTP/HTTPS), but I'm still not fully sure what an internal redirect is and how that is web-exposed. As the person who field https://github.com/whatwg/fetch/issues/1426, - Can you help me come up with a test case or a specific scenario where that would be web-observable? |
| 16:02 | <freddy> | I a test that redirects 14 times + internal redirect would get you to 15 redirects (is that still the max?) and return a NetworkError, where a scheme-replacement wouldnt. But surely that isn't in the categories of interesting scenarios? :) |
| 16:03 | <annevk> | freddy: that's actually a scenario we have an issue on |
| 16:03 | <annevk> | freddy: limit is 20 per https://fetch.spec.whatwg.org/#concept-http-redirect-fetch |
| 16:05 | <annevk> | freddy: actually replacing it would also update a Request object I think, which doesn't make any sense |
| 16:06 | <annevk> | freddy: an internal redirect is essentially where you go to the network layer and the network layer gives you a new location and then you do policy checks against that (hopefully correctly, but often we've had bugs) and tell the network layer to go fetch it |
| 16:07 | <annevk> | freddy: https://github.com/whatwg/fetch/issues/576 |
| 16:09 | <freddy> | Ah, so the "fetch" abstraction should treats it as a redirect that needs to be subject to additional security checks? |
| 16:09 | <freddy> | I suppose in a "switch the target to HTTPS" you wouldn't want to check the CSP (and cause violations for a request that was browser-modified and not issued by the page)? |
| 16:10 | <freddy> | I'll need to think about that some more. Unfortunately, I have to end my work for today. |
| 16:11 | <annevk> | freddy: or bypass certain checks such as CSP and CORS |
| 16:12 | <annevk> | freddy: I guess the main reason why it's done is because you can't always make these decisions synchronously and the network layer has access to the relevant information; Fetch doesn't really have the same limitation/interface, but we do kinda want the initial request URL not to be mutated, but we could solve that in other ways too |
| 16:13 | <annevk> | (Clearly, I should also take a break.) |