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

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.

~TJ

Received on Thursday, 11 April 2013 17:35:09 UTC