New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 174553 link

Starred by 12 users

Issue metadata

Status: Duplicate
Merged: issue 136119
Closed: Jul 2014
EstimatedDays: ----
NextAction: ----
OS: All , Chrome
Pri: 2
Type: Bug

Sign in to add a comment

Need a way to feature detect for touchscreen laptops with trackpad/mouse

Project Member Reported by, Feb 6 2013

Issue description

It's currently impossible to distinguish touchscreen laptops from regular touch devices without trackpad/mouse. This is bad, since touchscreen laptops can have interactions that use both the touchscreen and trackpad simultaneously.

Basically we need something that says "this device has both a touch screen and a trackpad/mouse". For example, this can be done with an explicit media query to test whether or not a mouse is present. Alternatively, it can be done by fixing the CSS4 spec. The culprit of that spec is this sentence:

"If a device has multiple input mechanisms, it is recommended that the UA reports the characteristics of the least capable pointing device of the primary input mechanisms."

Instead, (pointer: coarse) and (pointer: fine) should be true for touch laptops, and false otherwise.
Labels: Feature-Touch Feature-Ash-Touch
I agree there would ideally be a good way to do this.  In practice some people are doing it today by determining what constitutes a mobile/tablet device by looking for specific UAs (obviously not ideal).

I don't think returning true for both pointer: coarse and pointer: fine is likely to be the right solution though.  First, AFAIK, none of the other media queries work this way - each feature can have exactly one value.  We'd also have to decide what to do with hover (the analgous change of having both hover:0 and hover:1 be true is clearly no good).

One option would be to have new features like 'touchscreen' and 'mouse' that can each return true/false.  A feature like 'touchscreen' is what I originally proposed (exactly like -moz-touch-enabled in mozilla:, but Florian (CSS4 MQ spec editor) felt it was better to focus on the properties of the input devices rather than identifying them (eg. maybe you want coarse pointer optimizations for accessibility too).

Let's try to define a specific scenario here so we can come up with a proposal that fits with the existing MQ approach based on capabilities.  What exactly would a site want to do differently if it knew, for example, that a user would be using both a fine-grained and coarse-grained pointer device?
Labels: -Restrict-View-Google
Status: Assigned
Can this either have an owner or be removed from Feature-Ash? It seems more like a lower-level platform issue.

Comment 4 by, Feb 15 2013

Labels: -Area-UI -Feature-Ash-Touch Area-WebKit MStone-27
Labels: -MStone-27
Boris, can you think of a real-world scenario where this would be used (see comment #1)?  I can't think of anything compelling off the top of my head, so not prioritizing for now.  I'm happy to make this a priority though if we can show that it's actually a pain point.
One usecase is that people assume a touch interface should be presented if touch events are detected. So the touch points will all be much larger. (e.g. Gmail on the PIxel).
Developers will want to decide that even though the user could use the touch interface directly, since they have alternate means of pointing, they may be preferred and a more desktop interface is preferable. 
Project Member

Comment 7 by, Mar 10 2013

Labels: -Area-WebKit -Feature-Touch Cr-Content Cr-UI-Input-Touch

Comment 8 by, Mar 15 2013

Labels: -Cr-UI-Input-Touch Cr-UI-Touch

Comment 9 by, Mar 15 2013

Labels: -Cr-UI-Touch Cr-UI-Input-Touch
Labels: -Cr-UI-Input-Touch Cr-Ui-Input-Touch-Screen OS-Chrome
Project Member

Comment 11 by, Apr 5 2013

Labels: -Cr-Content Cr-Blink
Labels: -Cr-Ui-Input-Touch-Screen Cr-Internals-Input-Touch-Screen
Labels: Cr-Blink-Input
Blocking: chromium:136119
Note the MQ spec ( now has the following language:
 ... if there are multiple reasonable "primary" input mechanisms with different characteristics, UAs may make the feature match multiple values. 

We can probably move ahead with (although I'd still like to hear from other browser vendors - see 

Labels: Hotlist-Input-Dev
Mergedinto: 136119
Status: Duplicate
The MQ spec now resolves this by tweaking the pointer/hover definition and adding any-pointer and any-hover.  The IE team is on-board with this design and is currently implementing it.

Tab says we should be good to ship it as specced -  issue 136119 
Blocking: -chromium:136119

Sign in to add a comment