recursal/MDN huggingface dataset:
MediaTrackConstraints: groupId property
=======================================

 The `MediaTrackConstraints` dictionary's
 **`groupId`** property is a `ConstrainDOMString`
 describing the requested or mandatory constraints placed upon the value of the
 `groupId` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.groupId` as returned by a call
 to `MediaDevices.getSupportedConstraints()`. However, typically this is
 unnecessary since browsers will ignore any constraints they're unfamiliar with.

Value
-----

 An object based on `ConstrainDOMString` specifying one or more acceptable,
 ideal, and/or exact (mandatory) group IDs which are acceptable as the source of media
 content.

 Group IDs are unique for a given origin for the duration of a single browsing session,
 and are shared by all media sources that come from the same physical device. For
 example, the microphone and speaker on the same headset would share a group ID. This
 makes it possible to use the group ID to ensure that the audio and input devices are on
 the same headset by retrieving the group ID of the input device and specifying it when
 asking for an output device, perhaps.

 However, the value of the `groupId` is determined by the source of the
 track's content, and there's no particular format mandated by the specification
 (although some kind of GUID is recommended). That means that a given track will only
 return one value for the `groupId` when you call
 `getCapabilities()`, and keep in mind
 that this value will change for each browsing session.

 Because of this, there's no use for the group ID when calling
 `MediaStreamTrack.applyConstraints()`, since there is only one possible
 value, and you can't use it to ensure the same group is used across multiple browsing
 sessions when calling `getUserMedia()`.

Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-groupid |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
MediaTrackConstraints: deviceId property
========================================

 The `MediaTrackConstraints` dictionary's
 **`deviceId`** property is a `ConstrainDOMString`
 describing the requested or mandatory constraints placed upon the value of the
 `deviceId` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.deviceId` as returned by a
 call to `MediaDevices.getSupportedConstraints()`. However, typically this
 is unnecessary since browsers will ignore any constraints they're unfamiliar with.

 Because RTP doesn't include this information, tracks associated with a
 WebRTC `RTCPeerConnection`
 will never include this property.

Value
-----

 An object based on `ConstrainDOMString` specifying one or more acceptable,
 ideal, and/or exact (mandatory) device IDs which are acceptable as the source of media
 content.

 Device IDs are unique for a given origin, and are guaranteed to be the same across
 browsing sessions on the same origin. However, the value of the `deviceId` is
 determined by the source of the track's content, and there's no particular format
 mandated by the specification (although some kind of GUID is recommended). That means
 that a given track will only return one value for the `deviceId` when you
 call `getCapabilities()`.

 Because of this, there's no use for the device ID when calling
 `MediaStreamTrack.applyConstraints()`, since there is only one possible
 value; however, you can record a `deviceId` and use it to ensure that you get
 the same source for multiple calls to `getUserMedia()`.


**Note:** An exception to the rule that device IDs are the same across browsing sessions:
 private browsing mode will use a different ID, and will change it each browsing
 session.


Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-deviceid |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
MediaTrackConstraints: echoCancellation property
================================================

 The `MediaTrackConstraints` dictionary's
 **`echoCancellation`** property is a
 `ConstrainBoolean` describing the requested or mandatory constraints placed
 upon the value of the `echoCancellation` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.echoCancellation` as returned
 by a call to `MediaDevices.getSupportedConstraints()`. However, typically
 this is unnecessary since browsers will ignore any constraints they're unfamiliar with.

 Because RTP doesn't include this information, tracks associated with a
 WebRTC `RTCPeerConnection`
 will never include this property.

Value
-----

 If this value is a simple `true` or `false`, the user agent will
 attempt to obtain media with echo cancellation enabled or disabled as specified, if
 possible, but will not fail if this can't be done. If, instead, the value is given as an
 object with an `exact` field, that field's Boolean value indicates a required
 setting for the echo cancellation feature; if it can't be met, then the request will
 result in an error.

Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-echocancellation |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
MediaTrackConstraints: channelCount property
============================================

 The `MediaTrackConstraints` dictionary's
 **`channelCount`** property is a `ConstrainULong`
 describing the requested or mandatory constraints placed upon the value of the
 `channelCount` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.channelCount` as returned by a
 call to `MediaDevices.getSupportedConstraints()`. However, typically this
 is unnecessary since browsers will ignore any constraints they're unfamiliar with.

