[mediaqueries-5] New interaction media-feature: navigation #2494
Conversation
| would match | ||
| <code highlight=css>@media (pointer) { … }</code> | ||
| as well as | ||
| <code highlight=css>@media not (navigation) { … }</code>. |
There was a problem hiding this comment.
I can imagine the iOS guys implementing this in a way where the navigation boolean changes when the software keyboard is brought up/down. Just wanted to bring this up, in that I tab around form inputs all the time in my smartphone browser.
There was a problem hiding this comment.
Because I already hate when something like @media (min-height: 20em) {...} swaps back and forth when the software keyboard comes up/down.
There was a problem hiding this comment.
How about clarifying that if there's a Tab key on a software keyboard, @media (navigation:sequential) is expected to match, even if the keyboard is not always visible?
The MQ is not about how convenient to access the Tab key is, just about whether it's there.
There was a problem hiding this comment.
I'm only nitpicking from a desire to see this feature land as useful as possible.
I'm guessing the primary example provided for not matching sequential is less the rule and more the exception if most TV (or touch) OS browsers have software keyboards, even if only accessible when focusing opens an OSK that has a tab key?
|
@frivoal looks like we've missed this for several meetings (I've only looked at issues with the Agenda tags, never PRs). If you still want to suggest this change, could you manually add the item to the wiki agenda? |
|
I am no longer pursuing this. Closing. |
This introduces a new media feature, which complements the interaction media features
pointerandhoverintroduced in Media Queries Level 4.This new one,
navigationone gives authors insights into an additional aspect of the input systems available to the user: the ability to navigate sequentially (aka tab based navigation) or spatially (arrow-key based navigation).