W3C home > Mailing lists > Public > www-style@w3.org > April 2013

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 11 Apr 2013 10:34:22 -0700
Message-ID: <CAAWBYDAAEzbW3MOHa1oTB_kwwsSMVpvp79Kg0vQEdphCzW0wgw@mail.gmail.com>
To: Rick Byers <rbyers@chromium.org>
Cc: Florian Rivoal <florian@rivoal.net>, Sylvain Galineau <sylvaing@microsoft.com>, "www-style@w3.org" <www-style@w3.org>, "Edward O'Connor" <eoconnor@apple.com>, Boris Smus <smus@google.com>, bokan <bokan@chromium.org>
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.

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

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:28 UTC