| 01:14 | <AvMaster> | configuration zoho |
| 07:09 | <annevk> | PR Preview should be fixed now. If you ever notice PR Preview not working please attempt to escalate immediately by opening an issue against the PR Preview repository. Thanks! |
| 07:09 | <annevk> | (Credit for fixing goes to Tobie, Denis (W3C), and Tab!) |
| 08:31 | <jgraham> | Well in Firefox it's probably actually implemented by running js in the parent process (or maybe privileged js in the content process, but basically same deal) :p In other browsers I assume there are native-code APIs to manipulate streams &c. But the spec doesn't consider that possibility. |
| 11:26 | <Shannon Booth> | ladybird actually happens to have such a concept which is used for non observable css stuff like in shadow trees. but for pretty much everything else like internal fetch we just use whatever realm is available. it meant we had a bug at some stage where if scripting was disabled (like in a sandboxed iframe) fetch wouldn't work. https://github.com/whatwg/html/commit/905b7218 fixed that for us though |
| 16:38 | <Dominic Farolino> | When fetching in parallel, what's the best way to convert a response into JSON? It seems you can't use https://infra.spec.whatwg.org/#parse-json-bytes-to-an-infra-value since it technically expects a realm, but maybe it's "OK" if you handle the errors good enough? Perhaps https://tc39.es/ecma262/#sec-ParseJSON would be better, but it seems unused outside of ES |
| 17:32 | <Noam Rosenthal> | seems like multiple specs are using "parse JSON bytes to an infra value" |
| 17:44 | <TabAtkins> | Is the realm expectation some transitive dependency buried deep in the call chain? I'm not easily finding it. |
| 20:12 | <bkardell> | It’s a shame that https://html.spec.whatwg.org/multipage/html-design-principles is 404 instead of a redirect or explanation - there are external links to it |