recursal/MDN huggingface dataset:
XRSession: depthUsage property
==============================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The *read-only* **`depthUsage`** property of an `immersive-ar`
`XRSession` describes which depth-sensing usage is used.

Value
-----

This property can return the following values:

`cpu-optimized`

The depth data is intended to be used on the CPU; see the `XRCPUDepthInformation` interface.

`gpu-optimized`

The depth data is intended to be used on the GPU; see the `XRWebGLDepthInformation` interface.

Examples
--------

To request the desired usage method, you need to specify a `usagePreference` when requesting a session using `XRSystem.requestSession()`. Here, the caller is able to handle both CPU- and GPU-optimized usage. The order indicates preference for CPU:


```js
navigator.xr.requestSession("immersive-ar", {
  requiredFeatures: ["depth-sensing"],
  depthSensing: {
    usagePreference: ["cpu-optimized", "gpu-optimized"],
    formatPreference: ["luminance-alpha", "float32"],
  },
});
```


To check which usage was selected by the user agent, you can call the `depthUsage` property:


```js
console.log(session.depthUsage); // either "cpu-optimized" or "gpu-optimized"
```

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

| Specification |
| --- |
| WebXR Depth Sensing Module # dom-xrsession-depthusage |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The `XRSession` interface's *read-only* **`environmentBlendMode`**
 property identifies if, and to what degree, the computer-generated imagery is overlaid atop the real world.

 This is used to differentiate between fully-immersive VR sessions and AR sessions which render
 over a pass-through image of the real world, possibly partially transparently.

Value
-----

A string defining if and how virtual, rendered content is overlaid atop the image of the real world.

Possible values are:

`opaque`

The rendered image is drawn without allowing any pass-through imagery. This is primarily used by fully-immersive VR headsets, which totally obscure the surrounding environment, with none of the real world shown to the user at all. The alpha values specified in the `XRSession`'s `renderState` property's `baseLayer` field are ignored since the alpha values for the rendered imagery are all treated as being 1.0 (fully opaque).

`additive`

Primarily used by AR devices with transparent lenses which directly allow reality to pass through to the user's eyes, the `additive` blending mode is designed to be used in a situation in which the device has no control over the background and its brightness, since that isn't being digitally controlled. All the device can do is add more light to the image; it can't make things get darker. Therefore, black is rendered as fully transparent, and there's no way to make a pixel fully opaque. As with the `opaque` setting, alpha values specified are ignored and treated as if they were 1.0.

`alpha-blend`

 Used by headsets or goggles which use cameras to capture the real world and display it digitally on the screen or screens used to render the content for the user to see, this offers a way to create an AR presentation using a VR device. Alpha blending can also be used by non-wearable devices that provide AR modes, such as phones or tablets using cameras to capture the real world for use in AR apps. Since the real world is being digitally presented, the brightness of each pixel can be controlled, whether it's reality or the rendered XR image, the user's environment can be blended with the virtual environment with each pixel having its color and brightness precisely controlled.
 In this mode, the `XRSession`'s `renderState.baseLayer` property provides relative weights of the artificial layer during the compositing process. Pixels whose alpha value is 1.0 are rendered fully opaque, totally obscuring the real world, while pixels with an alpha of 0.0 are totally transparent, leaving the surrounding environment to pass through.


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

| Specification |
| --- |
| WebXR Augmented Reality Module - Level 1 # dom-xrsession-environmentblendmode |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

An `end` event is fired at an `XRSession` object when the WebXR session has ended, either because the web application has chosen to stop the session, or because the user agent terminated the session.

Syntax
------

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


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

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

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

An `XRSessionEvent`. Inherits from `Event`.

Event

XRSessionEventEvent properties
----------------

*In addition to the properties listed below, properties from the parent interface, `Event`, are available.*

`session` Read only 

The `XRSession` to which the event refers.

Description
-----------

### Trigger

Triggered when the WebXR session has ended, either because the web application has chosen to stop the session, or because the user agent terminated the session.

This event is not cancelable and does not bubble.

