- From: Patrick H. Lauke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 Dec 2016 16:28:49 +0000
- To: public-css-archive@w3.org
revisiting this once more, i think part of the discussion about keyboard is actually a red herring, since `pointer`/`hover`/`any-pointer`/`any-hover` in their definition do seem to refer specifically to pointing mechanisms. keyboards and keyboard-like interfaces (d-pads, spatnav, etc) by that definition aren't covered at all by these. so, with this reevaluation, i can see how `any-pointer` would logically be `none` only if none of the pointing devices had any precision, i.e. only if no pointing devices were present. however, in the case of `any-hover`, the one scenario (if we only take pointing mechanisms into account, not generic input mechanisms) that still can't be properly detected today would be: two pointing mechanisms (say a touchscreen and a mouse), one of which is hover capable (mouse), one of which isn't (touch). currently, `any-hover:none` would return false, even though there is a pointing mechanism without hover. does this narrowing of the scope change the discussion here? presumably, the UA should already be "aware" of all the pointing mechanisms (so no, it doesn't need to know about the "rock" next to your computer, but it does know about the touchscreen and the mouse, since it needs to already know about those to correctly evaluate the `pointer`/`any-pointer`), so it *should* be straightforward to then also change the way it evaluates `any-hover` to not just be the union, but to consider all individual hover capabilities of the pointers it presumably knows about already? -- GitHub Notification of comment by patrickhlauke Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/737#issuecomment-269348418 using your GitHub account
Received on Tuesday, 27 December 2016 16:28:55 UTC