Value
-----

 If this value is a number, the user agent will attempt to obtain media whose channel
 count is as close as possible to this number given the capabilities of the hardware and
 the other constraints specified. Otherwise, the value of this
 `ConstrainULong` will guide the user agent in its efforts to provide an
 exact match to the required channel count (if `exact` is specified or both
 `min` and `max` are provided and have the same value) or to a
 best-possible value.

The channel count is 1 for monaural sound, 2 for stereo, and so forth.

Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-channelcount |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
MediaTrackConstraints: width property
=====================================

 The `MediaTrackConstraints` dictionary's
 **`width`** property is a `ConstrainULong`
 describing the requested or mandatory constraints placed upon the value of the
 `width` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.width` as returned by a call
 to `MediaDevices.getSupportedConstraints()`. However, typically this is
 unnecessary since browsers will ignore any constraints they're unfamiliar with.

Value
-----

 If this value is a number, the user agent will attempt to obtain media whose width is
 as close as possible to this number given the capabilities of the hardware and the other
 constraints specified. Otherwise, the value of this `ConstrainULong` will
 guide the user agent in its efforts to provide an exact match to the required width (if
 `exact` is specified or both `min` and `max` are
 provided and have the same value) or to a best-possible value.

Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-width |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
MediaTrackConstraints: sampleSize property
==========================================

 The `MediaTrackConstraints` dictionary's
 **`sampleSize`** property is a `ConstrainULong`
 describing the requested or mandatory constraints placed upon the value of the
 `sampleSize` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.sampleSize` as returned by a
 call to `MediaDevices.getSupportedConstraints()`. However, typically this
 is unnecessary since browsers will ignore any constraints they're unfamiliar with.

Value
-----

 If this value is a number, the user agent will attempt to obtain media whose sample
 size (in bits per linear sample) is as close as possible to this number given the
 capabilities of the hardware and the other constraints specified. Otherwise, the value
 of this `ConstrainULong` will guide the user agent in its efforts to provide
 an exact match to the required sample size (if `exact` is specified or both
 `min` and `max` are provided and have the same value) or to a
 best-possible value.


**Note:** Since this property can only represent linear sample sizes, this constraint can only
 be met by devices that can produce audio with linear samples.


Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-samplesize |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
MediaTrackConstraints: facingMode property
==========================================

 The `MediaTrackConstraints` dictionary's
 **`facingMode`** property is a `ConstrainDOMString`
 describing the requested or mandatory constraints placed upon the value of the
 `facingMode` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.facingMode` as returned by a
 call to `MediaDevices.getSupportedConstraints()`. However, typically this
 is unnecessary since browsers will ignore any constraints they're unfamiliar with.

 Because RTP doesn't include this information, tracks associated with a
 WebRTC `RTCPeerConnection`
 will never include this property.

Value
-----

 An object based on `ConstrainDOMString` specifying one or more acceptable,
 ideal, and/or exact (mandatory) facing modes are acceptable for a video track.

 An `exact` value in this case indicates that the specified facing mode is
 specifically required; for example:


```js
const constraints = {
  facingMode: { exact: "user" },
};
```


 This indicates that only a user-facing camera is acceptable; if there is no user-facing
 camera, or the user declines permission to use that camera, the media request will fail.

 The following strings are permitted values for the facing mode. These may represent
 separate cameras, or they may represent directions in which an adjustable camera can be
 pointed.

`"user"`

 The video source is facing toward the user; this includes, for example, the
 front-facing camera on a smartphone.


`"environment"`

 The video source is facing away from the user, thereby viewing their environment.
 This is the back camera on a smartphone.


`"left"`

 The video source is facing toward the user but to their left, such as a camera aimed
 toward the user but over their left shoulder.


`"right"`

 The video source is facing toward the user but to their right, such as a camera
 aimed toward the user but over their right shoulder.


Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-facingmode |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
MediaTrackConstraints: aspectRatio property
===========================================

 The `MediaTrackConstraints` dictionary's **`aspectRatio`** property is a `ConstrainDouble` describing the requested or mandatory constraints placed upon the value of the
 `aspectRatio` constrainable property.

 If needed, you can determine whether or not this constraint is supported by checking
 the value of `MediaTrackSupportedConstraints.aspectRatio` as returned by a
 call to `MediaDevices.getSupportedConstraints()`. However, typically this
 is unnecessary since browsers will ignore any constraints they're unfamiliar with.

Value
-----

 A `ConstrainDouble` describing the acceptable or required value(s) for a
 video track's aspect ratio. The value is the width divided by the height and is rounded
 to ten decimal places. For example, the standard high-definition video aspect ratio of
 16:9 can be computed as 1920/1080, or 1.7777777778.

 If this value is a number, the user agent will attempt to obtain media whose aspect
 ratio is as close as possible to this number given the capabilities of the hardware and
 the other constraints specified. Otherwise, the value of this
 `ConstrainDouble` will guide the user agent in its efforts to provide an
 exact match to the required aspect ratio (if `exact` is specified or both
 `min` and `max` are provided and have the same value) or to a
 best-possible value.

Examples
--------

See the Constraint exerciser example.

Specifications
--------------

| Specification |
| --- |
| Media Capture and Streams # dom-mediatrackconstraintset-aspectratio |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Media Capture and Streams API
* Capabilities, constraints, and settings
* `MediaTrackConstraints`
* `MediaDevices.getSupportedConstraints()`
* `MediaTrackSupportedConstraints`
* `MediaStreamTrack`
CSSSkewX: ax property
=====================

 The **`ax`** property of the
 `CSSSkewX` interface gets and sets the angle used to distort the element
 along the x-axis (or abscissa).

Value
-----

A `CSSNumericValue`.

Examples
--------

To do

Specifications
--------------

| Specification |
| --- |
| CSS Typed OM Level 1 # dom-cssskewx-ax |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
CSSSkewX: CSSSkewX() constructor
================================

 The **`CSSSkewX()`** constructor creates a new
 `CSSSkewX` object which represents the
 `skewX()`
 value of the individual `transform` property in CSS.

Syntax
------


```js
new CSSSkewX(ax)
```

### Parameters

`ax`

 A value for the `ax` angle of the `CSSSkewX` object to be
 constructed. This must be a `CSSNumericValue`.


Examples
--------

To do

Specifications
--------------

| Specification |
| --- |
| CSS Typed OM Level 1 # dom-cssskewx-cssskewx |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
ServiceWorker: error event
==========================

The `error` event fires whenever an error occurs in the service worker.

Syntax
------

Use the event name in methods like `addEventListener()`, or set an event handler property.


```js
addEventListener("error", (event) => {});

onerror = (event) => {};
```

Event type
----------

A generic `Event`.

Example
-------

The following code snippet gets a handle to the `ServiceWorker` object via `ServiceWorkerRegistration.active` and sets up an `onerror` handler on the resulting object:


```js
// in the page being controlled
if (navigator.serviceWorker) {
  navigator.serviceWorker.register("service-worker.js");

  navigator.serviceWorker.ready.then((registration) => {
    registration.active.onerror = (event) => {
      console.log("An error occurred in the service worker!");
    };
  });
}
```

Specifications
--------------

| Specification |
| --- |
| HTML Standard # handler-abstractworker-onerror |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
ServiceWorker: statechange event
================================

The `statechange` event fires anytime the `ServiceWorker.state` changes.

Syntax
------

Use the event name in methods like `addEventListener()`, or set an event handler property.


```js
addEventListener("statechange", (event) => {});

