Web APIs R-S Page
I created this page because when implementing Notifications and the Service Worker for this website, I came across the mdn web docs page on Web APIs, and I noticed how many Web APIs I haven't tried out that looked interesting. I am going to use this page to learn more about the Web APIs and implement them to test their functionality. Because there are 137 Web APIs available, I am going to paginate this project so that one page does not have too much information.
The list below lists the Web APIs that are available on various platforms, and it provides links to notes that I have taken on them / implementations of the various Web APIs on this site.
- A-B
- C-C
- D-F
- G-I
- K-P
- Launch Handler API
- Local Font Access API
- Media Capabilities API
- Media Capture and Stream
- Media Session API
- Media Source Extensions
- MediaStream Recording
- Navigation API
- Network Information API
- Page Visibility API
- Payment Handler API
- Payment Request API
- Performance API
- Periodic Background Sync
- Permissions API
- Picture-in-Picture API
- Pointer Event
- Pointer Lock API
- Popover API
- Presentation API
- Prioritized Task Scheduling API
- Push API
- R-S
- T-V
- W-W
- Web Audio API
- Web Authentication API
- Web Component
- Web Crypto API
- Web Locks API
- Web MIDI API
- Web NFC API
- Web Notification
- Web Serial API
- Web Share API
- Web Speech API
- Web Storage API
- Web Workers API
- WebCodecs API
- WebG
- WebGPU API
- WebHID API
- WebOTP API
- WebRTC
- WebSockets API
- WebTransport API
- WebUSB API
- WebVR API
- WebVTT
- WebXR Device API
- Window Controls Overlay API
- Window Management API
The Reporting API provides a generic reporting mechanism for web applications to use to make reports available on various platform features (for example, Content Security Policy, Permissions-Policy, or feature deprecation reports) in a consistent manner.
There are several different features and problems on the web platform that generate information useful to web developers when they are trying to fix bugs or improve their websites in other ways. Such information can include:
- Content Security Policy violations
- Permissions-Policy violations
- Deprecated feature usage (when you are using something that will stop working soon in browsers)
- Occurrence of crashes
- Occurrence of user-agent interventions
The purpose of the Reporting API is to provide a consistent reporting mechanism that can be used to make such information to developers in the form of reports represented by JavScript objects. Endpoints are named URLs that can be sent reports from a user agent. The Reporting-Endpoints HTTP header is used to specify endpoints that a user-agent has available for delivering reports. The report-to directive can then be used on particular HTTP response headers to indicate the specific endpoint that will be used for the associated report.
The reports themeselves are sent to the target endpoint by the user agent in a POST operation with a Content-Type of application/reports+json. They are serializations of Report objects, where the type indicates the type of report, the url indicates the origin of the report, and the body indicates a serialization f the API interface that corresponds to the report type.
Reports can also be obtained via ReportingObserver objects created via JavaScript inside the website you are aiming to get reports on.
The Resize Observer API provides a performant mechanism by which code can monitor an element for changes to its size, with notifications being delivered to the observer each time the size changes.
There are a lot of use cases for responsive design techniques that respond to changes in an element's size, but previously their implementations have often been hacky/brittle. The Resize Observer API provides a solution to common problems when you want to listen for changes in the size of an element, and it provides a JavaScript solution to the often-discussed lack of element queries in the web platform. You can create a ResizeObserver object using the ResizeObserver() constructor, then use ResizeObserver.observe() to make it look for changes to a specific element's size.
SVG applies elements for circles, rectangles, and simple and complex curves. The elements' attributes values specify how these must be drawn. The SVG API is the subset of the DOM connecting these SVG elements and their attribute values to scripts or programming languages by representing them in memory. The SVG API thus provides methods that allow programmatic access to the SVG elements and their attribute values.
The Screen Capture API introduces additions to the existing MediaCapture and Streams API to let the user select a screen or portion of a screen (such as a window) to capture as a media stream. This stream can then be recorded or shared with others over a network.
The Screen Capture API is simple to use. Its sole method is MediaDevices.getDisplayMedia(), whose job is to ask the user to select a screem or portion of a screen to capture in the form of a MediaStream.
The Screen Orientation API provides information about the orientation of the screen.
The Screen Wake Lock API provides a way to prevent devices from dimming or locking the screen when an application needs to keep running.
Most devices by default turn of their screen after a specified amount of time to prolong the life of the hardware. The Screen Lock Wake API prevents the screen from turning off, dimming or locking. It allows for a simple pattern-based solution for visible (active) documents to acquire the platform screen wake lock. You acquire a WakeLockSentinel object by claling the navigator.wakeLock.request() Promise-based method that resolves if the platform allows it.
The Selection API enables developers to access and manipulate the portion of a document selected by the user.
The Window.getSelection() and Document.getSelection() methods return a Selection object representing the portion of the document selected by the user. A Selection object provides methods to:
- access the currently selected nodes
- modify the current selection, expanding or collapsing it or selecting an entirely different part of the document
- delete parts of the current selection from the DOM
The Selection APIalso provides two events, both firing on Document: selectionstart and selectionchange.
The Sensor APIs are a set of interfaces built to a common design that expose device sensors in a consistent way to the web platform.
Although the Generic Sensor API specification defines a Sensor interface, as a web developer you will never use it. Instead, you'll use one of its subclasses to retrieve specific kinds of sensor data, e.g. the Accelerometer interface. Sensors may or may not correspond exactly to a physical device sensor.
Detecting Sensor APIs
if (typeof Gyroscope === "function") {
// run in circles…
}
if ("ProximitySensor" in window) {
// watch out!
}
if (window.AmbientLightSensor) {
// go dark…
}
Defensive Programming must be used when detecting th existence of sensors:
- Checking for thrown errors when instantiating a sensor object.
- Listening for errors thrown during its use.
- Handling the errors gracefully so that the user experience is enhanced rather than degraded.
Sometimes you have to request permission to use a sensor or alter the Permissions-Policy HTTP header.
Sensor | Permission Policy Name |
---|---|
AbsoluteOrientationSensor | 'accelerometer', 'gyroscope' and 'magnetometer' |
Accelerometer | 'accelerometer' |
AmbientLightSensor | 'ambient-light-sensor' |
GravitySensor | 'accelerometer' |
GyroScope | 'gyroscope' |
Linear Acceleration Sensor | 'accelerometer' |
Magnetometer | 'magnetometer' |
RelativeOrientationSensor | 'accelerometer' and 'gyroscope' |
Sensor readings are received through the reading event callback which is inherited by all sensor types.
Traditionally, a web page has to send a request to the server to receive new data [...] With server-sent events, it's possible for a server to send new data to a web page at any time, by pushing messages to the web page. These incoming messages can be treated as Events + data inside the web page.
Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests, and take appropriate action based on whether the network is available, and update assets residing on the server. They will also allow access to push notifications and background sync APIs.
A service worker is an even-driven worker registered against an origin and a path. It takes the form of a JavaScript file that can control the web page/site that it is associated with, intercepting and modifying navigation and request and resource requests, and caching resources in a very granular fashion to give you complete control over how your app behaves in certain situations.
Service Workers have no DOM access and run on a different thread to the main JS that powers your app. They are non-blocking and designed to be fully asynchronous. Service workers can;t import JS dynamically, and they only work over HTTPS.
The Shared Storage API is a client-side storage mechanism that enables unpartitioned, cross-site data access while preserving privacy (i.e., without relying on tracking cookies).
The Shared Storage API provides a flexible solution for use cases where cross-site information sharing is preferable.
The Speculation Rules API is designed to improve performance for future navigations. It targets document URLs rather than specific resource files, and so makes sense for multi-page applications (MPAs) rather than single page applications (SPAs).
The Speculation Rules API provides an alternative to the widely-available <link rel="prefetch"> and is designed to supersede the Chrome-only deprecated <link rel="prerender"> feature.
The Storage Standard defines a shared storage system designed to be used by all APIs and technologies that websites can use to store data in a user's browser.
The Storage APU gives websites the ability to find out how much space they can use, how much they are already using, and even control whether or not they need to be alerted before the user agent disposes of data in order to make room for other things. The storage system described by the Storage Standard, where site data is stored, usually consists of a single bucket for each origin. In essence, every website has its own storage space into which its data gets placed.
Each site storage bucket has a mode that describes the data retention policy for that bucket. There are two modes:
- "best-effort": The user agent will try to retain the data contained in the bucket for as long as it can, but will not warn users if storage space runs low and it becomes necessary to clear the bucket in order to relieve the storage pressure
- "persistent": The user agent will retain the data as long as possible, clearing all "best-effort" buckets before considering clearing a bucket marked "persistent"
The user agent determines, using whatever mechanism it chooses, the maximum amount of storage a given site can use. The maximum is the origin's quota. The amount of this space which is in use by the site is called its usage. But these values are estimates. Data eviction is the process by which a user agent deletes an origin's stored data.
The Storage Access API provides a way for cross-site content loaded in a third-party context (loaded in an <iframe>) o gain access to third-party cookies and unpartitioned state that it would typically only have access to ina first party context.
The Streams API allows JavaScript to programatically access streams of data received over the network and process them as desired by the developer.
Streaming involves breaking a resource that you want to receive over a network into small chunks, then processing it bit by bit. Browsers already do this when receiving media assets - video buffer and play as more of the content downloads, and sometimes you'll see images display gradually as more is loaded too. With the streams API, you can start processing raw data bit by bit as it is available, without needing to generate a buffer, string, or blob.