There's not much point in re-requesting the drawing context from the
offscreen canvas at the start of each drawing operation. The canvas
keeps the context around and returns it on every call to getContext(),
so we may as well just keep our reference to it too. This does mean
that the front-end won't detect puzzles drawing outside of a redraw
operation, but I think it's the mid-end's job to assert things like
that.
Rumours that I'm doing this because I had a mysterious bug whereby ctx
was unexpectedly null are entirely true.
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.
Specifying the { alpha: false } option when creating a rendering context
tells the browser that we won't use transparency, and the standard
puzzle canvases, along with blitters, are all opaque. No obvious
effect, but the MDN suggests that this should reduce CPU usage.
The one exception here is the resize handle, which actually is
transparent.
By default, CSS uses "object-fit: fill", which means that an object is
independently scaled in both dimensions to fit its containing box.
This is simpler than what I'd assumed (which was "object-fill:
contain"). Obviously, the HTML could be changed to use a different
object-fit, in which case this code would have to detect it, but for
now following the CSS default is more correct than not.
The highlights for covered squares now have a minimum width of 1 pixel,
which means that Mines is comfortably playabale down to about 8 pixel
tilesize, below which the numbers become unreadable.
Each menu item has a -0.5px margin so that the borders of adjacent menu
items overlap, but we don't actually want the menu items to protrude
beyond the containing <ul>. Adding 0.5px of padding to the <ul>
achieves that.
This is so that (given time for caches to expire) I can switch to having
a persistent dialogue box in HTML rather than fabricating it from
scratch in JavaScript each time it's used.
Menu items that open dialogue boxes are now marked with ellipses, while
menu items that lead to submenus have pointing triangles.
The triangles are implemented as SVG files embedded in data: URLs in the
CSS, which is kind of silly but also works really well. There are
suitable characters in Unicode, but some of my test systems don't have
fonts containing them, so maybe the SVG is better.
I expect Escape to exit the menu, and SoftRight should do that as well
for KaiOS. Backspace goes up one level through the menus, again because
that's conventional on KaiOS and not too confusing elsewhere.
In the bubbling phase it managed to catch the "Enter" keypress that
opened a dialogue box from the menu and use it to close the dialogue
box again. I think it's probably reasonable to have it run earlier and
just permanently steal any keypresses it wants.
When we disable a button, it loses focus but doesn't generate a "blur"
event. This means our "focus-within" class goes wrong. Instead of
relying on "blur" events to remove the class, remove it from any
inappropriate elements in the "focus" handler. This requires attaching
the handler to the root element of the document, but I've got plans that
need that anyway.
Old browsers (like KaiOS 2.5) don't have :focus-within, but it's pretty
easy to replace the pseudo-class with a real .focus-within class
maintained by JavaScript event handlers. This is made only marginally
fiddlier by the odd fact that "focus" and "blur" events don't bubble.
Once the input focus is in the menu system (for instance by Shift+Tab
from the puzzle), you can move left and right through the menu bar and
up and down within each menu. Enter selects a menu item. The current
menu item is tracked by giving it the input focus.
I'm generally in favour of putting HTML in HTML rather the constructing
it in JavaScript, and this will allow for simplifying the code
eventually. This only changes the JavaScript to make sure that's in
people's caches before I change the HTML itself.
The previous expression for WIDTH defined it, curiously, as (1 +
(TILESIZE >= 16) + (TILESIZE >= 32) + (TILESIZE >= 64)) which is
roughly logarithmic in tile size, but bounded above by a maximum of 4
pixels. On high-DPI displays this isn't really good enough any more.
Now I've set the line thickness to a constant fraction of the tile
size (but still bounded below by 1), so it's much easier to see the
lines when the puzzle is expanded to extra large size.
When there's no drag in progress, cancelling the drag has no effect.
Returning NULL lets the front-end know this, which in particular means
the Backspace key can leave the app in KaiOS.
Older Firefox versions don't support "-moz-appearance: none" on radio
buttons, which seems to mean that the specifies padding for them
doesn't appear. Using a space character instead works fine, so do that
everywhere. This seems to move the text slightly closer to the tick on
browsers that do support "appearance: none", but the result is quite
acceptable.
This also makes the focus outline on the ticks slightly less weird.
Games with neither presets nor configuration (which may only be the Null
Game) have been slightly broken since the introduction of hierarchical
preset menus, in that the code to remove the "Type..." menu stopped
being called then. My switch to using radio buttons in menus then broke
them utterly because it's not possible to set the value of an empty
radio group, causing a crash at startup.
Fix this by detected when there's no preset menu, removing the item from
the menu bar, and setting the variable that's meant to indicate this has
been done.
The solve button problem was more subtle, in that only the <button> was
being hidden and not the <li> containing it, which led to the right border of the menu bar being two pixels thick. Switch to fully removing
the <li> from the DOM, like we now do with the presets menu, since that
also makes my keyboard handler (in another branch) simpler.
The C code in the Emscripten front-end already keeps a timer_active
variable to ensure that the timer can be activated only when it's
inactive, and deactivated only when it's active. Adjusting the
JavaScript side to rely on this makes the code much simpler. The only
oddity is that it now requests a new animation frame before calling the
callback so that it's ready to be cancelled if the callback decides to
deactivate the timer.
I think this has been broken since a752e73, when the canvas changed to
being hidden, and hence unable to receive keyboard focus, when the page
loaded. I've now moved the focus() call to after the canvas gets
displayed.
This is the wrong attribute, and the correct type="text/css" is
deprecated by MDN. Since it's never worked, the deprecated attribute
presumably isn't needed either.
They can now be specified by sticking some JSON in a <script> element in
the Web page:
<script id="environment" type="application/json">
{ "LOOPY_DEFAULT": "20x10t11dh" }
</script>
This isn't brilliantly useful, but it does allow for changing settings
without recompiling.
