W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

[Bug 19936] consider allowing non-matching enums to be converted to a particular value

From: <bugzilla@jessica.w3.org>
Date: Thu, 11 Sep 2014 05:54:16 +0000
To: public-script-coord@w3.org
Message-ID: <bug-19936-3890-s2zUYpC7xl@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19936

--- Comment #9 from Jan-Ivar Bruaroey [:jib] <jib@mozilla.com> ---
"None of the above" is not the same as "not present". For example:

  navigator.getUserMedia({
    video: {}
  })

means "unconstrained", give me any camera, I don't care which way it faces. But

  navigator.getUserMedia({
    video: {
      facingMode: { exact: "blah" },
    }
  })

must NOT succeed, because the caller is requiring a direction known to them but
unknown to the (old) browser. Likewise:

  navigator.getUserMedia({
    video: {
      advanced: [
        { facingMode: "blah", aspectRatio: 16/9}, // multi-constraint
        { facingMode: "user"},                    // single constraint
      ]
    }
  })

is required to satisfy both "blah" and 16/9 or give up and move to the next
entry. In other words, if it doesn't know "blah" then it should not limit
user-facing cameras to 16/9.

Travis' suggestion doesn't have the this problem, or the problem with
sequences. We can define:

  enum VideoFacingModeEnum {
    "user",
    "environment",
    "left",
    "right"
    "other" = default
  };

and blah turns into facingMode: ["user", "other", "left"] just fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 11 September 2014 05:54:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC