Attribute-based Constraints For <usermedia>

[yashrajbharti]

Summary

For <usermedia> implementations a concise, attribute-based syntax might be better suited for some use cases. The goal is to better surface user intent at the HTML layer, while preserving the existing script-based constraints as an escape hatch.

---

Motivation

PEPC optimizes for clear, declarative user intent. Requiring embedded JSON scripts for camera/microphone controls:

• Obscures intent in otherwise semantic HTML
• Reduces readability and diffability
• Adds CSP and tooling friction

Most real-world use cases only need coarse, predictable constraints that map to attributes.

Also, the following may not be the most readable semantics.

<usermedia>
<script type="permissionconstraints">
  {
    "video": {
      "width": { "min": 640, "ideal": 1920, "max": 1920 },
      "height": { "min": 400, "ideal": 1080 },
      "aspectRatio": 1.777777778,
      "frameRate": { "max": 30 }
    }
  }
</script>
</usermedia>

---

Proposed syntax

Minimal usage

<usermedia audio></usermedia>
<usermedia video></usermedia>
<usermedia audio video></usermedia>

Equivalent to:

{ audio: true }
{ video: true }
{ audio: true, video: true }

---

Constraint refinement via prefixed attributes

<usermedia
  video
  video-width="1920"
  video-height="1080"
  video-framerate-max="30">
</usermedia>

Maps to:

{
  video: {
    width: { ideal: 1920 },
    height: { ideal: 1080 },
    frameRate: { max: 30 }
  }
}

<usermedia
  audio
  audio-channel-count="2"
  audio-sample-size="16">
</usermedia>

Rules:

• audio / video attributes express requested capabilities
• audio-* and video-* attributes refine constraints
• Prefixed attributes without the base capability are invalid

---

Autostart (unchanged)

<usermedia audio video autostart></usermedia>

---

Escape hatch for advanced constraints

For less common or advanced cases, allow a single JSON attribute:

<usermedia constraints='{ "video": { "aspectRatio": 1.777 } }'></usermedia>

If present, constraints overrides all derived attributes.

---

Parsing model (high level)

1. If constraints attribute is present, parse and use it

2. Otherwise:

   • Initialize audio and/or video based on presence of attributes

3. Apply audio-* and video-* refinements

4. If neither audio nor video is present, the element is invalid

---

Why this fits PEPC

• Attributes express intent, scripts express behavior
• HTML-first, declarative, and inspectable
• Better tooling, accessibility, and CSP characteristics

This is a layering improvement, not a replacement.

[tomayac]

One possible thing to watch out for is possible interference with the Custom Attributes proposal. So effectively this would mean you'd have to remove the - from all of your attributes to stay clear of that.

[jan-ivar]

Thanks @yashrajbharti, I fully share your concerns with <script type="permissionconstraints">.

But the proposal looks like option 5 which I believe was previously considered?

I'd prefer we move away from constraints. They're a complexity mistake the WebRTC WG has been working to curb the spread of for years. See w3c/mediacapture-main#695, w3c/mediacapture-main#455, w3c/mediacapture-main#707

For some of the declarative benefits you seek, last WebRTC WG meeting, I showed declaring the types without overloading constraints (there were no objections registered, only concern over MVP):

<microphone></microphone>
<camera></camera>
<usermedia></usermedia>

The follows the design principle § 3.7. Give each HTML element a single purpose, and avoids the <input type=> mistake.

I also proposed these minimal constraints methods that are optional to call (no true/false, no advanced constraints):

microphone.setConstraints(audioConstraints);
camera.setConstraints(videoConstraints);
usermedia.setConstraints({video: videoConstraints, audio: audioConstraints})

I believe these should suffice, as

• I'm not aware of any non-JS use cases for camera and microphone
• Calling them on pageload seems fine and in plenty of time for getUserMedia
• Avoids confusion over whether html attributes are "live" (btn.setConstraints() != track.applyConstraints())