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 04:42:25 +0000
To: public-script-coord@w3.org
Message-ID: <bug-19936-3890-cCW5g2r1QC@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19936

--- Comment #8 from Cameron McCormack <cam@mcc.id.au> ---
For HTMLCanvasElement.getContext, I'm thinking now that a DOMString expresses
the intent better: context names can be any string, and the defined behaviour
of getContext is to return null for a context type it doesn't support.

For HTMLInputElement.type (an IDL attribute "limited to only known values"),
assigning any string causes the content attribute to be given that value, but
getting its value will only the default value (or the empty string for some) if
the value of the content attribute is not valid.  The behaviour here seems a
bit different from HTMLCanvasElement.getContext.

For Navigator.getUserMedia, the facing mode value can be used either directly
as the value of dictionary members MediaTrackConstraintSet.facingMode and
ConstrainVideoFacingModeParameters.{exact,ideal} or in a sequence that is the
value of those dictionary members.

I was going to suggest something like:

  dictionary MediaTrackConstraintSet {
    ...
    [LenientEnum] ConstrainVideoFacingMode facingMode;
  };

which would make

  navigator.getUserMedia({
    video: {
      advanced: [
        {
          facingMode: "blah"
        }
      ]
    }
  })

treat the facingMode dictionary member as "not present" since it doesn't have a
matching value.

But this leads to the question of how to treat the values inside the
sequence<VideoFacingModeEnum>, e.g. if you write

  navigator.getUserMedia({
    video: {
      advanced: [
        {
          facingMode: ["user", "blah", "left"]
        }
      ]
    }
  })

or

  navigator.getUserMedia({
    video: {
      advanced: [
        {
          facingMode: {
            exact: ["user", "blah", "left"]
          }
        }
      ]
    }
  })

There's no concept of "not present" for sequence values, so prose is going to
have to handle the "blah" value.  I think it would be strange to allow the JS
Array -> sequence<VideoFacingModeEnum> conversion to skip invalid elements.

So this makes me think that all of this should be done with a DOMString and
handled in prose, actually.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 11 September 2014 04:42:26 UTC

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