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/>

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

    video: {}

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

    video: {
      facingMode: { exact: "blah" },

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

    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 {
    "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