- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 28 Apr 2014 11:49:48 -0700
- 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