- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Thu, 17 Nov 2016 04:03:16 +0000
- To: public-css-archive@w3.org
frivoal has just labeled a pull request from patrickhlauke for https://github.com/w3c/csswg-drafts as "mediaqueries-4": == [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, 17 November 2016 04:03:23 UTC