tc39
consider publishing multipage biblios
The published biblio is useful, but in many cases it would be better for proposals to link to the multipage version of the spec.
The current biblio format is not well-suited for that, but it would be trivial to make it also allow arrays of such objects.
I'm not clear on any case where it'd be better - the multipage version is strictly worse in every situation except for Chrome, due to a layout rendering issue in that browser.
If I'm in a proposal, and I want to see the definition of a term, I would prefer to load and render a ~700KB page rather a ~7MB page. That's a lot of extra bytes! With Firefox on my phone the multipage version loads ~instantly and the full document in ~10 seconds. Similar or worse experience with Safari on my laptop.
We clearly have different preferred experiences - I'm not interested in optimizing a single term (google can do that), I'm interested in loading the entire spec so that i can jump around to read all the terms I click through instantly (since they're preloaded).
What's the use case where you're browsing the published biblio and the lack of pagination is prohibitive?
I'm not browsing the published biblio. (... why would you be browsing the biblio?) I'm browsing a proposal, and clicking on links in that proposal. Some of those links are within the proposal and load quickly. Others, usually unbeknownst to me until I click on them, are going to go to ecma262. I want those links to load quickly instead of loading slowly, so I can read the definition or algorithm they're linking to and then get back to reading the proposal. When ecma262 takes 10 seconds to load, that's very annoying.
When I'm reading ecma262, I also prefer the full document, because I'm going to stay within the document. But if I'm coming from a proposal, I'm just looking at a single term in ecma262 and then going back to the proposal.
ahhh i see what you mean, you're saying that the proposal spec makes a runtime JSON request for the biblio JSON file, which might be large?
That makes a ton of sense. Perhaps instead of ecmarkup loading the entire biblio file, it could inline only the used parts?
No, I mean, I want links which go from proposal specifications to 262 to go to the multipage version of 262 instead of the single page version. Because I'm clicking on links in the proposal, and I want those links to load quickly.
The way to accomplish that is by allow proposals to use a biblio corresponding to the multipage version of the spec.
Here, I've prepared two recordings. The first is the experience I currently have, where proposals link to the full spec. The second is the experience I would like to have (achieved by editing the link in devtools), where proposals link to the multipage version of the spec. These are actual recordings. The cache is even warm for the first one, to make it as fair as possible.
(Edit: actually I didn't realize the first one wasn't interactive yet when I ended the recording the first time. It takes 20 seconds to load to interactive! Updated the recording.)
https://github.com/user-attachments/assets/d3f3d35f-4761-42ad-b619-0b27b95f8600
https://github.com/user-attachments/assets/0c0f4a18-2d58-41df-8970-bbb5c794afe9
No, like I said the above recordings are with a warm cache. The problem is that the full document just takes an extremely long time to lay out and render on many devices.
We could improve the time to render - for example, not using a custom font would cut ~1/3 off the rendering time - but I doubt we can fix it entirely.