Re: [mediaqueries] reevaluating media queries when the environment changes

> On 07 Apr 2015, at 22:23, Greg Whitworth <gwhit@microsoft.com> wrote:
> 
>> MQ4 states:
>> "User agents should re-evaluate media queries in response to changes in the user environment"
>> MQ3 has the same, phrased differently.
>> I believe this was intentional, but I cannot think of any good reason for using should rather than must in this sentence, and would like to change.
> 
>> The only two reasons I can think of are:
>> 1) If we write MUST, this will delay MQ3 getting to REC
> 
>> If that's the case, this is no longer relevant, and we can use must
> 
>> 2) We want to allow some user agents to layout and render a static view of the page once, and then never touch it again (no relayout, no interaction, no javascript after the initial load...).
> 
>> If that's what we want to do, we can carve out a specific exemption for such UAs, without allowing normal interactive browsers to fail to update their media queries when something changes.
> 
> I think this would be best to stay as 'SHOULD' as that implies your desired end result while keeping us from forcing a 'MUST' on all current or future MQs. I think if you want to be more explicit than this, then each MQ evaluation type should be listed and whether or not they 'SHOULD' or 'MUST' be re-evaluated on environment change.

I just went through the list of all media features we have, and I think they should all be MUST.

There are two places where I think it may not be obvious, so let's clarify.

1) For some of MQs, it is difficult to imagine them changing at all in a live environment, such as the grid media feature for example. If something cannot change, it doesn't really matter what we say about what happens when it changes.

2) The pointer and hover queries.

I can reasonably think of cases where you wouldn't want them to update when new input devices become available or existing ones are removed. Let's say a user is on a tablet using the touch screen, and a previously paired mouse comes in bluetooth range, you don't want the UI to suddenly change.

This is however not in contradiction with having re-evaluation as a MUST. pointer and hover reflect only the primary input device, and the UA is meant to be smart about which device is the primary one, to follow platform conventions, apply heuristics, and possibly (although that may not always be appropriate) prompt the user.

For example, if my understanding of Continuum on Windows 10 is correct (I don't have it to test), the OS has a tablet mode (The-UI-system-that-shall-no-longer-be-called-Metro) and a desktop mode, and will switch from desktop to tablet mode when you for example detach the keyboard+trackpad. On this platform, when in desktop mode, I would expect pointer:fine and hover:hover as that is a good description of the trackpad. When in tablet mode, I would expect pointer:coarse and hover:none as that is a good fit for a touch screen.

If a mouse is connected during desktop mode, it would make no difference to either pointer and hover, as a mouse and a trackpad cannot be distinguished in terms of pointer accuracy or hovering ability. If a mouse is connected while in tablet mode, I would expect to follow the platform convention. If doing so would switch the whole OS to desktop mode, or prompt the user as to whether they'd like that to happen, the media queries would flip as well. I suspect that doesn't happen though, and that the device stays in tablet mode, in which case pointer would stay coarse, and hover would stay none. 

Even on a platform without such conventions, I don't expect the UA to blindly switch these media queries every time an input device is connected or disconnected from the OS. Hover and pointer need to reflect the input device through which the user is primarily interacting with the system. If something which the user isn't using (much) changes, it shouldn't impact 'hover' and 'pointer'. But if the primary input was a mouse, and it gets disconnected and you're left with only a touch screen or a TV remote control, you have to update the queries, otherwise the site risks being unusable.

The spec may not be entirely clear about this at the moment as it is very short on details about what is meant by "primary", but that's the intention, so I'll clarify.

To me, this means that while you have to be somewhat smart about what device is the primary one, if you determine that the primary one has changed, pointer and hover also MUST update. Otherwise they are not usable for their intended purpose.

 - Florian

Received on Wednesday, 8 April 2015 09:51:02 UTC