| 00:29 | <devsnek> | has there ever been any discussion about the reviver function and response.json() |
| 00:30 | <devsnek> | I'm guessing response.text() + JSON.parse is just good enough |
| 00:55 | <Domenic> | devsnek: https://github.com/whatwg/fetch/issues/104 |
| 01:37 | <devsnek> | Domenic: thanks for the link |
| 01:38 | <devsnek> | it looks like it's assumed there that streaming json on main thread < buffer text and parse? |
| 02:04 | <Domenic> | I'm not sure how to parse that sentence |
| 02:53 | <devsnek> | Domenic: it seems like it was assumed in that thread that streaming parsing on the main thread isn't worth it compared to building up a string with .text() and calling parse |
| 02:53 | <devsnek> | which is surprising to me but of course I'm not an expert on performance |
| 03:08 | <MikeSmith> | reading https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/bKn2DLuRdeU |
| 03:08 | <MikeSmith> | about <iframe loading="lazy"> |
| 03:09 | <MikeSmith> | > the <img> portions of the spec have landed, whereas we dropped a ball on the <iframe> variant landing in the HTML spec … |
| 03:09 | <MikeSmith> | > some have suggested |
| 03:09 | <MikeSmith> | un-shipping the feature. |
| 03:09 | <MikeSmith> | Why? |
| 03:10 | <MikeSmith> | Where? Who? |
| 03:11 | <MikeSmith> | I realize the message also says it’s not gonna be un-shipped, but I don’t understand why anybody would have suggested it to begin with |
| 04:03 | Domenic | MikeSmith: first message of https://groups.google.com/a/chromium.org/forum/#!topic/blink-api-owners-discuss/JjETiVoN6l8 has yoav suggesting removing the feature as one course of action |
| 04:03 | <MikeSmith> | aha |
| 04:04 | <Domenic> | (did not mean to /me that, I guess there's some IRCCloud keyboard shortcut that automatically inserts a /me prefix...) |
| 04:04 | <Domenic> | devsnek: "streaming parsing on the main thread" isn't well-defined. |
| 04:05 | <Domenic> | https://groups.google.com/a/chromium.org/d/msg/blink-api-owners-discuss/JjETiVoN6l8/3JeXh6rjAAAJ has Addy Osmani also suggesting moving it back behind a flag |
| 04:06 | <devsnek> | my thinking was that with the json source proposal it might be worth taking another look |
| 04:06 | <devsnek> | I imagine parsing out bigints will be somewhat common |
| 04:07 | <MikeSmith> | Domenic: thanks! |
| 04:07 | <Domenic> | devsnek: I think step 1 would be someone proposing an actual processing model for streaming JSON that has well-defined semantics. So far nobody has. The closest is NLDJSON. |
| 04:08 | <Domenic> | s/NLDJSON/NDJSON |
| 04:09 | <devsnek> | I was thinking step 0 would be "does anyone actually want this" |
| 04:09 | <Domenic> | Right, well, it's not clear what "this" is |
| 04:10 | <devsnek> | well parsing a bunch of json that might be broken into pieces is not difficult |
| 04:10 | <Domenic> | In a way different than just buffering into text and parsing all at once? |
| 04:10 | <devsnek> | well since all the modern json parsers in engines are loop based instead of recursion based |
| 04:10 | <MikeSmith> | Domenic: I had actually just mis-took the message I cited as being about un-shipping img[loading].. |
| 04:11 | <devsnek> | it should be as simple as just calling into a function every time you get more data |
| 04:11 | <Domenic> | devsnek: you can't produce any incremental results because if you have `{ ... 500 KiB of valid object literal JSON ... ]` then the whole thing must be a parse error. |
| 04:11 | <devsnek> | ah I see what you mean |
| 04:12 | <devsnek> | yeah that is unfortunate I guess |
| 04:12 | <devsnek> | scrap everything I said |
| 04:12 | <Domenic> | You need a new format that can have "checkpoints" for validity. NDJSON is one stab at that, but I'm unsure on the adoption. |
| 04:14 | <devsnek> | ndjson would serve the use cases I know of but I wouldn't suggest it being part of browsers |
| 04:41 | <annevk> | https://siguza.github.io/psychicpaper/ (test your parsers or ideally just have one of them) |
| 04:44 | <annevk> | Oh lol, they mitigated with more parsers |
| 04:47 | <annevk> | But also, what I thought was usage of XML is in fact several terrible dialects of XML |
| 05:22 | <MikeSmith> | annevk: wow |
| 05:22 | <MikeSmith> | > We can also ask ourselves how a bug like that could ever exist. Why the hell there are 4 different plist parsers on iOS. Why we are still using XML even. But I figure those are more philosophical than technical in nature. |
| 05:22 | <MikeSmith> | haha |
| 05:31 | <annevk> | Another instance of technical debt not being prioritized |
| 08:00 | <nixi> | hi |
| 08:01 | <nixi> | i have been looking for a formal specifications on which codecs to use in html video and i am not sure there is any |
| 08:02 | <nixi> | i have ben searching here mainly: https://html.spec.whatwg.org/multipage/media.html#the-video-element |
| 10:51 | <annevk> | nixi: there are no mandated formats atm |
| 10:55 | <nixi> | annevk: ah ok, so it is a free-for-all in terms of browser implementation of formats |
| 10:55 | <annevk> | unfortunately, yes, though I think through WebRTC there might be some mandated formats, but those might be scoped to WebRTC specifically, not sure |
| 10:56 | <annevk> | Hopefully AV1 is the way out of this mess |
| 11:07 | <nixi> | no daala? |
| 13:15 | <annevk> | If anyone is interested in somewhat more formalized storage architecture: https://github.com/whatwg/storage/pull/86 |
| 14:15 | <annevk> | Another thing, I noticed that our snapshots now use the snapshot logos and it's rather nice: https://whatpr.org/storage/86.html |
| 15:12 | <Domenic> | There's a bug with the warning that I can't repro locally... it should say "this is a PR preview" not "not ready for implementation". But it only shows up on whatpr.org, not when I run the same commands locally. |
| 15:21 | <annevk> | Domenic: I suspect the PR preview software might need changes; tobie added that warning before we had something iirc |
| 15:21 | <Domenic> | Hmm |
| 15:23 | <Domenic> | Ah, yeah... https://github.com/tobie/pr-preview/blob/a38138ef02f65d8829a2c01c5a7195fa7b4ea941/lib/models/config.js#L44-L47 |
| 15:23 | <Domenic> | It overrides the default md-warning set by our boilerplate |
| 15:23 | <Domenic> | That's awkward |
| 15:23 | <Domenic> | Maybe we can hard-code a WHATWG exception |
| 15:27 | <Domenic> | Filed https://github.com/tobie/pr-preview/issues/55 |
| 15:29 | <annevk> | We could branch on params["md-status"] I guess |
| 15:30 | <Domenic> | Yeah that's what I ended up suggesting |
| 15:36 | <annevk> | https://github.com/tobie/pr-preview/pull/56 |