### Use cases

You can use this event to react to the ending of an WebXR session. You may want to display a UI element informing about the termination of the session, for example.

Examples
--------

To be informed when a WebXR session comes to an end, you can add a handler to your `XRSession` instance using `addEventListener()`, like this:


```js
XRSession.addEventListener("end", (event) => {
  /\* the session has shut down \*/
});
```


Alternatively, you can use the `XRSession.onend` event handler property to establish a handler for the `end` event:


```js
XRSession.onend = (event) => {
  /\* the session has shut down \*/
};
```

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

| Specification |
| --- |
| WebXR Device API # eventdef-xrsession-end |
| WebXR Device API # dom-xrsession-onend |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

 The *read-only* **`visibilityState`** property of the
 `XRSession` interface is a string indicating whether the WebXR content is
 currently visible to the user, and if it is, whether it's the primary focus.

 Every time the visibility state changes, a
 `visibilitychange` event is fired on the
 `XRSession` object.

Value
-----

 A string indicating whether or not the XR content is
 visible to the user and if it is, whether or not it's currently the primary focus.

The possible values of `visibilityState` are:

`hidden`

 The virtual scene generated by the `XRSession` is not currently visible to the user,
 so its `requestAnimationFrame()`
 callbacks are *not* being executed until the `visibilityState` changes.
 Input controllers are *not* being handled for the session.


`visible`

 The virtual scene rendered by the `XRSession` is currently visible to the user
 and is the primary focus of the user's attention. To that end, the session's
 `requestAnimationFrame()` callbacks are being processed
 at the XR device's native refresh rate and input controllers are being processed as normal.


`visible-blurred`

 While the virtual scene rendered by the `XRSession` may currently be visible to the user,
 it is not the user's primary focus at the moment; it's also possible the session is not currently visible at all.
 In order to optimize resource utilization, the user agent may be handling the session's
 `requestAnimationFrame()` callbacks at a throttled rate.
 Input controllers are *not* being processed for the session.


Usage notes
-----------

 It's important to keep in mind that because an immersive WebXR session is potentially
 being shown using a different display than the HTML document in which it's running (such
 as when being shown on a headset), the value of a
 session's `visibilityState` may not necessarily be the same as the owning
 *`document`'s* `visibilityState`. For instance, if the viewer is using a headset tethered to a
 computer and the immersive scene is obscured by a configuration UI, the user could peek
 out from behind the headset and still be able to see the document itself on their
 computer's monitor.

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

| Specification |
| --- |
| WebXR Device API # dom-xrsession-visibilitystate |

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

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

See also
--------

* `visibilitychange` event
DeprecationReportBody: id property
==================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`id`** read-only property of the `DeprecationReportBody` interface returns a string representing the feature or API that is deprecated. This can be used to group or count related reports.

Value
-----

A string.

Examples
--------

In this example we create a new `ReportingObserver` to observe deprecation reports, then print the value of `id` to the console.


```js
let options = {
  types: ["deprecation"],
  buffered: true,
};

let observer = new ReportingObserver((reports, observer) => {
  let firstReport = reports[0];
  console.log(firstReport.type); // deprecation
  console.log(firstReport.body.id);
}, options);
```

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

| Specification |
| --- |
| Deprecation Reporting # dom-deprecationreportbody-id |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`anticipatedRemoval`** read-only property of the `DeprecationReportBody` interface returns the date that the browser version which removes the feature will ship. This value can be used to prioritize warnings. If this property returns `null` because the date is unknown, then the deprecation should be considered low priority.

Value
-----

A `date` object, or `null` if the date is not known.

Examples
--------

In this example we create a new `ReportingObserver` to observe deprecation reports, then print the value of `anticipatedRemoval` to the console.


```js
let options = {
  types: ["deprecation"],
  buffered: true,
};

let observer = new ReportingObserver((reports, observer) => {
  let firstReport = reports[0];
  console.log(firstReport.type); // deprecation
  console.log(firstReport.body.anticipatedRemoval);
}, options);
```

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

