Touch Support Test

The number at the top of the panel is navigator.maxTouchPoints, and it answers a narrower question than it appears to. It is not a count of fingers you have used, nor a count of devices. It is the maximum number of simultaneous contact points the browser believes the hardware can report, and it is a static figure set when the browser starts.

Typical values are telling. A modern phone or tablet reports 5 or 10, because that is how many fingers the digitiser tracks. A touchscreen laptop usually reports 10. A device with a stylus may report a higher number to cover the pen and fingers together. Zero means the browser sees no touch digitiser at all.

CSS gives pages four related queries. pointer describes the primary pointing device and answers fine, coarse or none; a trackpad or mouse is fine, a finger is coarse. any-pointer asks the same question of every attached device, so it can report coarse and fine at the same time. hover and any-hover do the same for hovering: a mouse can hover, a finger cannot.

The distinction between the plain and the any- form is the whole point of the feature. A site that wants to know whether to rely on hover should ask hover, because that describes the input the user is actually holding. A site that wants to know whether a touch target should be enlarged should ask any-pointer: coarse, because the user may reach for the screen at any moment.

A Windows laptop with a touchscreen and a trackpad is the case that confuses naive detection. The operating system calls the trackpad primary, so pointer: fine and hover: hover both report true. It also has a digitiser attached, so any-pointer: coarse reports true, and maxTouchPoints reads 10.

Nothing in that set is wrong, but the shape of it — fine primary, coarse available, ten touch points — describes a convertible or a touchscreen laptop rather than a desktop or a phone. A detector that computes a fingerprint from input capabilities sees a configuration shared by a much smaller group than either extreme. The panel above flags this as a hybrid rather than a contradiction, because that is what it is; the contradiction case is a device reporting a coarse pointer while claiming zero touch points, which the panel treats as a genuine conflict.

Before Pointer Events, touch was handled by a separate event family: touchstart, touchmove, touchend, each carrying a list of every contact point currently on the screen. Handling mouse and touch then meant writing two code paths that behaved differently for reasons no one wanted to remember.

Pointer Events collapsed that into one stream. Each event carries a pointerId that stays stable for the life of the contact and a pointerType of mouse, pen or touch, so multi-touch becomes a matter of tracking ids in a set — which is exactly what the live pad above does. Every current browser implements the full set, and the one addition is pointerrawupdate, which reports motion at input-device frequency and is Chromium-only. Seeing it listed as unsupported tells you the browser is not Chromium.

A phone reporting ten touch points is a phone, and no one is surprised by that. The informative cases are the edges: a machine with no touch that still claims touch events, a desktop reporting a coarse pointer, or a browser whose touch values disagree with its user agent. Those combinations are rare and therefore memorable.

Taken together with the screen signals, input capabilities round out a description of the device rather than the person. The device pixel ratio test and the device and hardware test cover the rest of the machine, and the browser fingerprint test shows what all of it adds up to.