[css-mediaqueries-5] nav-controls: Clarify use in a boolean context (closes #7288)

[mgiuca]

[css-mediaqueries-5] nav-controls: Clarify use in a boolean context (closes #7288)

Non-normative change: Remove the example of using nav-controls in a boolean
context and somewhat confusing note explaining its usage. Replaced with a note
explaining why it is not recommended that sites use nav-controls in a boolean
context.

[frivoal]

@tabatkins What do you think? I'm sympathetic to this viewpoint, yet I am hesitant to promote more verbose syntax in prevention of a theoretically valid but practically unlikely risk…

[mgiuca]

more verbose syntax

We're talking about the difference between nav-controls and nav-controls: back. As a site developer, this seems like an easy trade-off to make: 6 more characters to say what you mean, instead of baking a generally-but-not-necessarily-true assumption into your code.

theoretically valid but practically unlikely

Until we have a second control, this isn't a normative issue. However, let's consider the future. I think there are two directions this could go (normatively) when we do add another control (e.g. share):

1. User agents are free to have share controls without a back button. Therefore, from today, sites should never use nav-controls in a Boolean context (it is fairly meaningless, since it doesn't imply the existence of any particular control). Instead, they should always write @media (nav-controls: back), and it is misleading to suggest otherwise.
2. nav-controls always implies the presence of a back button. Therefore, it is valid to write @media (nav-controls) to mean "if there is a back button". In this case, that implicit assumption will need to be made explicit if we ever add a new control; for example, if we add share, it will need to be normatively specified as "The user agent provides navigation controls, including at least a back button and a share button." (There should be a non-normative note stating that all future values will explicitly specify the inclusion of the back button as well.)

If we're not comfortable committing to having all future controls explicitly including the back button (2), then we should choose 1. I don't think it makes sense to sit on the fence here and say "user agents can have a share button without a back button, but we encourage developers to write code that assumes they won't."

I would prefer 1 because it allows us to give developers the ability to control (via manifest hints) which controls appear. It is perfectly reasonable to want a site that has a share button but not a back button, even if that is unlikely to be the default UA behaviour.

(Ultimately, the non-normative text in the spec doesn't really matter. What matters is what tutorials do and what developers generally write. I can't find any tutorials about this feature at the moment. The reason I'm spending energy debating here is because I suspect when tutorials do come along, they will copy the advice from the spec, and then developers will copy the code from tutorials.)

[mgiuca]

This didn't get a lot of traction, possibly because there was no open bug linked to it.

I've filed a new bug: #7288.