| 09:50 | <annevk> | Andreu Botella: if you do something like class CustomError extends Error { name = "CustomError" } the name won't get preserved (and neither will the subclass) |
| 09:51 | <annevk> | Perhaps that's not a concern though. If they don't end up doing anything like serialization/deserialization I won't care too much. |
| 10:51 | <Noam Rosenthal> | annevk: re fetch controller, the initial plan was to have it reported from within fetch, but then we wanted to allow callers to be in charge of when reporting happens, whether it happens at all, and to affect the response end time. The change of behavior would be mainly for scripts, because they won't be able to report timing as if it was a network error after the response has arrived, but maybe that's OK |
| 12:08 | <annevk> | Noam Rosenthal: yeah, I guess I'm wondering whether we now know enough to invert control, but I would be okay with keeping the existing setup |
| 12:08 | <annevk> | Noam Rosenthal: if we keep the existing setup, perhaps we shouldn't rename it to "conclude" though |
| 12:09 | <annevk> | Noam Rosenthal: and just refactor where we keep some of the structs |
| 12:09 | <Noam Rosenthal> | annevk: it doesn't really finalize anything, so perhaps "report timing" is enough |
| 12:09 | <Noam Rosenthal> | annevk: What does it mean "some of the structs"? |
| 12:11 | <annevk> | Noam Rosenthal: moving timing info from response to controller and creating body info |
| 12:11 | <Noam Rosenthal> | annevk: one thing that would simplify the HTML PR a lot is if we allowed inversion of control as a default but allowed to override it like in the case of CSS and scripts |
| 12:12 | <Noam Rosenthal> | like, pass on an initiator type and an auto-report boolean |
| 12:13 | <Noam Rosenthal> | So 95% of callers would not need to do extra work reporting stuff |
| 12:20 | <Noam Rosenthal> | ... anyway, I updated the PR based on this conversation. |
| 12:22 | <annevk> | Noam Rosenthal: yeah that would make sense; I'd also be curious to learn why CSS and scripts cannot use it, but probably best discussed in a new issue then |
| 13:23 | <Noam Rosenthal> | annevk: scripts report an error for non-script mime types |
| 13:25 | <annevk> | Noam Rosenthal: hmm, some of those checks happen before the script element so it wouldn't be able to distinguish those from a network error |
| 13:25 | <annevk> | Noam Rosenthal: and classic scripts don't do that, they accept most types |
| 13:27 | <annevk> | Noam Rosenthal: anyway, I gotta go for a bit (not sure if I will have time to look into this more today); could you create an issue to track this? (https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? is the algorithm that's part of fetch that ends up blocking certain responses on the network layer which the caller would be unaware of.) |
| 13:34 | <Noam Rosenthal> | Noam Rosenthal: hmm, some of those checks happen before the script element so it wouldn't be able to distinguish those from a network error |
| 15:12 | <Domenic> | Wow https://github.com/whatwg/html/issues/7952 is fun |
| 16:27 | <annevk> | Yeah, stuff like that is what makes the HTML Standard uniquely interesting to work on. Someone adds a bell or whistle to one part of the web platform and then HTML falls over (or not, as may be the case here) in dramatic fashion. |
| 23:23 | <shu> | what the |
| 23:24 | <shu> | lol |
| 23:24 | <shu> | i agree with mgaudet in that this does not seem like a code path worth anyone's time to maintain |