Re: [mediaqueries] hover: on-demand

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

 - Florian

Received on Wednesday, 10 February 2016 03:57:58 UTC