| Specification |
| --- |
| Deprecation Reporting # dom-deprecationreportbody-anticipatedremoval |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`sourceFile`** read-only property of the `DeprecationReportBody` interface returns the path to the source file where the deprecated feature was used.

**Note:** This property can be used with `DeprecationReportBody.lineNumber` and `DeprecationReportBody.columnNumber` to locate the column and line in the file where the error occurred.

Value
-----

A string, or `null` if the path is not known.

Examples
--------

In this example we create a new `ReportingObserver` to observe deprecation reports, then print the value of `sourceFile` to the console.


```js
let options = {
  types: ["deprecation"],
  buffered: true,
};

let observer = new ReportingObserver((reports, observer) => {
  let firstReport = reports[0];
  console.log(firstReport.type); // deprecation
  console.log(firstReport.body.sourceFile);
}, options);
```

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

| Specification |
| --- |
| Deprecation Reporting # dom-deprecationreportbody-sourcefile |

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

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.
DeprecationReportBody: toJSON() method
======================================

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`toJSON()`** method of the `DeprecationReportBody` interface is a *serializer*, and returns a JSON representation of the `InterventionReportBody` object.

Syntax
------


```js
toJSON()
```

### Parameters

None.

### Return value

A JSON object that is the serialization of the `DeprecationReportBody` object.

Examples
--------

In this example we create a new `ReportingObserver` to observe deprecation reports, then return a JSON representation of the first entry.


```js
let options = {
  types: ["deprecation"],
  buffered: true,
};

let observer = new ReportingObserver((reports, observer) => {
  let firstReport = reports[0];
  console.log(firstReport.toJSON());
}, options);
```

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

| Specification |
| --- |
| Deprecation Reporting # dom-deprecationreportbody-tojson |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`message`** read-only property of the `DeprecationReportBody` interface returns a human-readable description of the deprecation. This typically matches the message a browser will display in its DevTools console regarding a deprecated feature.

Value
-----

A string.

Examples
--------

In this example we create a new `ReportingObserver` to observe deprecation reports, then print the value of `message` to the console.


```js
let options = {
  types: ["deprecation"],
  buffered: true,
};

let observer = new ReportingObserver((reports, observer) => {
  let firstReport = reports[0];
  console.log(firstReport.type); // deprecation
  console.log(firstReport.body.message);
}, options);
```

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

| Specification |
| --- |
| Deprecation Reporting # dom-deprecationreportbody-message |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`columnNumber`** read-only property of the `DeprecationReportBody` interface returns the line in the source file in which the deprecated feature was used.

**Note:** This property is most useful alongside `DeprecationReportBody.sourceFile` and `DeprecationReportBody.lineNumber` as it enables the location of the column in that file and line where the error occurred.

Value
-----

An integer, or `null` if the column is not known.

Examples
--------

In this example we create a new `ReportingObserver` to observe deprecation reports, then print the value of `columnNumber` to the console.


```js
let options = {
  types: ["deprecation"],
  buffered: true,
};

let observer = new ReportingObserver((reports, observer) => {
  let firstReport = reports[0];
  console.log(firstReport.type); // deprecation
  console.log(firstReport.body.sourceFile); // the source file
  console.log(firstReport.body.lineNumber); // the line in that file
  console.log(firstReport.body.columnNumber); // the column in that file.
}, options);
```

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

| Specification |
| --- |
| Deprecation Reporting # dom-deprecationreportbody-columnnumber |

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

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

**Experimental:** **This is an experimental technology**  
Check the Browser compatibility table carefully before using this in production.

The **`lineNumber`** read-only property of the `DeprecationReportBody` interface returns the line in the source file in which the deprecated feature was used.

**Note:** This property is most useful alongside `DeprecationReportBody.sourceFile` as it enables the location of the line in that file where the error occurred.

Value
-----

An integer, or `null` if the line is not known.

Examples
--------

In this example we create a new `ReportingObserver` to observe deprecation reports, then print the value of `lineNumber` to the console.


