This means that it can inherit the current colour from the HTML around
it, and hence adapt properly to changes of colour scheme.

Here, user preferences are stored in localStorage, so that they can
persist when you come back to the same puzzle page later.

localStorage is global across a whole web server, which means we need
to take care to put our uses of it in a namespace reasonably unlikely
to collide with unrelated web pages on the same server. Ben suggested
that a good way to do this would be to store things in localStorage
under keys derived from location.pathname. In this case I've appended
a fragment id "#preferences" to that, so that space alongside it
remains for storing other things we might want in future (such as
serialised saved-game files used as quick-save slots).

When loading preferences, I've chosen to pass the whole serialised
preferences buffer from Javascript to C as a single C string argument
to a callback, rather than reusing the existing system for C to read
the save file a chunk at a time. Partly that's because preferences
data is bounded in size whereas saved games can keep growing; also
it's because the way I'm storing preferences data means it will be a
UTF-8 string, and I didn't fancy trying to figure out byte offsets in
the data on the JS side.

I think at this point I should stop keeping a list in the docs of
which frontends support preferences. Most of the in-tree ones do now,
and that means the remaining interesting frontends are ones I don't
have a full list of. At this moment I guess no out-of-tree frontends
support preferences (unless someone is _very_ quick off the mark), but
as and when that changes, I won't necessarily know, and don't want to
have to keep updating the docs when I find out.

This means that the calculated font properties of the HTML canvas now
control what font is used.  The size is overridden, and for monospaced
text so is the family.

I'd like to be able to also specify the monospaced font, maybe using a
CSS variable, but that looks like being quite a lot of extra complexity.

My experience when testing this was that constructing a valid "font"
string for a canvas context is prone to breakage, but broke in a way
that left the font unchanged, so we always set a simple specification
first before trying to construct one from CSS.

Otherwise it varies depending on whether it has any text in it, which
is distracting.

Instead of an align=center HTML attribute, we now centre its contents
using CSS.  Also, this element contains all the important contents of
the page, so it seems appropriate to us the HTML5 <main> element for
this.

It wasn't doing anything useful, and I was getting fed up with having to
expand it in the inspector.

I'd like to use this, but (a) I need it in the HTML for a little while
first, and (b) I think my current implementation may be a bit fragile.

This is more compact than carefully drawing it on a canvas in
JavaScript.  More importantly, the SVG resize handle scales nicely as
the page is zoomed, or on high-DPI screens.

At the moment, the nice SVG resize handle is removed by JavaScript,
but we need to wait a little while for everyone to get the new HTML
cached before changing that.

With word-wrapping disabled, long status-bar texts fall off the
right-hand end rather than wrapping onto an invisible second line.
This is less confusing because it makes the overflow more obvious.
I've also turned on "text-overflow: ellipsis" for extra obviousness.
Finally, this also the need to explicitly set the height of the status
bar, not that that was doing any harm.

They were set to "1px", which isn't a valid value since they're meant to
be integers.  Since they weren't valid, they were ignored.  This doesn't
seem to have caused any trouble, so they may as well be removed.  In any
case, the canvas is invisible until after its size has been set by
JavaScript.