diff --git a/README.md b/README.md index 9e88d2f..add7ed8 100644 --- a/README.md +++ b/README.md @@ -308,6 +308,9 @@ The main required features are: without them this demo will fall back to `mode 3`. * Custom built-in elements: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/is, without them this demo will fall back to `mode 2`. +* Templates: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template, + without them `mode 1` or `mode 2` will break, but they're in baseline HTML, + so if they're not supported, ES modules are not supported either, and this demo will fall back to `mode 3` anyway. * `:scope` CSS selector, needed in `mode 2` only: https://developer.mozilla.org/en-US/docs/Web/CSS/:scope * `MutationObserver`, needed in `mode 2` only: @@ -315,6 +318,7 @@ The main required features are: * `:not` CSS selector for critical UI features, needed in all modes (hiding and showing different messages and buttons depending on the game state): https://developer.mozilla.org/en-US/docs/Web/CSS/:not. +* `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 (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 (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). -* links: checked on 2.30, half-broken: - * Everything that depends on the game state is always displayed, - 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 +* links: checked on 2.30, mostly functional: + * Links doesn't support disabled buttons 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, or clicking on an empty field when the game is over, does not change anything), 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 - because even with Web Components templates, elinks will still display template content: - https://github.com/rkd77/elinks/issues/341. - Fixable by building all state-dependent components on frontend manually - (so that backend only sends those that are relevant for the current state), - but that would be too significant redesign for no benefit besides making things work in elinks. +* elinks: checked on 0.17.1.1, mostly functional: + * elinks just like links does not support disabled buttons in 0.17.1.1, + but this is fixed in https://github.com/rkd77/elinks/issues/341. + * elinks does not support `hidden` attribute and by default does not support `display: none` in 0.17.1.1, + so it will display the content of all (unused) templates. + 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, * `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); -* 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 - in 99.9% desktop and presumably 99.9% overall browsers, - with Internet Explorer being the main offender. + in all more or less mainstream browsers (including presumably Internet Explorer 6 and NetFront 3, unchecked), + and in some non-mainstream ones, including text browsers such as links and elinks (checked) but notably not lynx. ## Known issues and quirks @@ -387,9 +388,6 @@ So presumably, according to caniuse.com, ## Remaining tasks -* Use HTML `