Possible duplication of requirements

[annevk]

Under DisplayMediaStreamConstraints it states that video being false MUST be rejected. Unless I'm missing something this is already required as part of getDisplayMedia(). And the latter is a much better style as the order relative to other rejections is clear.

[eladalon1983]

Thought - what if we specified things in such a way that {video: false} weren't even possible?

So instead of:

(boolean or MediaTrackConstraints) video = true;

Have:

MediaTrackConstraints video = {};

We could accept video = true for a few releases and issue a warning, then deprecate.
(Note that the empty dictionary evaluates as true. If only true also auto-converted to the empty dictionary... 😄)

[eladalon1983]

This currently reads:

video of type (boolean or MediaTrackConstraints), defaulting to true
---
If true, it requests that the returned MediaStream contain a video track.
If a Constraints structure is provided, it further specifies desired processing
options to be applied to the video track rendition of the display surface chosen
by the user.
If false, the request MUST be rejected with a TypeError.

If we remove "If false, the request MUST be rejected with a TypeError" we end up with text that addresses 2 out of 3 possible values. Are we sure this is an improvement? Or is the suggestion to replace MUST with "must," lowercase?

[annevk]

It needs to be an informal description without implementation requirements. Lowercasing must does not help with that, it would still be duplicating a requirement.