search

w3c / mst-content-hint

This is the specification for the content-hint attribute. This optional hint permits MediaStreamTrack consumers such as PeerConnection or MediaRecorder to encode or process track media with methods more appropriate to the type of content that is being consumed.
https://w3c.github.io/mst-content-hint/
Other
4 stars 14 forks source link

Decide on how the setter should respond to invalid values #4

Closed domenic closed 7 years ago

domenic commented 7 years ago

Per https://heycam.github.io/webidl/#dfn-attribute-setter (step 4), enumeration types ignore attempts to set them to invalid values. They just leave the previous value in place. If we want to be consistent with enumeration types, we'd want to use this behavior. So your algorithm for the setter (#2) would just bail out if it sees an incorrect value.

If we think this is bad behavior, we should consider two possibilities:

  1. Make it throw an error. (Maybe TypeError, maybe something else like InvalidModificationError.) This will feel a bit inconsistent with the rest of the platform, but we can maybe squint a bit and convince ourselves that this is not an enumeration, it's something different.
  2. Consider a slightly different API. E.g. making mediaContentTypeHint only have a getter, then adding a seperate setter function setMediaContentTypeHint() that throws, or trySetMediaContentTypeHint() that returns a boolean and resets it to null, or similar.

Notably I don't think it'd be OK to make it reset to null upon encountering an invalid value. That would be just too surprising.

pbos commented 7 years ago

Using this "as enums" when spec's updated with new values, say X means that users that would like to fall back to "" as default have to do either:

Enum: foo.hint = X; if (foo.hint != X) foo.hint = "";

Or possibly, if this is possible? if ((foo.hint = X) != X) foo.hint = "";

TypeError: try { foo.hint = X; } catch(TypeError) { foo.hint = ""; }

I'm not sure which one I like best. Eew to both. :(

Maybe go with enums since they have presedence and both seem to generate about equally-ugly code?

domenic commented 7 years ago

That makes sense to me. However, I want to understand your scenario a bit more. I think as-enums gives good behavior in reality. Consider wanting to set it to "animation" in browsers that support that, and fall back to "fluid" in other browsers. I think you'd do:

track.mediaContentTypeHint = "fluid";
track.mediaContentTypeHint = "animation";

and everything would work perfectly. I don't understand in what scenario you'd write the explicit-test-and-set-to-empty-string code.

pbos commented 7 years ago

I guess the other scenario would be if track is stale and is:

track.mediaContentTypeHint = "inappropriateForAnimation"; // Old value from before, worse than "" // ... track.mediaContentTypeHint = "animation";

But setting them in order of what you want makes sense to me too, then you get the most appropriate value. Act-as-enum sounds good to me then (with different values depending on .kind == "audio"/"video").