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

[mgiuca]

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' that could match when 'back' doesn’t. In that case, using the '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

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

[SebastianZ]

@media allows to combine multiple queries via and and or and negate them via not. With those you can check for the different cases you mention.

"none" is covered by @media (nav-controls: none), "back only" by @media (nav-controls: back) and not (nav-controls: share), "share" by @media (nav-controls: share) and not (nav-controls: back) and "back and share" by @media (nav-controls: back) and (nav-controls: share).

Sebastian

[tabatkins]

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

That is indeed possible: any of an MQs values might be true or false, with no exclusivity implied.

@SebastianZ's comment correctly explains how to combine those to get the precise boolean conditions, if desired.

[mgiuca]

Fantastic, I did not realise MQs were essentially a bag of Booleans, as opposed to an enum.

Re-reading the text of that green box, I now understand what it means. But I had a totally different read of it. I think the last sentence is somewhat 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.

I thought you were advising people to use @media (nav-controls), but you're actually advising people to use @media (nav-controls: back) (but saying it probably doesn't matter).

I think this is probably bad advice. Regardless of whether the new features will generally come with a back button, @media (nav-controls) controlling the back button is semantically incorrect. Widespread usage of this on websites could mean that websites break in the unlikely but allowable scenario where the user agent shows another feature without a back button, creating a de facto standard where UAs effectively can't do that.

I would therefore propose two non-normative changes:

1. Remove the second (erroneous) example of using @media (nav-controls) to control a back button.
2. Replace the green box with some other explanatory text. e.g. "Note: This media feature can also be used in a boolean context, e.g. @media (nav-controls). However, as there could be new values in a future extension of this media feature other than 'back', use of the 'nav-controls' feature in a boolean context could cause the page to incorrectly interpret some other control as a "back" button, and its usage is therefore discouraged."

Reopening for discussion.

[mgiuca]

Uploaded PR #6795 enacting the above proposal.