- From: Florian Rivoal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Nov 2016 07:17:07 +0000
- To: public-css-archive@w3.org
Given that it is not possible for a UI to show buttons that are simultaneously small and large , at some point there's got to be a judgement call as to whether the UI is suited to fine pointing or not. It is not possible to have a UI that simultaneously relies on hovering and does not use it, so there's got to be a judgement call as to whether the UI is suited to a device for which hovering is practical or not. Only using any-* is a cop out: it tells the author: "there's a bunch of input devices, some of which might be ignored by the user but you can't know which". If authors start to design for the lowest common denominator, this will be an incentive for browser vendors to not report under any-* some of the less used the devices that users, because it dumbs down the UI unnecessarily. At which point `any-*` become something like what the `pointer` and `hover` were meant to be, and nothing takes the role of the original `any-*`. When you take the surface studio horizontal in drawing-desk mode, you quite possibly have a device which is primarily used both with pen an stylus. So maybe it could be described with `coarse` and `fine` matching at the same time on `pointer`. But the way I think of it this finger+stylus interaction is able to make accurate clicks, thanks to the stylus. So when designing a UI for it, you do not need to forgo small clicking targets. Just like not every click target is tiny on desktop screens, `pointer` responding to `fine` does not mean you have to make everything tiny, just that you can when you want to without making everything unusable. Here's the way I think about this: * If `(pointer:fine)` is true, it is ok to use small click targets. Doing so will not inconvenience the user either by asking them to do do fine movements with a device unsuited for that, nor by forcing them to reach out for some optional peripherals. If it's false, you should generally stay away from small click targets. Maybe the user does not have an accurate pointing device, maybe they have one, but it's somewhere under the sofa's cushions, maybe they have a disability that makes fine motion control difficult... * If `(pointer:coarse) and (any-pointer:fine)` is true, the above "should generally stay away from small click targets" is right, as accurate clicking will be doable even if it is an inconvenience. But if it is false, it is "must stay away from small click targets", as the UA is advertising no known way of making accurate clicks. * Same logic for `(pointer:none)` vs `(pointer:none) and (any-pointer)`. `(pointer:none)` tells you to design something that works without clicking, and `(any-pointer)` tells you whether that's a should or a must. * Similarly, `(hover:none)` tells you that the user is unlikely to discover that things can be hovered and even if they knew, they may have a hard time interacting with them. `(any-hover)` tells you whether they have a way to bypass that. So in my mind, it's the `any-*` variants we may be able to do without, as they are expressing a nuance over the more generally useful information. The continued disagreement on this topic makes me wonder 1. Does spec do such a poor job of explaining the logic between this primary / secondary input mechanism that people tasked with implementing it misunderstand what they're meant to do, and instead are at risk of implementing something different that's not nearly as usable? 2. Are the WG or Tab and I oblivious to the fact that the way we want these features implemented is not possible, and that what can be implemented isn't nearly as useful? 3. Are the WG or Tab and I oblivious to some use cases or some devices where the feature as designed falls short of what authors need to do a good job? I am suspecting 1, but you sound like you're on 3. Which is why I think that a few concrete examples would help sort things out. If you can show a few concrete designs, what you would like to do on particular devices, how you'd try to code them up, why it fails to do what you'd hope, we should be able to sort out whether it doesn't work due to a unclear spec leading to misunderstanding about how `pointer`, `hover`, and `any-*` are supposed to work, or because the way they're supposed to work does overlook some key situations. -- GitHub Notification of comment by frivoal Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/690#issuecomment-259063677 using your GitHub account
Received on Tuesday, 8 November 2016 07:17:13 UTC