W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2020

[csswg-drafts] Pull Request: [mediaqueries-4] expand/change emphasis of advice for use of pointer/hover/any-pointer/any-hover

From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 May 2020 09:08:34 +0000
To: public-css-archive@w3.org
Message-ID: <pull_request.labeled-93839942-None-sysbot+gh@w3.org>
frivoal has just labeled a pull request from patrickhlauke for https://github.com/w3c/csswg-drafts as "Tracked in DoC":

== [mediaqueries-4] expand/change emphasis of advice for use of pointer/hover/any-pointer/any-hover  ==
Related to the discussion in https://github.com/w3c/csswg-drafts/issues/690 this is an initial expansion/change to the current advice given for `pointer`/`hover`/`any-pointer`/`any-hover`.

[edit: copying the relevant description from the individual commits here, for completeness]

* Change "rare" to "all available": "rare" is a loaded term, unnecessarily implying (without much foundation) the likelihood/frequency that a user may use inputs deemed "not primary" by the OS/UA. In addition, as `any-*` also include the pointer that is deemed primary, the "rare" moniker is even more inappropriate, as by definition the "primary" is not "rare".

* Reword the note about pointer/hover vs any-*: Change the emphasis of the note, away from making the `any-*` features sound like a nice-to-have, and more towards aknowledging that these can be useful in making a page/app adapt better/preemptively to all available input methods.

* Add new example for any-hover usage: Include the common touchscreen laptop scenario, and show how `any-hover` can be used to make two completely different judgement calls on the part of the author (one inclusive, one exclusive)

* Add additional any-* consideration note to pointer/hover: The rationale given in any-pointer/any-hover about not relying exclusively on any-* is equally valid in reverse here. This does not imply that authors must design for "lowest common denominator", but simply opens up the possibility that they may wish to keep non-primary inputs in mind when deciding on their layout/functionality.

* Soften/expand the advice in the modified note for any-*: Reworded to remove the implication that authors should "ensure" that "ideally" they take any-* into account...turning it into a "may", which explains more about the rationale for the existence of these `any-*` features without seemingly mandating that authors must follow a specific style/design decision.

While I'm still not a fan of the "primary" concept, this PR would be a compromise I could (currently) live with (in which case this PR could close the relate issue)

See https://github.com/w3c/csswg-drafts/pull/715
Received on Thursday, 28 May 2020 09:08:40 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:07 UTC