* `hidden` attribute or inline `style="display: none"` support in `mode 3` to not display templates.
* Also CSS grid for nice presentation: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-template
* Also CSS grid for nice presentation: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-template
(presentation is less nice on small screens, should be easy to make layout responsive, but I already spent too much time on this project).
(presentation is less nice on small screens, should be easy to make layout responsive, but I already spent too much time on this project).
@ -346,33 +350,30 @@ Therefore, for desktop browsers:
UI should be functional (not pretty) in IE8+ (2008) and dysfunctional in IE7 and lower
UI should be functional (not pretty) in IE8+ (2008) and dysfunctional in IE7 and lower
(fixable by refactoring the approach to displaying/hiding elements to avoid the usage of `:not` selector,
(fixable by refactoring the approach to displaying/hiding elements to avoid the usage of `:not` selector,
but this is outside the scope of the task).
but this is outside the scope of the task).
* links: checked on 2.30, half-broken:
* links: checked on 2.30, mostly functional:
* Everything that depends on the game state is always displayed,
* Links doesn't support disabled buttons
i.e. we get "Start game", "Restart game", "make computer play for X",
"make X moves manually", and most importantly,
"Player X won", "Player Y won" and "Draw" all displayed always;
this can be worked around by using Web Components templates
instead of controlling state visibility by CSS.
* Additionally, Links doesn't support disabled buttons
so all board fields are always clickable (even if they're already filled),
so all board fields are always clickable (even if they're already filled),
this does not cause any functional issues (clicking on the occupied field,
this does not cause any functional issues (clicking on the occupied field,
or clicking on an empty field when the game is over, does not change anything),
or clicking on an empty field when the game is over, does not change anything),
but still that's a poor UX.
but still that's a poor UX.
* elinks: checked on 0.17.1.1, half broken in the same way as on links, not easily fixable
* elinks: checked on 0.17.1.1, mostly functional:
because even with Web Components templates, elinks will still display template content:
* elinks just like links does not support disabled buttons in 0.17.1.1,
https://github.com/rkd77/elinks/issues/341.
but this is fixed in https://github.com/rkd77/elinks/issues/341.
Fixable by building all state-dependent components on frontend manually
* elinks does not support `hidden` attribute and by default does not support `display: none` in 0.17.1.1,
(so that backend only sends those that are relevant for the current state),
so it will display the content of all (unused) templates.
but that would be too significant redesign for no benefit besides making things work in elinks.
Support for `hidden` attribute is already implemented in https://github.com/rkd77/elinks/issues/341,
and will automatically work in newer versions; in older versions, the user should add
`set document.css.ignore_display_none = 0` to their elinks config.
So presumably, according to caniuse.com,
So presumably, according to caniuse.com,
* `mode 1` should work in 88% desktop browsers and 80% total browsers
* `mode 1` should work in 88% desktop browsers and 80% total browsers
(with Safari being the notable exception contributing 9% on desktop and 18% overall);
(with Safari being the notable exception contributing 9% on desktop and 18% overall);
* Fallback to `mode 2` should bring the total to at least 96% overall (98% on desktop; for some less popular mobile browsers support status is unknown);
* Fallback to `mode 2` (which is just as functional but with a bit more convoluted JS code)
should bring the total to at least 96% overall (98% on desktop; for some less popular mobile browsers support status is unknown);
* The demo should at least fall back to functional `mode 3` (client-server) with the functional UI
* The demo should at least fall back to functional `mode 3` (client-server) with the functional UI
in 99.9% desktop and presumably 99.9% overall browsers,
in all more or less mainstream browsers (including presumably Internet Explorer 6 and NetFront 3, unchecked),
with Internet Explorer being the main offender.
and in some non-mainstream ones, including text browsers such as links and elinks (checked) but notably not lynx.
## Known issues and quirks
## Known issues and quirks
@ -387,9 +388,6 @@ So presumably, according to caniuse.com,
## Remaining tasks
## Remaining tasks
* Use HTML `<template>`s for rendering state messages,
instead of having them all in HTML and then hiding irrelevant with CSS,
for better graceful degradation in browsers that don't support complex CSS queries with `:not`.
* Implement error handling and handling of incorrect / malformed game states (since they come from the client).
* Implement error handling and handling of incorrect / malformed game states (since they come from the client).
* Improve UI for large boards (disable autoplayers when board is too large,
* Improve UI for large boards (disable autoplayers when board is too large,
hide "enable autoplayer" buttons, provide clear indication to the user instead).
hide "enable autoplayer" buttons, provide clear indication to the user instead).