Everything should still work in online mode, falling back on client-server communication,
except that the design in Safari before 10.1 (2017) will not look very good (but will still be functional),
* WebKit (e.g. qutebrowser, Konqueror, Epiphany and notably Safari): superficialy checked in [BadWolf](https://hacktivis.me/projects/badwolf) 1.3 / webkit2gtk-4.1 2.46.3,
basic functionality seems to work both with JS enabled (in `mode 2`) and with JS disabled (in `mode 3`).
Should work with JS enabled in `mode 2` in all browsers supporting custom elements (e.g. in Safari 10.1 (2017) and newer);
should fall back to `mode 3` in older browsers, except that the design in Safari before 10.1 (2017) will not look very good (but will still be functional),
and will probably become disfunctional in Safari before 3.1 (2008).
* Servo: checked, does **not** work in nightly as of 2024-11-20 and as of 2024-11-25 (even progressive form doesn't work),
and its developer tools host seemingly crashes on this page
@ -323,9 +340,9 @@ Therefore, for desktop browsers:
3. Gating offline JS mode for non-servo browsers only will mean that in the future, when servo is fixed,
this demo will only work in client-server mode, just because servo once had a bug. Not ideal.
(Also not even attempting to use dynamic features in servo will make it more difficult to debug the problem in it.)
* EdgeHTML (classic MS Edge before they migrated to Chromium): not checked, should fall back to client-server mode in all versions,
* EdgeHTML (classic MS Edge before they migrated to Chromium): not checked, should fall back to `mode 3` in all versions,
but the page will not look very pretty in Edge before 16 (2017).
* Trident (Internet Explorer): not checked, should fall back to client-server mode,
* Trident (Internet Explorer): not checked, should fall back to `mode 3`,
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,
but this is outside the scope of the task).
@ -350,22 +367,15 @@ Therefore, for desktop browsers:
So presumably, according to caniuse.com,
* Offline JS mode 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);
* The demo should at least fall back to functional client-server model with the same UI
in at least 98% desktop and at least 96% overall (and likely in at least 98% overall)
(with IE lacking support for grids contributing ~1% on desktop and ~0.5% overall,
and UC Browser and QQ Browser with unknown status of support for grids contributing further 2% overall);
* This demo should at least fall back to functional client-server model with at least functional (but not neccessary pretty) UI
in 99.9% desktop and at least 97% overall browsers (and likely at least 99% overall)
(with older versions of IE lacking support for `:not` selectors contributing 0.1% on desktop,
and UC Browser and QQ Browser with unknown status contributing 2% overall;
it is highly likely that they do actually support `:not` selectors).
* 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);
* 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,
with Internet Explorer being the main offender.
## Known issues and quirks
* The game does not work offline fully on client (i.e. without falling back on client-server communication)
in WebKit-based browsers (such as qutebrowser or Safari), see above.
* Playing against the computer opponent is only supported for boards under 12 squares (i.e. 4x3 or 3x4 max).
* The computer player moves might be counterintuitive at times,
and it might be difficult for a human player to get to lose the game,
@ -380,11 +390,6 @@ So presumably, according to caniuse.com,
* 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 custom progressive form wrapper element (use `MutationObserver` to find when forms are added/removed),
use it instead of custom built-in element in browsers not supporting custom built-in elements
(i.e. all modern WebKit browsers including Safari 10.1+, and Chrome 54 to 66),
so that these browsers will get offline client-only support too,
instead of falling back to client-server mode.
* 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,
hide "enable autoplayer" buttons, provide clear indication to the user instead).