Re: [mediaqueries] hover: on-demand

On Mar 22, 2016, at 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.

I originally thought it was for touch screen phones and tablets, since they do respond to :hover, but just at the same time as touchstart, and remain in that start until you touch the screen again. 

In fact, to say that @media (hover:none) is for touchscreen phones because the pointing system can't hover seems wrong. I know people who use :hover along with 'display:none|block' to toggle the visibility of a descendant or sibling. It toggles with each tap, like a disclosure control.  

So I don't even know what devices 'on-demand' are for.

Received on Friday, 25 March 2016 20:10:56 UTC