W3C home > Mailing lists > Public > www-style@w3.org > October 2016

Re: [mediaqueries] hover: on-demand

From: Bruno Racineux <bruno@hexanet.net>
Date: Wed, 19 Oct 2016 02:10:06 -0700
To: Florian Rivoal <florian@rivoal.net>
CC: Greg Whitworth <gwhit@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <D42C1A7C.B2426%bruno@hexanet.net>
On 10/17/16 11:03 PM, "Florian Rivoal" <florian@rivoal.net> wrote:
>Even if two devices are different, if an author would react to both of
>them the same way,
>it is counter productive for media queries to distinguish between them,
>as it just
>creates more author complexity, and opportunities for mistakes or
>> An example use-case is the ability to prevent a CSS 'hover' on the basis
>> of 'on-demand'. Or respond differently to it. On mobile a css:hover can
>> trigger before touch-end, and that's a tricky situation. 'on-demand'
>> provides that detail of accuracy.
>In that case, what would be the problem of applying the code you wanted
>to write for hover:on-demand to hover:none? If no actual on-demand
>is triggered, your code will do nothing, but it isn't causing harm either.

It's not causing harm. It just very much feels like using a non explicit
'on-demand' context that is not being explicitly stated.

>> What if an author wants to replace a long-press touch with something
>> Like a context menu instead or just prevent 'hover'. Authors can't do
>> with
>> a 'hover:none' MQ which is iOS's implementation right now.
>I don't understand why. What about hover:none prevents you from doing

That use case is manageable with CSS. Awkwardly but ok. The JS concern was
the ability to rely on matchMedia('(hover:on-demand)') to be able to
detect what to expect on/after touchstart or cancel on-demand. But on
afterthoughts it may not help all that much.

A long-press on iOS triggers the :hover state but does not fire mouseover
and :hover cannot be cancelled. Android's on-demand triggers :hover then
later mouseover, and the :hover state can be prevented on touchstart. I
was expecting a more predictable on-demand pattern. And Firefox Android
has opted for :hover

The tricky part here is we somehow have an undeclared :hover-on-demand
pseudo behavior. The two can probably be differentiated by :focus:hover vs
:hover I think in addition to the hover:none inference. So that's ok.

Perhaps a specced :hover-on-demand pseudo is what could considered
instead, if a clear case presents itself for that in the future. Meanwhile
a (hover:none) will have to do.

>When it comes to confusion, I think there was a problem with Tab's design:
>hover:on-demand was not falsy, which means that if you just did
>  @media (hover) { .... }

Ok I did not fully understand what the falsy aspect related to before.
Thanks for clarifying.

Received on Wednesday, 19 October 2016 09:10:42 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:01 UTC