Multipage should be more accessible

[gibson042]

Having multipage support is great, but it should be more accessible... for example, loading the single-page https://tc39.es/ecma262/ from a linked term in https://tc39.es/ecma402/ or loading a build preview such as https://ci.tc39.es/preview/tc39/ecma262/pull/3513 from a GitHub Actions CI link on a Chrome DevTools "Slow 4G" connection:

• consumes at least 8.7 MB of RAM
• takes 9 seconds to get there
• ~~never indicates~~ does not highlight the presence of a multipage alternative
• does not respond to the "m" shortcut for switching to multipage until after all page HTML has been parsed
• responds to the "m" shortcut by navigating first to https://tc39.es/ecma262/multipage/#sec-… and then, after that page has been parsed, re-navigating to https://tc39.es/ecma262/multipage/$page.html#sec-…

The "~~never indicates~~ does not highlight multipage" issue could be solved with a floating link, possibly cleared/moved/otherwise de-emphasized on completion of page load (cf. https://html.spec.whatwg.org/ ).

The "after HTML has been parsed" issues stem from use of <script defer>, which I think would be better behaved as <script async> or possibly even loading doShortcut as a blocking script before the body (and probably updating it to tolerate an undefined idToSection).

The re-navigation issue is the smallest of these, but could be solved by loading multipage.js (specifically for idToSection and the re-navigation logic) even on the single-page view for use by doShortcut.

And as suggested below, a cookie to force either single-page or multi-page with a check and redirection in a blocking script at the beginning of the page would preempt the need for any future interaction at all.

[gibson042]

Related #195

[bakkot]

never indicates the presence of a multipage alternative

It's linked in the very first text in the body of the page:

I know people tend to gloss over the frontmatter, but it is at least there. Not as helpful when you're jumping to a specific term, of course.

The "after HTML has been parsed" issues stem from use of <script defer>, which I think would be better behaved as <script async> or possibly even loading doShortcut as a blocking script before the body (and probably updating it to tolerate an undefined idToSection).

I believe HTML rendering blocks the main thread, so I don't know that messing with the placement of the script would have any effect (because it can't run the shortcut event handler until after the main thread is unblocked), but I could be wrong; if you want to experiment and find that it does work I'd happily take a PR.

Alternatively, we could have some way of indicating that the user would prefer to always be redirected to the multipage version, and do that check+redirect in a blocking script at the beginning of the page.

[ljharb]

Having an input that sets a cookie and indicates the user's preference (for both always multipage, or never multipage) would be great. (Since I don't use Chrome, I don't have any slowness with the single-page version, so I always prefer single-page for the find-in-page capability)

[gibson042]

I know people tend to gloss over the frontmatter, but it is at least there.

Thanks; acknowledged and updated.

Not as helpful when you're jumping to a specific term, of course.

Indeed.

I believe HTML rendering blocks the main thread, so I don't know that messing with the placement of the script would have any effect (because it can't run the shortcut event handler until after the main thread is unblocked), but I could be wrong; if you want to experiment and find that it does work I'd happily take a PR.

Confirmed on both Chrome and Firefox that <script src="assets/ecmarkup.js?cache=…" async> makes the shortcut available before rendering is complete (although ecmarkup.js being 1.3 MB itself still delays things more than is ideal).

Alternatively, we could have some way of indicating that the user would prefer to always be redirected to the multipage version [Having an input that sets a cookie and indicates the user's preference (for both always multipage, or never multipage) would be great], and do that check+redirect in a blocking script at the beginning of the page.

I am in favor of this as well, and have added it to the description.

Since I don't use Chrome, I don't have any slowness with the single-page version

@ljharb See «on a Chrome DevTools "Slow 4G" connection» in the issue description; this is about efficiency of transferring content rather than in dealing with it after the fact.

[ljharb]

ah, fair enough. i'd still rather wait for the single-page load rather than lose out on find-in-page, personally :-) but that's what configuration is for.