```js
let options = {
  types: ["deprecation"],
  buffered: true,
};

let observer = new ReportingObserver((reports, observer) => {
  let firstReport = reports[0];
  console.log(firstReport.type); // deprecation
  console.log(firstReport.body.sourceFile); // the source file
  console.log(firstReport.body.lineNumber); // the line in that file
}, options);
```

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

| Specification |
| --- |
| Deprecation Reporting # dom-deprecationreportbody-linenumber |

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

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

The **`ProgressEvent()`** constructor returns a new `ProgressEvent` object, representing the current completion of a long process.

Syntax
------


```js
new ProgressEvent(type)
new ProgressEvent(type, options)
```

### Parameters

`type`

 A string with the name of the event.
 It is case-sensitive and browsers set it to `loadstart`, `progress`, `abort`, `error`, `load`, `timeout`, or `loadend`.


`options` Optional

An object that, *in addition of the properties defined in `Event()`*, can have the following properties:

`lengthComputable` Optional

 A boolean value indicating if the total work to be done, and the
 amount of work already done, by the underlying process is calculable. In other words,
 it tells if the progress is measurable or not. It defaults to `false`.


`loaded` Optional

 A number representing the amount of work already
 performed by the underlying process. The ratio of work done can be calculated with the
 property and `ProgressEvent.total`. When downloading a resource using HTTP,
 this only represent the part of the content itself, not headers and other overhead. It
 defaults to `0`.


`total` Optional

 A number representing the total amount of work that the
 underlying process is in the progress of performing. When downloading a resource using
 HTTP, this only represent the content itself, not headers and other overhead. It
 defaults to `0`.



### Return value

A new `ProgressEvent` object.

Example
-------

The example demonstrates how a `ProgressEvent` is built using a constructor. This is particularly useful for tracking the progress of processes like file uploads, downloads, or any long-running tasks.


```js
function updateProgress(loaded, total) {
  const progressEvent = new ProgressEvent("progress", {
    lengthComputable: true,
    loaded: loaded,
    total: total,
  });

  document.dispatchEvent(progressEvent);
}

document.addEventListener("progress", (event) => {
  console.log(`Progress: ${event.loaded}/${event.total}`);
});

updateProgress(50, 100);
```

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

| Specification |
| --- |
| XMLHttpRequest Standard # dom-progressevent-progressevent |

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

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

See also
--------

* The `ProgressEvent` interface it belongs to.
ProgressEvent: loaded property
==============================

 The **`ProgressEvent.loaded`** read-only property is an integer
 representing the amount of work already performed by the underlying process. The ratio
 of work done can be calculated with the property and `ProgressEvent.total`.
 When downloading a resource using HTTP, this value is specified in bytes (not bits), and only represents the part of the content
 itself, not headers and other overhead.

Value
-----

A number.

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

| Specification |
| --- |
| XMLHttpRequest Standard # dom-progressevent-loaded |

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

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

See also
--------

* The `ProgressEvent` interface it belongs to.
ProgressEvent: lengthComputable property
========================================

 The
 **`ProgressEvent.lengthComputable`** read-only property is a
 boolean flag indicating if the resource concerned by the
 `ProgressEvent` has a length that can be calculated. If not, the
 `ProgressEvent.total` property has no significant value.

Value
-----

A boolean.

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

| Specification |
| --- |
| XMLHttpRequest Standard # dom-progressevent-lengthcomputable |

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

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

See also
--------

* The `ProgressEvent` interface it belongs to.
ProgressEvent: total property
=============================

 The **`ProgressEvent.total`** read-only property is an unsigned
 64-bit integer value indicating the total size of the data being processed or
 transmitted. In the case of an HTTP transmission, this is the size of the body of the
 message (the `Content-Length`), and does not include headers and other
 overhead.

 If the event's `lengthComputable`
 property is `false`, this value is meaningless and should be ignored.

Value
-----

An integer.

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

| Specification |
| --- |
| XMLHttpRequest Standard # dom-progressevent-total |

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

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

See also
--------

* The `ProgressEvent` interface it belongs to.