| 06:48 | <annevk> | iwan.aucamp: there have been a few attempts, see the issues; none has really made it to the point where it would seem like a clear improvement, at least to me |
| 09:22 | <iwan.aucamp> | A clear improvement as compared to not having one, or as compared to the IETF grammar? |
| 09:24 | <iwan.aucamp> | It seems to me that if the intent is indeed to obsolete RFC 3986 then a providing a grammar would be an essential part of it. |
| 09:24 | <iwan.aucamp> | I see for example mention in the one issue that it would be simple, but if it would be, why not just make it? |
| 09:28 | <annevk> | Not all assertions on the internet happen to be true. 🙂 Likewise, you might find that not everyone is as convinced about the merit of grammars. |
| 09:29 | <iwan.aucamp> | Okay, but say I want to incorporate it into another format, like Turtle? |
| 09:29 | <iwan.aucamp> | or into another grammar? |
| 10:26 | <annevk> | iwan.aucamp: in most cases you wouldn't want that grammar to fall over the moment this grammar is extended in some way, so usually you'd have a somewhat broader field and then define processing requirements around it |
| 10:28 | <annevk> | (This is one of the criticisms against grammar, it alone is not sufficient to define what you actually expect to happen) |
| 10:41 | <annevk> | foolip: so does idlharness.js not use webidl2.js underneath? |
| 10:42 | <annevk> | foolip: cause it seems krosylight patched that in https://github.com/w3c/webidl2.js/commit/4a4be1f3436360f033a8a7efd896904ef1a52aab |
| 10:43 | <annevk> | foolip: I suppose we want to list webidl2.js as a place to file issues on when Web IDL gets changed (that would involve two minor changes to whatwg/spec-factory and whatwg/meta), but maybe other tools as well? E.g., bikeshed? |
| 10:43 | <annevk> | Although I guess bikeshed was fine this time around as Fetch is still building... |
| 10:44 | <annevk> | (Maybe because they're separate IDL fragments.) |
| 10:50 | <krosylight> | foolip: so does idlharness.js not use webidl2.js underneath? |
| 11:09 | <annevk> | I filed https://github.com/whatwg/webidl/issues/1147 to track this conversation |
| 13:11 | <Doug Conmy> | annevk: Following up on PR, can you advise on next steps? I believe everything needed is in there. https://github.com/whatwg/html/pull/7678 |
| 14:57 | <annevk> | Doug Conmy: thanks for the reminder, I'm checking internally with Mozilla to see if anyone has any problems with closing https://github.com/mozilla/standards-positions/issues/624 as worth prototyping; I suspect we'll know by Wednesday or so |
| 14:58 | <annevk> | Domenic: I take it jarhar speaks for Google as a whole on this issue? |
| 14:59 | <Domenic> | annevk: I think to the extent we require in the WHATWG, yes. (The Blink API owners are always the final deciders but we generally assume alignment unless something's particularly controversial.) |
| 16:01 | <annevk> | shu: https://github.com/tc39/proposal-shadowrealm/issues/353 seems to discuss cloning errors; shouldn't that follow HTML StructuredSerialize semantics? |
| 16:08 | <annevk> | I guess I'll just raise my concern there directly, easier to keep track of it |
| 16:25 | <shu> | annevk: no, it's not cloning errors per se |
| 16:26 | <shu> | like, maybe that's one thing that you do to propagate errors across the boundary? i don't know what the intention is |
| 16:26 | <foolip> | It does, it's just that it's completely manual to update the dependency. Perhaps it would be good to get a CI job for that |
| 16:28 | <annevk> | shu: https://github.com/tc39/proposal-shadowrealm/issues/353#issuecomment-1071058577 is what made me think that, FWIW |
| 16:29 | <shu> | i read that as just brainstorming |
| 16:30 | <shu> | (and also my reading that the idea was rejected more or less by others in the discussion) |
| 16:30 | <shu> | another relevant thing here is that the idea of distinguishing platform-thrown errors from user-thrown errors has been floated |
| 16:30 | <shu> | i both think that is probably not possible and a bad idea |
| 16:33 | <krosylight> | It would be easy enough to that for webidl2.js I think. I would be nice if it doesn't have to be done differently for each dependency though, so https://github.com/web-platform-tests/rfcs/issues/46 comes to mind. |
| 16:34 | <annevk> | shu: to some extent that's what StructuredSerialize does, but perhaps TC39 plans to adjust it somehow if/when they take it over |
| 16:34 | <foolip> | A webidl2.js update should not break wpt in a way that each test should be adjusted (idlharness is the only thing it should affect). Not sure that applies to all dependencies |
| 16:35 | <annevk> | shu: anyway, if the current proposal is to map everything to a TypeError I guess my comment doesn't apply |
| 16:36 | <shu> | annevk: how does StructuredSerialize distinguish platform-thrown from user-thrown errors? |
| 16:36 | <annevk> | Noam Rosenthal: I hadn't looked at the PR text of https://github.com/whatwg/fetch/pull/1413 again; so from your comment I take it I should wait a bit until there's a fix for the issue Yutaka found, right? |
| 16:37 | <Noam Rosenthal> | Noam Rosenthal: I hadn't looked at the PR text of https://github.com/whatwg/fetch/pull/1413 again; so from your comment I take it I should wait a bit until there's a fix for the issue Yutaka found, right? |
| 16:40 | <krosylight> | It still has to happen through a PR, so I'm not sure that makes any difference in practice. Also, all changes can sometimes break something. |
| 16:40 | <annevk> | Noam Rosenthal: nice |
| 16:41 | <Noam Rosenthal> | annevk: I had a related question about request. It seems like we save some state on it - both the done flag as well as things like TAO fail. Shouldn't they be moved to fetch-params/controller? |
| 16:42 | <annevk> | shu: hmm maybe it doesn't, it just looks at [[ErrorData]] but also checks it's not a platform object... I wonder if that ends up doing the right thing for a DOMException with a stack. I guess not? |
| 16:43 | <Andreu Botella> | DOMException's serialization steps explicitly include serializing the stack IIRC |
| 16:43 | <annevk> | Noam Rosenthal: yeah, I think that would be an improvement (although there's a bit public/private member tension there in that some state should be available to fetch callers and some shouldn't) |
| 16:44 | <Noam Rosenthal> | annevk: fetch callers anyway pass along the request so they have access to its done & TAO fail |
| 16:45 | <annevk> | Noam Rosenthal: yeah that's equally dumb, fair |
| 16:46 | <annevk> | Noam Rosenthal: arguably URL list should be on controller too, slowly turning request back into an immutable thingie |
| 16:47 | <Noam Rosenthal> | annevk: are Request object reusable? Seems like they are and they don't re-initialize their associated internal request, which means that currently in the spec there is a "bug" where e.g. if a request would fail TAO then subsequent fetches with the same request object would also fail TAO |
| 16:47 | <Noam Rosenthal> | (probably similar bugs with URL-list) |
| 16:49 | <annevk> | Andreu Botella: shu: though that combination probably means that user-thrown errors end up being treated differently? In that they won't have [[ErrorData]] or custom serialization steps |
| 16:49 | <annevk> | Noam Rosenthal: each time you invoke fetch() it runs the Request constructor |
| 16:51 | <Noam Rosenthal> | Noam Rosenthal: each time you invoke Request(prevRequest: Request) which internally doesn't clone, but reuses the internal object (https://fetch.spec.whatwg.org/#dom-request 6.2) |
| 16:51 | <Andreu Botella> | If a user throws a new Error(), it will have [[ErrorData]] – not sure if that's the distinction you meant |
| 16:52 | <annevk> | Noam Rosenthal: but then step 12 happens |
| 16:53 | <Noam Rosenthal> | annevk: ah. in that case I guess request could have also held the timing info as it's one request per fetch, and perhaps we didn't really need the controller? |
| 16:54 | <shu> | Andreu Botella: that's the distinction i'm imagining |
| 16:55 | <shu> | i can see the SES folks who raised the concern caring about that kind of distinguishing |
| 16:55 | <shu> | i just don't think it's possible |
| 16:55 | <annevk> | Noam Rosenthal: we need a controller for cancelation |
| 16:55 | <annevk> | Noam Rosenthal: and once we have a controller for that purpose, we can also it for general state changes for which "request" isn't really suitable |
| 16:56 | <Noam Rosenthal> | I guess external caller can still fetch the same request twice |
| 16:56 | <Noam Rosenthal> | which would have the TAO bug if any caller actually did that |
| 16:57 | <annevk> | Yeah, it's just poor design, but fortunately it hasn't leaked to any public API |
| 17:00 | <Noam Rosenthal> | annevk: ok, so to summarize: there's no current bug because callers behave even though it's not asserted, and moving this to the controller will allow us to prevent future cases of this potential design issue. |
| 17:12 | <Noam Rosenthal> | annevk: uploaded a new revision, without the new states and ensures callers don't meddle with state except by terminating/aborting, as there is no need for "concluded" state. conclude now only reports timing. |