Re: [mediaqueries] hover: on-demand

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.

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.

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.

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

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. You could
equally end up with authors making bad assumption about 'coarse' implying
on-demand behavior when it may not etc... Also JS use cases for such MQs
are important. It's not only a matter of CSS markup.

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.

Bruno



On 3/22/16 9:07 PM, "Greg Whitworth" <gwhit@microsoft.com> wrote:

>> > On Feb 10, 2016, at 10:12, Tab Atkins Jr. <jackalmage@gmail.com>
>>wrote:
>> >
>> > On Sun, Feb 7, 2016 at 6:55 PM, Florian Rivoal <florian@rivoal.net>
>>wrote:
>> >>> On Feb 6, 2016, at 03:56, fantasai <fantasai.lists@inkedblade.net>
>>wrote:
>> >>> hover: none | on-demand | hover
>> >>>
>> >>> Unless we can make 'on-demand' result in a boolean evaluation of
>> >>> "false", I think we should drop the value and classify such UAs as
>>"hover:
>> none".
>> >>> It seems like these UAs should be opted into @media not (hover)
>> >>> designs rather than @media (hover) designs.
>> >>
>> >> I agree, but I think Tab doesn't (he introduced this part), so I'd
>> >> like to hear his take on this.
>> >
>> > Yes, I disagree.  on-demand hovering UAs *can* handle hover-based UIs,
>> > it's just not ideal.
>> That's true, but I wonder if the upside is bigger than the downside.
>> 
>> Upside: If for some reason both a hovering UI and a non-hovering UI are
>> possible, but the non-hovering UI would harder to use than the
>>on-demand-
>> hovering UI, authors can make the decision to show the later one on
>>devices
>> that can cope.
>> 
>> Downside 1: Authors will accidentally provide hovering UIs on device
>>where
>> this is very inconvenient-but-possible, even though they have an viable
>> alternative to offer.
>> 
>> Downside 2: It is unclear what people who don't want to hover but are
>>able
>> to should set their UA to represent them as. Pick none, and you risk
>>opting in
>> to pages which break if you do hover after all, pick on-demand and you
>>risk
>> getting pages with a hover UI even though an non hover one was
>>available.
>> 
>> My personal and non-data based estimate of this makes me think that the
>> upside is actually a limited corner case, downside 1 is likely to be
>>pretty
>> common, and downside 2, even if rare, is a missed opportunity for
>> accessibility.
>
>What is a real world end user scenario that requires the need for this
>MQ? Is this being requested by someone? Personally, this feels like a
>solution looking for a problem, but I am happy to be proven wrong.
>
>Greg

Received on Tuesday, 18 October 2016 04:07:29 UTC