[mediaqueries-4] expand/change emphasis of advice for use of pointer/hover/any-pointer/any-hover #715
Conversation
"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".
|
/cc @frivoal / other editors for review |
There was a problem hiding this comment.
Some parts of the PR seem useful regardless of where the discussion in #690 ends up going, so I would like to merge it. On the other hand, two parts are incorrect given the current definition of any-hover: none. I suggest removing them so that I can merge the rest.
Maybe as a result of the #690 discussion we'll end up changing the spec to make these two parts correct and then we can add them back, or maybe we'll change the design enough that they're no longer needed. Or maybe not. Until, I suggest we just merge in the parts where we do agree.
| @@ -1607,7 +1607,7 @@ Pointing Device Quality: the 'pointer' feature</h3> | |||
| Type: discrete | |||
| </pre> | |||
|
|
|||
| The 'pointer' media feature is used to query about the presence and accuracy of a pointing device such as a mouse. | |||
| The 'pointer' media feature is used to query the presence and accuracy of a pointing device such as a mouse. | |||
There was a problem hiding this comment.
Is this to fix incorrect grammar, or are both sentences valid but mean different things? My non native speaker brain prefers the current phrasing, but I am very possibly either missing a nuance or not noticing a mistake.
There was a problem hiding this comment.
This is for grammar, but also for consistency (if you check the rest of the spec, there are 5 instances of "query the ...", e.g. " query the value of individual features", "query the ability of the output device to modify the apearance of content ..." etc
| In addition, even if the primary input mechanism has 'hover: hover' capability, | ||
| there may be additional input mechanisms available to the user where 'hover: none' is true. | ||
| Authors may wish to query the 'any-hover' media feature to take these other non-hover-capable | ||
| potential input mechanisms into account. |
There was a problem hiding this comment.
This does not work. While there may be other devices which cannot hover (and arguably this is a common case: every desktop computer with a mouse also has a keyboard that cannot hover), the query will not let you detect that in the way you suggest. any-hover: none only matches if none of the devices can hover, not merely if some of them cannot.
Maybe we should change that (although I am not convinced), but until we do, this note is incorrect.
| use of the hover capability is essential for their page, and display a notification | ||
| reminding users to only use their mouse/trackpad. | ||
| </div> | ||
|
|
There was a problem hiding this comment.
Same comment as above: any-hover: none only matches if none of the devices can hover, not merely if some of them cannot, so this example is incorrect.
|
oh, i must have misunderstood the |
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.
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.
patrickhlauke
force-pushed
the
mediaqueries4-pointer-hover
branch
from
6f9957e
to
580529b
Compare
|
Force-pushed a change removing the stuff relating to my incorrect understanding of |
|
Thanks, merged.
Sure. And thanks for agreeing to slice this issue in smaller chunks. It seem easier to make progress this way. |
frivoal
added
the
Commenter Satisfied
frivoal
added
Tracked in DoC
Testing Unnecessary
Related to the discussion in #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-hovercan 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)