Now we don't assume that stdout is line-buffered and that we'll
therefore get a single call to print(). Instead, we collect up all
the output in a string and use it when the program exits.
The usual focus ring in Firefox and Chromium appears at the same
stacking level as the element it's attached to. This means that it's
hidden by elements after it in the document, including pixels below it
and to its right. Fiddling with the z-index of the focussed pixel
helps with this.
This makes it more obvious that something is happening when the mouse
button is pressed, even though the tickybox doesnt change state until
it's released. Thus should make the UI feel less sluggish.
The new code triggers when the <input> is edited. It updates the
pixel tickyboxes and the rendered glyph, but suppresses updating the
<input> itself. This can be used for interactive editing, but is
mostly to allow for pasting in character bitmaps.
According to <https://github.com/fuweichin/xhtml5-esm-support>, an
internal script (a <script> element with content) can't be a module in
an XHTML page in Safari. So following the suggestion on that page, I
make the <script> on the page into a classic script, and use import()
to load the module containing the bedstead executable. Maybe this
will work on a reasonable selection of modern browsers.
Programs compiled with Emscripten end up statically linked against the
Emscripten runtime, which includes musl libc. So we need to comply with
their licences by including a copy of the licence and the relevant
copyright notices. I think putting them on the webstead page in small
print is probably the best approach.
This might need updating each release to match the version of Emscripten
that I build the editor with.
Apparently Chromium can't cope with "defer" scripts (which modules are
by default) in XHTML documents. But "async" scripts work properly,
so now we use one of those and then wait for DOMContentLoaded as
necessary.
