pager improvements

[mbostock]

This…

• Adds the top-level /index as the implicit first page (if there’s a title set)
• Fixes escaping when interpolating user content into HTML (no automatic protection here!)
• Switches to the blue (focus color) border on hover for pager buttons
• Produces “pretty” URLs by truncating /index as appropriate
• Avoids possible collision with userland CSS by using observablehq- prefixed ids
• Improves the type safety of the pager function
• Adds unit tests for the pager function

Example:

[Fil]

Related (though not a comment on this PR _per se_), as I was just working on the sidebar, I wanted to change the behavior wrt the **title** config option. For me, it's surprising that this option would make the top link to / appear (or disappear).

I'd like to suggest instead that the title option just changes the text of that link, which would be always present (unless of course there is only 1 page).

Otherwise, we must fix the bug that makes the whole navigation menu bold if there is no title. (This bug is already present in main; my suggestion fixes by way of consequence.)

When the first link goes to the home page (which in my suggestion would be always), we should skip pages[0] if it is /index, to avoid a repetition.

This in turn would allow the prev/next links to include the /index iff the user adds that page as the first element of config.pages (it would be the default if you don't specify config.pages).

this comment is now #195

[Fil]

My second comment is on the use of #observable-prev and #observable-next. I don't really like the markup it generates, and I'm not sure how this clashes with userland css, since everything was scoped to #observablehq-footer?

If we wanted to not use the classes .prev and .next, we could maybe use a (more semantic) a[rel=prev] markup?

[Fil]

I'll act on my first comment #192 (comment) in a separate PR.

Second comment about the markup is a non-blocking question.

[mbostock]

My second comment is on the use of #observable-prev and #observable-next. I don't really like the markup it generates, and I'm not sure how this clashes with userland css, since everything was scoped to #observablehq-footer?

What do you not like about the markup? I do like the rel=prev/next semantic approach though!

As for clashing, it clashes if users define their own .prev or .next classes. For example if a user says .prev { color: red; } then the footer previous button is red. We shouldn’t expect the user to know which classes our UI uses. Instead we always use the observablehq- prefix to defend against user styles. (User styles on global elements can still affect us, but that’s unavoidable without shadow DOM.)

I agree with the title and /index in pages comments. Thanks for volunteering to improve that.