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

Ping,
Any thoughts on changing 'pointer' to identify multiple primary pointers
instead of just the least-capable one?  We were about to implement
'pointer: fine' in Chrome...

Thanks,
  Rick


On Thu, Apr 11, 2013 at 1:48 PM, Rick Byers <rbyers@chromium.org> wrote:

> On Thu, Apr 11, 2013 at 1:34 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:
>
>> On Thu, Apr 11, 2013 at 9:01 AM, Rick Byers <rbyers@chromium.org> wrote:
>> > Sorry to revive this old thread.  I've had some people request that we
>> > provide a mechanism in Chromium to differentiate "coarse and fine"
>> primary
>> > pointer scenarios from "coarse only" ones (crbug.com/174553).  I think
>> the
>> > argument really boils down to feeling that when there are multiple
>> pointers,
>> > the application should be in charge (or at least part of the decision)
>> in
>> > determining which to consider primary, rather than the UA.  Of course
>> they
>> > can do this today by responding to events (i.e. when a touch is actually
>> > seen, morph the UI or prompt to switch modes), but it's nicer to seed
>> the
>> > decision with a good guess.
>> >
>> > For example, for sites that have a functionally-reduced touchscreen
>> version
>> > and a more powerful mouse-based version - they'd prefer to give users
>> to the
>> > mouse version if it's at all possible for them to use it (and that's
>> > probably what users would prefer too).  Whereas for cases where the UI
>> is
>> > almost the same but just a little large by default when a touchscreen
>> is in
>> > use, it makes sense to default to the coarse mode.
>> >
>> > I think there's a legitimate argument here.  I'm not sure how best to
>> > address it though.  I assume we don't want to allow a feature to take on
>> > multiple values, right?  We could replace the 'pointer' feature with a
>> set
>> > of 2-3 boolean features (fine-pointer, coarse-pointer, no-pointer), but
>> that
>> > would be ugly.
>>
>> There's nothing preventing a feature from taking on multiple values,
>> actually.  All the range-based ones like max-width can be thought of
>> like this if you'd like.  In general, each individual combination of
>> query+value is independent, and can return true/false independently.
>>
>> I'd rather do that than break up the query into multiple new ones.  I
>> think that's more annoying to use, but more importantly, it's not
>> upgradeable - if you didn't bring this point up before implementations
>> were stable, and then *later* we decided we needed the ability to show
>> when a pointer is both fine and course, we'd be stuck if "splitting
>> them up" was the accepted way to handle things.
>>
>
> Awesome!  I propose then that we allow pointer:fine and pointer:coarse to
> both be true at once (with no other combinations permitted), and change the
> wording from "least capable primary pointer device" to "primary pointer
> devices" (or even "preferred pointer devices" if we want to avoid the
> confusion with the notion of 'primary' from pointer events).
>
> Hover is a little trickier - I don't think we want 'hover' and 'not hover'
> to both be true <grin>.  I propose we just leave hover as specified (I
> don't think it's likely to be as much of a problem in practice).
>
>
>> ~TJ
>>
>
>