Pass kind into algorithms that rely on it. #1831
Conversation
| @@ -5495,7 +5497,8 @@ <h3><dfn>RTCRtpSender</dfn> Interface</h3> | |||
| changed appropriately.</p> | |||
|
|
|||
| <p>To <dfn>create an RTCRtpSender</dfn> with a | |||
| <code><a>MediaStreamTrack</a></code>, <var>track</var>, a list of | |||
| <code><a>MediaStreamTrack</a></code>, <var>track</var>, a string, | |||
| <var>kind</var>, a list of | |||
There was a problem hiding this comment.
the language "a string, kind" reads oddly to me. it's kind of the verbal equivalent of
function createRtcRtpSender(DOMString kind, .....)
but emphasizing the stringiness seems weird to me. Not going to object too much, though.
There was a problem hiding this comment.
I prefer to not list types at all (we're inconsistent throughout the spec). But if we're going to list types then kind is not a type, its type is string, and we are listing types here.
There was a problem hiding this comment.
"...and optionally an id string, id" was already there. Should I remove the types altogether?
There was a problem hiding this comment.
I'm happy with leaving the types out for these non-formal interfaces.
(the reason why audio/video isn't an enum is an artifact of WebIDL's treatment of enums and extensibility, not because we didn't want it to be, I think.)
| @@ -6559,7 +6562,7 @@ <h2>Dictionary <code><a>RTCRtpHeaderExtensionCapability</a></code> Members</h2> | |||
| <h3><dfn>RTCRtpReceiver</dfn> Interface</h3> | |||
| <p>The <code>RTCRtpReceiver</code> interface allows an application to | |||
| inspect the receipt of a <code>MediaStreamTrack</code>.</p> | |||
| <p>To <dfn>create an RTCRtpReceiver</dfn> with kind, <var>kind</var>, and | |||
There was a problem hiding this comment.
My comment was in reference to this line, which used kind as both type and name.
Fix for #1830.
Preview | Diff