| 18:05 | <James M Snell> | In relation to the fetch spec ... WinterTC has been discussing use of fetch outside of browsers / user-agents for some time now. There are many such implementations. The fundamental desire is for these non-browser implementations to be As Conformant As Possible while recognizing that there are fundamental differences in many requirements. In WinterTC discussions, we have considered a few possible approaches up to creating a different version of the fetch spec that documents the subset that makes sense for these other environments but the risk of forking with the spec is too significant and maintenance becomes a fundamental burden. At the same time, we fully recognize that browsers are not impacted by these differences. To address this, I have drafted a proposal here: https://github.com/WinterTC55/fetch-workstream/issues/14 ... The tl;dr is straightforward: add an optional carve out (what I'm calling a "posture") within the fetch spec that would allow us to selectively relax normative requirements within the spec for non-browser implementations. The carve outs would require NO implementation changes on the part of browsers. The default in the spec would be the status quo. The spec differences would be minimal and targeted, with the burden of identifying carve outs falling on WinterTC as they are identified. A key goal here is to minimize any burden these callouts would have on implementers. Given this I have two questions for this group: (a) Would there be any fundamental objections y'all would have to incorporating such carve outs within the spec itself and (b) are there specific areas of feedback for the linked proposal (https://github.com/WinterTC55/fetch-workstream/issues/14) |
| 18:07 | <James M Snell> | Note that at the moment, I'm largely looking to take temperature of the room. I'm planning to bring the actual proposal forward to a future WHATNOT meeting agenda soon |
| 18:59 | <Noam Rosenthal> | Generally makes sense to me to spell this out in the spec where there's a divergence between a browser environment and an unrestricted server environment |
| 19:02 | <Noam Rosenthal> | This has some equivalence with WebDriver support inside the fetch spec, which is its own "posture" that's only available when the browsing is automated |
| 19:15 | <Noam Rosenthal> | It's a bit premature perhaps, but naming wise, my gut feeling is to keep it as explicit as possible, like "If request's client is not a web environment, then set service workers mode to none" so that people don't accidentally trip over this |
| 19:17 | <James M Snell> | Is "web environment" strictly defined somewhere? I don't want to end up with disagreements about possible ambiguity |
| 19:19 | <Noam Rosenthal> | This is more of a strawman, but we can define the environment type being a "web environment" or a "server environment" or some such instead of the "posture", as something like "sandboxed" seems like it could live inside the web and can be confused with other sandboxed things |
| 19:20 | <Noam Rosenthal> | but let's not jump ahead, we can decide on this if there is a consensus to do this in the first place, and I suspect that the people that are likely to have opinions on this are OOO for the next few weeks. |
| 19:23 | <James M Snell> | That's fine... I'd caution against assuming it's always "server environment" however... a non-browser fetch client implementation could use the unrestricted profile also if it has no need for the full set of features |
| 19:23 | <James M Snell> | it's motivated by existing server impls but not limited to such |
| 19:24 | <James M Snell> | example: node.js' undici library is a client impl that is very close to the unrestricted posture |
| 19:25 | <Noam Rosenthal> | sure. we'll find the right name for it, my point is to make it pop out as "oh this is the non-browser-thingy" when people read the spec and are unfamiliar |
| 22:58 | <nektro> | is wpt/html/semantics/forms/the-input-element/email*.html the extent of the email address related tests in wpt? |