Web APIs A-B Page

Why Create This 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.

Navigate Web APIs

Attribution Reporting API

The Attribution Reporting API enables developers to measure conversions - for example when a user clicks on an ad embedded on one site an then proceeds to purchase the item on the vendor's site - and then access reports on those conversions. It does this without relying on third-party tracking cookie.

The Attribution Reporting API provides a way to measure ad conversion in a way that protects user privacy. The Attribution API works through a combination of headers, JavaScript (fetch and attributes), and anchor/image/iframe tags.

Attribution Reporting API
I am not going to implement the Attribution Reporting API because I don't plan on using ads anytime soon.

Audio Output Devices API

The Audio Output Devices API allows web applications to prompt users bout what output devices should be used for audio playback.
Operating systems commonly allow users to specify that audio should be played from speakers, a Bluetooth headset, or some other audio output device. This API allows application to provide the same functionality within a web page.

The API provides the MediaDevices.selectAudioOutput() method that allows users to select their desired audio output from those that are allowed by the speaker-selection directive of the Permissions-Policy HTTP header fro the document. The selected device then has user permission, allowing it to be enumerated with MediaDevices.enumerateDevices() and set as the audio output using HTMLMediaElement.setSinkId().

The area below will show the output of navigator.mediaDevices.selectAudioOutput, if it exists in the window context.

Background Fetch API

The Background Fetch API provides a method for managing downloads that may take a significant amount of time such as movies, audio files, and software.

When a user needs to download large files, this presents a problem in that the user needs to stay connected to the page for the download to complete. If they lose connectivity, close the page, or navigate away from the page, the download stops. The BackgroundSynchronization API provides a way for Service Workers to defer processing until a user is connected; however it can't be used for long running tasks such as downloading a large file. The BackgroundFetch API solves this problem. It creates a way for a web developer to tell the browser to perform some fetches in the background. The browser then performs the fetches in a user-visible way, displaying progress to the user and giving them a method to cancel the download. Once the download is complete, the browser then opens the service worker, at which point in your application can do something with the response.

I don't have a use yet for the Background Fetch API, but it should be used to download large files (I have no large files that I need to download right now).

Background Sync

The Background Synchronization API enables a web app to defer tasks so that they can be run in a service worker once the user has a stable network connection.

This API allows web applications to defer server synchonization work to their service worker to handle at a later time, if the device is offline. For example, an email client application could let its users compose and send messages at any time, even when the device has no network connection. The application frontend registers a sync request and the service worker gets alerted when the network is present again and handles the sync. The SyncManager interface is available through ServiceWorkerRegistration.sync.

Possible Use Cases:

  • Submitting articles / comments after regaining network connection.
  • Checking for changes in an article and using the ServiceWorker to check for changes to know if to reload the page / reload metrics on the article / comments.

Background Task

The Cooperative Scheduling of Background Tasks API (also referred to as the Background Tasks API or the requestIdCallback() API) provides the ability to queue tasks to be executed automatically by the user-agent when it determines that there is free time to do so.

Because event handling and screen updates are two of the most obvious ways users notice performance issues, it's important for your code to be a good citizen of the Web and help prevent stalls in the execution loop/ Window.requestIdCallback() makes it possible to become actively engaged in helping to ensure that the browser's event loop runs smoothly, by allowing the browser to tell your code how much time it can safely use without causing the system to lag.

How To Use:

  • Use idle callbacks for tasks which don't have high priority.
  • Idle callbacks should do their best not to overrun the time alloted.
  • Avoid making changes to the DOM within your idle callback.
  • Avoid tasks whose run time can't be predicted.
  • Use timeouts only when you need to.

Badging API

The Badging API gives web developers a method of setting a badge on a document or application, to act as a notification that state has changed without displaying a more distracting notification. A common use case for this would be an application with a messaging feature displaying a badge on the app icon to show that new messages have arrived. Web developers frequently update document favicons or titles in order to indicate status. The Badging API provides a more elegant way to show status, by providing a method which has meaning to the user agent and can therefore be displayed in a way that matches the rest of the UI.

Two Types of badges:

  • Document badges, which are typically shown in the browser tab near or on the page icon.
  • App badges, which are associated with the icon of an installed web app. These may display on the app icon in the dock, shelf, or home screen depending on the device in use.

A bade icon can have three possible values:

  1. nothing Indicates that no badge is currently set. A badge can be in this state due to it being cleared by the application, or being reset by the user.
  2. flag Indicating that the badge is set, but has no specific data to diaply. A badge will be in this state id the application has set a badge, but passed no value.
  3. an integer A value passed when setting the badge., This value will never be 0.

A badge is set with the methods setAppBadge(). Badges are cleared with the clearAppBadge() methods.

Barcode Detection API

The Barcode Detection API detects linear and two-dimensional barcodes in images.

Support for barcode recognition within web apps unlocks a variety of use cases through supported barcode formats. QR codes can be used for online payments, web navigation or establishing social media connections. Aztec codes can be used to scan boarding passes and shopping apps can use EAN or UPC barcodes to compare prices of physical items.

Battery API

The Battery Status API, more often referred to as the Battery API, provides information about the system's battery charge level and lets you be notified by events that are sent when the battery level or charging status change. This can be used to adjust your app's resource usage to reduce battery train when the battery is low, or to save changes before the battery runs out in order to prevent data loss.

Beacon

The Beacon API is used to send an asynchronous and non-blocking request to a web server. Unlike requests made using XMLHttpRequest or the Fetch API, the browser guarantees to initiate beacon requests before the page is unloaded and to run them to completion.

The main use case for the Beacon API is to send analytics such as client-side events or session data to the server. Because beacon requests are both asynchronous and guaranteed to be sent, they combine good performance characteristics and reliability.

Bluetooth API

The Web Bluetooth API provides the ability to connect and interact with Bluettoth Low Energy peripherals.

The Web Bluetooth API can only be used in a secure context. Access to the API is controlled by the Permissions Policy directive bluetooth. The default allowlist for the bluetooth policy is self, whch enables Bluettoth usage in same-origin nested frames but prevents access by third-party content by default. In order to use the freature, the user must first grant explicit permission (they will not be prompted for access for other reasons).

Broadcast Channel API

The Broadcast Channel API allows basic communication between browsing contexts (that is, windows, tabs, frames, or iframes) and workers on the same origin.

By creating a BroadcastChannel object, you can receive messages that are posted to it. You don;t have to maintain a reference to the frames or workers you wish to communicate with: they can "subscibe" to the frames or workers you wish to communicate with: they can "subscribe" to a particular channel by constructing their own BroadcastChannel with the same name and having bi-directional communication between all of them.

Broadcast Channel

The Broadcast Channel API's self-contained interface allows cross-context communication. It can be used to detect user actions in other tabs within a same origin, like when the user logs in or out.