- 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>
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