Re: [mediaqueries] hover: on-demand

> On Oct 18, 2016, at 13:06, Bruno Racineux <bruno@hexanet.net> wrote:
> 
> As I saw last week that 'on-demand' was suddenly being removed. I am
> concerned. I think 'on-demand was just fine as intended by Tab, as that's
> a proper signal what mobile touch does.

This happened a while back (march), after due process, but regardless, your
questions are good questions, so let's dive in.

> Whether voluntarily added by Chrome/Android touch, or a results of legacy
> mouseover
> fallbacks for non-mobile sites on iOS; I still don't quite get @smfr's
> argument that it's not what Webkit wants when on-demand "is in fact" the
> behavior.

I think the key here is that media queries are not meant to describe all
the different nuances of the different devices in as much details as possible.
Instead, we aim to expose the most relevant information in an easily actionable
way.

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.

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

> i.e. A lack of 'on-demand' means accepting the following rule as valid:
> 
> @media (hover:none), (any-hover:none){
> .myclass:hover {
>  //Why do I have a :hover triggering here? What's my inference point for
> that?
> }
> }

Because the user did hover even though they were on a device where doing so
isn't terribly practical, or despite a physical disability that makes hovering
difficult for them.

> That's weird and confusing. I don't think the corner case argument, or it
> "possibly" being confusing to authors has sufficient merits for the
> removal. The opposite is what end up happening in my opinion.

On the corner case argument, for now I stand by it. While I agree that
a device with an on-demand behavior is different from one that is strictly
impossible to hover, and that you would be able to write code that depended
on that difference if it was exposed, I don't think anyone has raised
concrete examples of actually trying to do so. Not just "if it were there
I might be able to use it for something" but "here is a specific design
that I'm going after, which would be inappropriate to use both with
hover:none and hover:hover".

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) { .... }
you would match on hover:hover devices and hover:on-demand devices. Authors
who have made an alternate design that works well without hover would
accidentally fail to serve it to devices for which it would generally be
the best choice. Since that is the shortest syntax, trying to teach authors
away from it would be counter productive. We want the simple-and-obvious syntax
to be the one that does the right thing as often as possible

We could solve that by making the on-demand value falsy, but then
  @media not (hover) {}
and 
  @media (hover:none) {}
would be different, unlike any other MQ that has a none value. That too
is counter intuitive and hard to teach.


> You could
> equally end up with authors making bad assumption about 'coarse' implying
> on-demand behavior when it may not etc...

That would be bad, just like people assuming that (width:320px) means you're on an iphone.
However, unlike that example, there is no evidence that a large number
of authors are trying detect on-demandness, much less of doing that with misguided code.

> Also JS use cases for such MQs
> are important. It's not only a matter of CSS markup.

Fair enough. I'd appreciate examples of code that you can write but
that would not be appropriate to activate unless you knew you were on
an on-demand device.

> More wishy washy states and guesses based upon the platform behavior, by
> JS detection and the likes, is not what I want to keep doing. Accuracy is
> more important to me.

There's a tention. More fine grained detection of everything enables things
you couldn't conveniently do otherwise, but does so at the expense of making
the whole platform more complex. Depending on the situation, it can still
in some cases be worth exposing, but generally not if it would only serve niche
needs while making life harder for everyone else.

So that's why it boils down to: either we find a way to expose the information
in a way that does not inconvenience most authors, or we can point to enough
concrete demand to justify the cost (or both), or we don't add the feature.

 - Florian

Received on Tuesday, 18 October 2016 06:03:46 UTC