- From: François REMY <francois.remy.dev@outlook.com>
- Date: Mon, 28 Apr 2014 20:43:30 +0200
- To: "Oren Freiberg" <oren.freiberg@microsoft.com>, "Rick Byers" <rbyers@chromium.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "CSS WG" <www-style@w3.org>
> >I think a less error-prone approach to separating them is to have
> >separate boolean rules, eg. 'fine-pointer' and >'coarse-pointer'. This
> >is >also more extensible (eg. what if we decide there's another option
> >than just coarse >and fine, 'both' would be pretty confusing <grin>).
> You make a good point and I can both agree with it and align with this.
Fwiw, I think this could possibly be a mistake; it looks like a
reincarnation of the problem Pointer Events tried to solve, put another way.
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.
?
That way, we can detect "touch support on laptops" or "digital pen input on
tablets" using "any-pointer" while still keeping the site-optimization task
simple using "primary-pointer".
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).
Received on Monday, 28 April 2014 18:43:56 UTC