- From: Greg Whitworth <gwhit@microsoft.com>
- Date: Wed, 23 Mar 2016 04:07:10 +0000
- To: Florian Rivoal <florian@rivoal.net>, Tab Atkins Jr. <jackalmage@gmail.com>
- CC: fantasai <fantasai.lists@inkedblade.net>, "www-style@w3.org" <www-style@w3.org>
> > 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 Wednesday, 23 March 2016 04:08:11 UTC