Re: [csswg-drafts] [mediaqueries-4] Interaction Media Features make a rigid primary/"rare" distinction

I started by answering your points individually, but you have a lot, 
and I am not sure this will be productive, as we seem to be talking 
past eachother to some degree, and I am not sure answering the details
 when we seem to be having a fundamental disagreement is the best way 
forward.

I will write below the points I have already written answers to below,
 but I would like to reiterate my earlier request: can you please 
provide concrete examples of a sets of designs you wish to switch 
between using `[any-]?[pointer|hover]`, and concrete examples of 
devices they would be used on, and what you'd like to happen (and 
why)? The current design is intended to make it easy for an author to 
do the right thing in the general case, even when running on a device 
they have not tested on or anticipated, and to expose some additional 
information for more sophisticated use cases. This does assume that 
UAs are going to do a decent job a deciding what information to show 
through the `pointer` and `hover` and their any variants, possibly 
dynamically depending on the device. But it seems to me that with your
 alternative proposal, the only things authors can conclude is that 
they have no idea what the user might be comfortable with, and that 
they should never design anything with fine targets and hover effects.
 But in that case, you don't need input device MQs at all, so clearly 
this is not what you're after.

I do not understand how it is useful to the author to have a as the 
sole information about input capabilities a list of input capabilities
 that includes those that are known to the UA to be either something 
that the user doesn't use at all, or something that the user uses 
occasionally but typically not.

You've already given me plenty of high level answers, and I don't seem
 to get it. Please try and give me concrete examples. Hopefully I'll 
process that better.

----

Answer to some of your detailed points below. But again, an answer to 
the point above would help me much more.

> You talk of lowest common denominator and "dumbing down", so clearly
 you have a value judgement here that having large targets and no 
hover is intrinsically a bad thing.

Actually I don't. I think large targets and no hover can often be a 
better design. But I also think that when a designer has made a large 
target / no hover design and a small target with hover design, and is 
trying to pick between the two based on what input is available, then 
the designer does often have in mind a full UI and simplified one.

> Would browsers take a user-hostile move, really?

Of course not (provided they have a choice). This doesn't answer which
 move is user-hostile.

> So in a finger+stylus scenario, you still contend that stylus is 
then the primary.

Not really: I contend that the primary way the device is intereacted 
with comprises both a stylus and a finger, and that as such, it is 
capable of accurate pointing. (I agree that the spec may need to be 
rephrased to make this interpretation a valid one).

> But take your own example later on of the accurate pointing device 
under the sofa cushions...what if yes, I have finger+stylus, but my 
stylus is currently under that same sofa cushion?

Well, for a computer that only has a cordless mouse, if you lose your 
mouse, you're kind of in trouble as well. If you've misplaced the main
 way you're supposed to use the device, you're up for some pain 
anyway. Which I see it as a different thing from either of the 
following:
- You disagree that this device is supposed to be used with a stylus. 
Maybe tough luck? iPhones don't come with a small-target version of 
their UI for people who decide to use them differently than what 
they're designed for. Maybe there's a setting in the UI that lets you 
switch from finger+stylus to finger-only mode? Maybe the computer is 
smart enough to notice you never use the stylus (or that it is 
currently out of battery, or out of range...) and switches mode for 
you? It seems to me that the spec is trying to give these options to 
the UA/OS/Device vendor.
- You've misplaced the optional bluetooth mouse for your TV. The TV 
can support having a mouse, but was not designed to be used with one, 
so the UI wasn't tweaked for when the mouse was added, and there's 
nothing to switch it back to now that the mouse is lost.

> But by its very definition that's what you're saying though. Are you
 suggesting that authors would check for pointer:fine but then ignore 
it?

I am suggesting that it is perfectly reasonable to not check for 
pointer:fine and to provide large targets always. Just because it 
would return true if you asked doesn't mean that you have to ask. On 
the other hand, authors that do want to provide fine targets should 
indeed check whether that's going to be convenient.

> Designing a page that relies on hovering or accurate pointing only 
because `hover` or `pointer` indicate that (whatever the OS/UA decided
 is) the primary input mechanism has these capabilities, is likely to 
result in a poor experience (as it ignores the fact that secondary 
input mechanisms may be available that lack these specific 
capabilities).

I would phrase it differently: `hover:hover` / `pointer:fine` do 
indicate that hovering or accurate pointing are available and easily 
accessible. They do no indicate preference for or against hovering or 
accurate pointing.

> if (any-hover:none) evaluates to true but (any-hover:hover) also 
evaluates to true [...]
That's not possible, none is defined to match when other values don't.
 On the other hand, it seems to me that this example works just fine 
if (hover:none) evaluates to true but (any-hover:hover) also evaluates
 to true.



> Again, the spec, the OS, the UA, and the author/developer are in no 
position to make that particular assessment, and it is user-hostile to
 assume that it's ok to ignore the input mechanism the user might be 
currently using because it's not the "right" (primary) one.

An OS that would insist that the way the user is consistently using 
the device is not the primary way the user is using the device would 
be doing it wrong. My take is that yes, the OS+UA (but not the authors
 of the page) is in a position to judge what is the primary way the 
user uses the device, by combining knowledge about what the device is,
 what is connected to it AND how the user generally uses it AND how 
the user currently uses it.

----
All in all, I agree this is a tricky feature, so I am open to better 
approaches. And I agree that multi-input makes this tricky. But I 
would rather avoid answering the query with something that comes close
 to“The user may be using whatever”, because then authors cannot do 
anything other than ignore this information.

The `any-*` are meant to be a generic fallback that isn't particularly
 smart but is reliably predictable. The `pointer` and `hover` queries 
can only be useful if the OS+UA is generally right about what is the 
primary way to interact with the device, not in an abstract sense, but
 in actual practice.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/690#issuecomment-260895708 
using your GitHub account

Received on Wednesday, 16 November 2016 09:24:42 UTC