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

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

From: Rick Byers <rbyers@chromium.org>
Date: Fri, 19 Dec 2014 11:56:53 -0500
Message-ID: <CAFUtAY-KURhy0BOuGrgrjtNnuQy3Mv-vTLxHZ25gHHBRseSjnA@mail.gmail.com>
To: Oren Freiberg <oren.freiberg@microsoft.com>
Cc: Mustaq Ahmed <mustaq@chromium.org>, Florian Rivoal <florian@rivoal.net>, Brandon Walderman <brwalder@microsoft.com>, CSS WG <www-style@w3.org>, Fran├žois REMY <francois.remy.dev@outlook.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Rossen Atanassov <Rossen.Atanassov@microsoft.com>
On Thu, Dec 18, 2014 at 5:55 PM, Oren Freiberg <oren.freiberg@microsoft.com>
wrote:
>
> > We think the spec should avoid ambiguities around non-pointer
> devices---we were bitten by this during our implementation.
> > Details: Even though 'pointer', 'any-pointer', 'hover' and 'any-hover'
> values are meant for pointing devices only (right?), the spec
> >    http://dev.w3.org/csswg/mediaqueries-4/#mf-interaction
> > defines 'pointer' and 'hover' values ambiguously with respect to
> inclusion/exclusion of non-pointing input device like keyboards:
> >
> > A. The 'pointer' value definitions include non-pointing devices, but the
> 'hover' value definitions don't. These defs use "... primary input
> mechanism ..." and "... primary pointing system ..." respectively.
> > B. The 'any-pointer' and 'any-hover' definitions include non-pointing
> devices: "... capabilities of all the input devices ...".
>

It turns out Tab and I made some different assumptions on the intentions
here (and failed to talk to each other about it - sorry!).  I think the two
specific open issues are:

1) Is the distinction in the spec language between "pointer device" and
"input device" meaningful?  Can we just clarify all the wording to refer to
"pointing" devices to make it clear these APIs have nothing to do with
non-pointer input devices like keyboards?

2) What are the semantics for "any-{pointer,hover}: none"?  If it's
strictly a union of the {pointer,hover} values (as Tab instructed Dave off
thread for our initial implementation in chromium) then 'any-pointer: none'
will always be true.  If instead, it's a union of all capabilities (where
'none' represents the absence of a relevant capability) then 'none' is
mutually exclusive with all other values and so 'any-pointer' is true iff
'pointer' is true.  The latter makes the most conceptual sense to me, and
appears (from our limited testing) to be what the IE tech preview
implements.  We've just switched our implementation to match this (before I
was aware of the discussion between Dave and Tab on this point).


> > Hope we didn't miss anything in-between.
> > Mustaq
> >
> > On Thu, Dec 18, 2014 at 1:54 PM, Florian Rivoal <florian@rivoal.net>
> wrote:
> > On 15 Dec 2014, at 21:54, Mustaq Ahmed <mustaq@google.com> wrote:
> >
> > Update: we are on track to ship 'any-pointer' and 'any-hover' media
> queries in Chrome M41 (
> https://www.chromestatus.com/features/6460705494532096). These are
> already available in Chrome canary builds for testing. Note that we shipped
> 'pointer'
> > and 'hover' media queries in M38.
> >
> > BTW, IE 11 tech preview is also shipping these:
> >
> https://status.modern.ie/mediaquerieslevel4interactionmediafeaturespointerandhover?term=media%20queries
> >
> > Good to hear, thanks for the update. Any feedback on the feature itself,
> or the way it is specified, based on this implementation?
> > Also, I suppose you wrote some tests in the process of developing this.
> It would be greatly appreciated if you could contribute these to W3C to be
> included in the test suite for media queries 4, to help move the spec along
> the REC track.
> >  - Florian
> >
> > PS: Hi Microsoft, same questions about feedback and tests for you.
>
> Adding Brandon the developer to represent Microsoft for this feature area.
>
> Thanks!
> Oren
>
Received on Friday, 19 December 2014 16:57:41 UTC

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