W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: [mediaqueries4] pointer: coarse and pannable, zoomable viewports

From: Stu Cox <stuart.cox@gmail.com>
Date: Fri, 1 Mar 2013 00:02:39 +0000
Message-ID: <CAJ-2Ov5fPdW==hYypScu2b-90ZHo97nbijNgZh0Lm-Y_mRNEHg@mail.gmail.com>
To: www-style@w3.org
> I am a bit late to the conversation, but here is how I envisioned it when
> I wrote it up.
>
> First, let's quote what I wrote, it may not be very clear, but it is
> actually
> intended to provide some guidance over this:
>
> "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."
>
> So as you said, the UA picks the lowest resolution, but not necessarily
of
> all input devices, just of the primary ones. By primary, I mean the
normal
> way to interact with the device.
>
> This media feature does not indicate that the user will never be able to
> click accurately, only that it is inconvenient for him to do so. If you
> require accurate clicks when the MQ said 'coarse', you may be forcing the

> user to zoom, or you may be forcing him to fetch his optional blue-tooth
> mouse from across the room.
>
> Whether an input mechanism is primary or not is a subjective call from
the
> UA vendors. In a bunch of cases, it should be obvious, and then of
course,
> there is a grey area in the middle. My intention was to leave it up to
> vendors, as they know best how they know better than spec writers the UI
> paradigm of their device.
>
> On an old fashioned tablet-pc (this kind:
> http://en.wikipedia.org/wiki/Microsoft_Tablet_PC), you may consider the
> touch screen to be a secondary input device when the laptop is open. As
> you are then faced with the good old mouse driven UI, the touch screen is

> not expected to be the normal way to use the device. If you fold it to
> tablet form, then the touch screen becomes the normal way to drive the
> device, and it would determine the media query.
>
> On the other hand, on a Microsoft Surface, I would expect (I might be
> wrong, having never used one) that even when the cover is connected,
touch
> is still intended to be a completely normal way of interacting with the
> device. In that case, both the touch screen and the trackpad on the cover

> would be considered primary input devices. In order not to force the user

> away from one of them, the MQ could report 'coarse'. Alternatively, if
> Microsoft thought that pluging the cover in indicates that we should
> switch to some kind of laptop mode, and makes various adjustments across
> the UI to be more suitable to the pad than to the touch screen, then
> switching to 'fine' could be more appropriate.
>
> If you remove the mouse from a desktop computer (who needs a mouse when
> you know all the keyboard shortcuts), you'd switch from 'fine' to 'none'.
>
> Plugging a game controller on a pc, however inaccurate, would not change
> the MQ, as the controller is not the normal way to interact with
computer,
> just an extra thing.
>
> I hope this clarifies what I had in mind. Does that sound reasonable?
>
>   - Florian


Hello,

I've just been catching up with this. I wonder if the "primary pointer"
issue could do with some more clarification.

You say above that choice of primary input mechanisms is a subjective
choice for the UA vendors. However, the Pointer Events spec gives a
slightly more formal definition implying that *any* two input devices
connected would be primary; e.g. touch and mouse; I quote:

> When two or more pointer device types are being used concurrently,
multiple pointers are considered primary.

It also only suggests "multi-touch" as an example of multiple pointers from
which a primary would be selected. This suggests that any connected device
would have one primary pointer and e.g. subsequent contact points of a
touch input would be a typical example of non-primary (secondary?) pointers.

Or are these definitions unrelated?


Stu Cox
Received on Friday, 1 March 2013 13:32:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT