[csswg-drafts] [css-mediaqueries-5] nav-controls future proofing concerns (should each control have its own feature?) (#6785)

mgiuca has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-mediaqueries-5] nav-controls future proofing concerns (should each control have its own feature?) ==
Follow-up to #4187 (adding `nav-controls` media feature).

Draft spec text: https://drafts.csswg.org/mediaqueries-5/#nav-controls

This feature seems to work when the only queryable feature is `"back"`, but I don't see how this can be expanded in the future to support querying new features. As an example, in #4187 @grorg suggested a future ability to query for a user-agent-supplied Share button.

With only two values, `none` and `back`, we can clearly distinguish between these two cases. But say we added `share`; how would we distinguish the four cases of "none", "back only", "share only" and "back and share"? I don't believe MQ features can have multiple values (i.e. it's not possible for the UA to set `nav-controls` to {`back`, `share`}, and have the queries `@media (nav-controls: back)` or `@media (nav-controls: share)` both succeed). So, how would we ever add a new queryable control?

_(Please forgive my ignorance if this is actually possible, in which case this issue can be closed.)_

This is touched on by a green box in the spec text, but I don't think the answer is entirely satisfying:

> Note: Theoretically, the two are not strictly equivalent, as there could be new values in a future extension of this media feature other than ['back'](https://drafts.csswg.org/mediaqueries-5/#valdef-media-nav-controls-back) that could match when 'back' doesn’t. In that case, using the ['nav-controls'](https://drafts.csswg.org/mediaqueries-5/#descdef-media-nav-controls) feature in a boolean context could be misleading. However, given that navigation back is arguably the most fundamental navigation operation, the CSS Working Group does not anticipate user interfaces with explicit navigation controls but no back button, so this problem is not expected to occur in practice.

This is basically saying if we add a new control, say, `share`, then:

- `back` would mean "back only"
- `share` would mean "back and share"
- there would be no provision for a "share only" UI, per the above assumption

There are two problems with this:

1. It has a built-in footgun of `@media (nav-controls: back)`. Adding a new control like `share` will immediately break any sites which are (against the advice of the green box) using this query.
2. It can only be extended with one more control. Say we want to add a third control, like `forward`, and assume a back button is always present if there are any controls at all. How will user agents communicate to sites the difference between "back and share", "back and forward" and "back, forward and share"?

Since the intended usage of this is to consider each control in isolation (e.g. hide the in-page back button if the UA provides one, hide the in-page share button if the UA provides one, etc), why not simply provide a separate media feature for each control, with a common prefix?

This implies that instead of `nav-controls`: `none` | `back`, we should have `nav-controls-back`: `<mq-boolean>`. Any new controls would get their own feature, e.g. `nav-controls-share`: `<mq-boolean>`.

Thus the usage changes to
```css
@media (nav-controls-back) {
  #back-button {
    display: none;
  }
}
```

which is easier to read than `@media (nav-controls)` because it's explicit about the fact that we're looking for a back button (noting that `@media (nav-controls: back)` in the current draft is also explicit, but wrong).

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6785 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 1 November 2021 02:30:30 UTC