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

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
>