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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 28 Apr 2014 11:49:48 -0700
Message-ID: <CAAWBYDA9084r0JFoyrnttkPcm3v3FwzZNu6mrzpCC0MgkQ2dBQ@mail.gmail.com>
To: Fran├žois REMY <francois.remy.dev@outlook.com>
Cc: Oren Freiberg <oren.freiberg@microsoft.com>, Rick Byers <rbyers@chromium.org>, CSS WG <www-style@w3.org>
On Mon, Apr 28, 2014 at 11:43 AM, 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 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.

> Exposing both properties enables more complex scenarii like making "enable
> touch interface" button visible when "@media(any-pointer: coarse)" but
> enable the coarse mode only when either "this button is toggled on" or
> "@media(primary-pointer: coarse)". Once browsers support Custom CSS At-Rule,
> this could be as easy as "@media(--ui-mode: coarse)" with a simple JS
> maintaining the state accordingly by listening to the related events (while
> we wait we could use a css class on the root element).

Yeah, this is a reasonable use-case.

~TJ
Received on Monday, 28 April 2014 18:50:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:21 UTC