Re: [mediaqueries] hover: on-demand

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
>oversights.
>
>> 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
>hovering
>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
>>else?
>> Like a context menu instead or just prevent 'hover'. Authors can't do
>>that
>> 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?

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.


Bruno

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