- From: Matt Giuca via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Sep 2019 01:43:56 +0000
- To: public-css-archive@w3.org
Thanks CSSWG for discussing it. A few comments on this: @grorg : > I don't like the idea of "button". You're really talking about navigation functionality. That could be a swipe, glance, keyboard command, etc. To some level of exposure, which might not be obvious. Actually, I think this is more useful if it does focus on the presence of an actual visible button, or to generalize that slightly, an "obvious user-agent-supplied control for navigating back", as opposed to a "hidden" control such as a swipe gesture or keyboard shortcut. Because the intention of this query is that it's used to show or hide a highly-visible in-page control for navigation, you want to *show* the in-app control if there is no other obvious mechanism for navigation (even if there is a hidden one), but *hide* it if there is another obvious mechanism already present. To make this concrete: in Chrome PWA windows, we currently do not show the back button anywhere in the window controls, but we _do_ allow back navigation using the Alt+Left keyboard shortcut. Since Alt+Left is fairly undiscoverable, we often receive reports that there is no way to navigate back (even though, technically there is). In these cases, we want sites to be given the signal _to show_ their in-app navigation control, to provide an obvious mechanism to the user. Basically, the spec language doesn't need to explicitly mention a "button", but it should distinguish between obvious vs non-obvious mechanisms. @grorg : > It should not be restricted to back button. Knowing if a share button is present is also valuable (and would potentially avoid a lot of content embedded in the page). Similarly, this would be good but only if it was an obvious mechanism. On Chrome, we currently have user-agent-supplied Share functionality but it's hidden in an overflow menu. Arguably the entire utility of the Web Share API is giving sites the ability to put an easily discoverable Share button in their site, as opposed to being hidden away on an overflow menu. But if a PWA window had a big share button right in the title bar, arguably you wouldn't need to put a Web Share button in your site; just rely on the discoverability of the obvious share button. So ideally, the media query would return "true" if there's an obvious share button in the title bar, but "false" if there's only a share button hidden away in a menu. Ultimately, it would be at the discretion of the user agent to determine what "obvious" and "non-obvious" means, but the spec should give some examples (gestures, keyboard shortcuts and functionality inside drop-down menus would be "non-obvious"). > astearns: We should also get in touch with the original proposer (fallaciousreasoning) for giving credit. Please credit me (mgiuca@ / Matt Giuca) too :) Since I was the [original original proposer](https://github.com/w3c/manifest/issues/693); @fallaciousreasoning converted it into a formal proposal to the CSSWG. -- GitHub Notification of comment by mgiuca Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4187#issuecomment-528159548 using your GitHub account
Received on Thursday, 5 September 2019 01:43:58 UTC