onstatechange = (event) => {};
```

Event type
----------

A generic `Event`.

Examples
--------

 This code snippet is from the service worker registration-events sample (live demo). The code listens for any change in the `ServiceWorker.state`
 and returns its value.


```js
let serviceWorker;
if (registration.installing) {
  serviceWorker = registration.installing;
  document.querySelector("#kind").textContent = "installing";
} else if (registration.waiting) {
  serviceWorker = registration.waiting;
  document.querySelector("#kind").textContent = "waiting";
} else if (registration.active) {
  serviceWorker = registration.active;
  document.querySelector("#kind").textContent = "active";
}

if (serviceWorker) {
  logState(serviceWorker.state);
  serviceWorker.addEventListener("statechange", (e) => {
    logState(e.target.state);
  });
}
```


 Note that when `statechange` fires, the service worker's references may have
 changed. For example:


```js
navigator.serviceWorker.register("/sw.js").then((swr) => {
  swr.installing.state = "installing";
  swr.installing.onstatechange = () => {
    swr.installing = null;
    // At this point, swr.waiting OR swr.active might be true. This is because the statechange
    // event gets queued, meanwhile the underlying worker may have gone into the waiting
    // state and will be immediately activated if possible.
  };
});
```

Specifications
--------------

| Specification |
| --- |
| Service Workers # dom-serviceworker-onstatechange |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
ServiceWorker: scriptURL property
=================================

 Returns the `ServiceWorker` serialized script URL defined as part of `ServiceWorkerRegistration`.
 Must be on the same origin as the document that registers the
 `ServiceWorker`.

Value
-----

A string.

Examples
--------


```js
const sw = navigator.serviceWorker.controller;
console.log(sw.scriptURL);
// https://example.com/scripts/service-worker.js
```

Specifications
--------------

| Specification |
| --- |
| Service Workers # service-worker-url |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
ServiceWorker: state property
=============================

 The **`state`** read-only property of the
 `ServiceWorker` interface returns a string representing the current state
 of the service worker. It can be one of the following values: `parsed`, `installing`,
 `installed`, `activating`, `activated`, or
 `redundant`.

Value
-----

A `String` that can take one of the following values:

`"parsed"`

 The initial state of a service worker after it is downloaded and confirmed to be runnable.
 A service worker is never updated to this state, so this will never be the value of the `ServiceWorker.statechange_event`

`"installing"`

The service worker in this state is considered an installing worker. During this state, `ExtendableEvent.waitUntil()` can be called inside the `install` event handler to extend the life of the installing worker until the passed promise resolves successfully. This is primarily used to ensure that the service worker is not active until all of the core caches are populated.

`"installed"`

The service worker in this state is considered a waiting worker.

`"activating"`

The service worker in this state is considered an active worker. During this state, `ExtendableEvent.waitUntil()` can be called inside the `onactivate` event handler to extend the life of the active worker until the passed promise resolves successfully. No functional events are dispatched until the state becomes activated.

`"activated"`

The service worker in this state is considered an active worker ready to handle functional events.

`"redundant"`

A new service worker is replacing the current service worker, or the current service worker is being discarded due to an install failure.

Examples
--------

 This code snippet is from the service worker registration-events sample (live demo). The code listens for any change in the `ServiceWorker.state`
 and returns its value.


```js
let serviceWorker;
if (registration.installing) {
  serviceWorker = registration.installing;
  document.querySelector("#kind").textContent = "installing";
} else if (registration.waiting) {
  serviceWorker = registration.waiting;
  document.querySelector("#kind").textContent = "waiting";
} else if (registration.active) {
  serviceWorker = registration.active;
  document.querySelector("#kind").textContent = "active";
}

if (serviceWorker) {
  logState(serviceWorker.state);
  serviceWorker.addEventListener("statechange", (e) => {
    logState(e.target.state);
  });
}
```

Specifications
--------------

| Specification |
| --- |
| Service Workers # service-worker-state |

Browser compatibility
---------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.