Make a sticky preference for single-page vs. multi-page views

[gibson042]

Fixes #631

Expose buttons in the shortcuts popup for setting a localStorage "multipagePreference" entry to either empty or "single-page" or "multi-page" (and a way for similar data-multipage-preference="…" controls to be embedded in documents, necessary for mobile and other keyboard-free interactions), and check for that preference when loading any page to perform a prompt redirect if needed (e.g., before loading an entire single-page spec).

Redirects are not applied when following internal links, so using toggling between single-page and multi-page views without changing the preference still works.

[michaelficarra]

I don't like this. I prefer using the single-page document. When I open https://tc39.es/ecma262 in a new tab, I want to stay in the single-page document. But when I click a link that somebody posts to the multipage document, I am fine with it loading the multipage document. And when I want to share a link with somebody, I sometimes switch to the multipage document to copy the URL. But I don't want to go to the multipage document the next time I load the spec. For the latter problem, I could see adding a "copy multipage document link to clipboard" keyboard shortcut, but I don't know if there's a solution to the former problem.

[gibson042]

I don't like this. I prefer using the single-page document. When I open https://tc39.es/ecma262 in a new tab, I want to stay in the single-page document. But when I click a link that somebody posts to the multipage document, I am fine with it loading the multipage document. And when I want to share a link with somebody, I sometimes switch to the multipage document to copy the URL. But I don't want to go to the multipage document the next time I load the spec. For the latter problem, I could see adding a "copy multipage document link to clipboard" keyboard shortcut, but I don't know if there's a solution to the former problem.

Could you further elaborate upon "the former problem"? When following a link to the multi-page document, are you fine with loading the multi-page resource, or are you insisting upon that? And for links to the single-page document, would you likewise insist upon loading that rather than redirecting per preference to the multi-page document? Because if not, then it seems like either the first problem collapses into the second¹ or that you want the preference to asymmetrically affect only requests for the single-page document², but if you would insist upon loading the single-page document then it seems like you reject at least part of #631 and I'd like to explore that.

Footnotes

1. solved by e.g. single-page vs. multi-page permalink access and/or a more explicit way to set the preference ↩

2. which is certainly possible, but less friendly to those with a single-page preference ↩

[bakkot]

I would prefer links to the single-page document always open as single-page and links to the multi-page document always open as multi-page. Also, like @michaelficarra I regularly toggle between the two for the purposes of sharing links or find-on-page, without that indicating a preference about how future pages should be opened. I'm OK with having some sort of setting for "would you like to override opened links to force one state or the other", but I don't think it is appropriate for merely switching between the two states to be taken to indicate such a preference.

[ljharb]

I only ever want the single-page version, but I agree with #694 (comment)

[gibson042]

I would prefer links to the single-page document always open as single-page and links to the multi-page document always open as multi-page. Also, like @michaelficarra I regularly toggle between the two for the purposes of sharing links or find-on-page, without that indicating a preference about how future pages should be opened. I'm OK with having some sort of setting for "would you like to override opened links to force one state or the other", but I don't think it is appropriate for merely switching between the two states to be taken to indicate such a preference.

Thanks, that's useful feedback. How would y'all feel about the preference being set from About this Specification, such that the experience of updating it is something like "scroll/navigate to the start of the spec and then click as appropriate to set the preference and reload"? Maybe buttons that are enabled in correspondence with localStorage?

This document is available as a single page and as multiple pages. You can set a permanent preference for which view to use: No preference or Always single-page or Always multi-page.

It could also be added to the keyboard shortcuts popup for convenience, but that's too difficult to access on mobile so it couldn't live only there... and I'm inclined to leave it out.

[bakkot]

WFM. I'd also put it in the shortcuts menu personally but don't feel strongly.

[gibson042]

I have made the change to set the preference only by direct interaction with elements explicitly marked for that purpose.

[michaelficarra]

What happens when you press m while one of these options is selected? Does it navigate you away and right back? Does it do nothing? Does it change your preference?

I'm still not convinced by the utility of this feature. If it stays completely out of the way of my workflow and the workflows of consumers who don't use it, I don't have much standing to object to it, but at this point I still don't see the point of it.

[gibson042]

What happens when you press m while one of these options is selected? Does it navigate you away and right back? Does it do nothing? Does it change your preference?

As requested above, there is no change in what happens when you press m—it toggles the view without touching the preferences, allowing you to freely bounce between single-page and multi-page with no effect on future visits.

I'm still not convinced by the utility of this feature. If it stays completely out of the way of my workflow and the workflows of consumers who don't use it

It does; anyone who leaves the preference unset will have no change in experience.

I don't have much standing to object to it, but at this point I still don't see the point of it.

The point is to improve the experience for anyone who does have a preference, particularly on mobile devices which often have limited resources and are effectively precluded from using keyboard shortcuts.

[michaelficarra]

As requested above, there is no change in what happens when you press m—it toggles the view without touching the preferences, allowing you to freely bounce between single-page and multi-page with no effect on future visits.

Doesn't that kind of violate the preference?

The point is to improve the experience for anyone who does have a preference, particularly on mobile devices which often have limited resources and are effectively precluded from using keyboard shortcuts.

Since the redirect happens client-side, following a link to the single-page document will still load the single-page document before the multi-page one, actually increasing data use. Perhaps setting a cookie so the server could 302/307 to the appropriate page would be a better implementation if that's the goal.

[ljharb]

the server is github pages, there's no logic that can run there.

[michaelficarra]

I'm just talking about ideals.

[gibson042]

As requested above, there is no change in what happens when you press m—it toggles the view without touching the preferences, allowing you to freely bounce between single-page and multi-page with no effect on future visits.

Doesn't that kind of violate the preference?

No, we're treating m as an explicit signal to interact in a specific mode regardless of preference (#694 (comment) : "I regularly toggle between the two for the purposes of sharing links or find-on-page, without that indicating a preference about how future pages should be opened").

The point is to improve the experience for anyone who does have a preference, particularly on mobile devices which often have limited resources and are effectively precluded from using keyboard shortcuts.

Since the redirect happens client-side, following a link to the single-page document will still load the single-page document before the multi-page one, actually increasing data use.

It will load part of the single-page document, and then abort to load the multi-page document ASAP (because the first requested external resource is multipage.js via a <script> element with attribute async). For ECMA-262, overall data use will be lower than loading the single-page document (and likewise with respect to consumption of other resources such as memory and time).

Perhaps setting a cookie so the server could 302/307 to the appropriate page would be a better implementation if that's the goal.

ecmarkup produces content to be served from many places, and cannot rely upon server-side support (which in practice is effectively limited to static content anyway—neither ECMA nor GitHub are likely to open up cookie-based server-side redirection). And to be clear, the goal is practical improvement for ECMA-262 without being so narrow that it doesn't also apply to other documents availing theirselves of multipage support.