Re: [mediaqueries4]Differentiating touchscreen+mouse from touchscreen only scenarios

On Mon, Apr 28, 2014 at 4:03 PM, François REMY <
francois.remy.dev@outlook.com> wrote:

> Wouldn't it be better to have
>>>
>>>    primary-pointer: (fine || coarse) && (has-hover || has-no-hover)
>>>    any-pointer: (fine || coarse || fine && coarse) && (has-hover ||
>>> has-no-hover || has-hover && has-no-hover)
>>>
>>>    - where "primary-pointer" returns the value of the most convenient
>>> input
>>> method (and opposite values are therefore mutually exclusive),
>>>    - and where "any-poiner" returns the combination of the flags that
>>> match
>>> any of the enabled input methods without distinction.
>>>
>>
>> Note that this doesn't address the issue of "this device has multiple
>> primary inputs", which still means that you need to be able to match
>> multiple values for the "primary" thing.  Unless you're arguing that
>> devices should just make up their mind and settle on a single primary
>> input, and leave the detection of secondary inputs to the any-* MQs?
>>
>
> I think it's not unreasonable. That would make the spec text simpler by
> just clarifying that only one input method is considered to be the primary
> one (even if that selected one could technically change while the page is
> being run if the browser really want to).
>
> To clarify, I'm not against multiple primary pointers, but it's difficult
> to spec and it remains hard for authors to guess what to do anyway; the
> device manufacturer and the OS probably knows a lot about the usage habits
> of the device and can provide the simpler piece of advice you need: should
> I optimize my UI for imprecise input methods or not. If the media query
> replies both, that is not really helping, I think.
>
>
>
>  I think this is probably a reasonable approach to the problem of
>> detecting whether it's even *possible* for a user to do something.
>> I'd keep the MQs as written today, and just add another pair called
>> "any-pointer" and "any-hover" which address the rest of the inputs.
>>
>
> Yes, that would be ok; "any-hover" looked a bit strange to me, which is
> why I figured out we should maybe merge the two, but it seeems
> understandable.
>

That seems OK to me.  This also has the nice benefit (in contrast to some
of the other options we've discussed) as being compatible with what we've
already shipped in Chrome.