From 46502183f0a44d37f681a469eb1751b9a4951114 Mon Sep 17 00:00:00 2001 From: wbamberg Date: Wed, 8 Nov 2023 15:54:29 -0800 Subject: [PATCH] De-XHR, part 1 --- files/en-us/web/api/document/lastmodified/index.md | 7 ++----- .../how_to_create_a_dom_tree/index.md | 10 +++++----- .../web/api/eventtarget/addeventlistener/index.md | 2 +- files/en-us/web/api/eventtarget/index.md | 2 +- .../web/api/indexeddb_api/basic_terminology/index.md | 2 +- files/en-us/web/api/mediasource/endofstream/index.md | 4 ++-- files/en-us/web/api/pushmanager/index.md | 2 +- files/en-us/web/api/pushmanager/subscribe/index.md | 2 +- .../api/serviceworkerregistration/pushmanager/index.md | 2 +- files/en-us/web/api/streams_api/concepts/index.md | 2 +- files/en-us/web/api/web_workers_api/index.md | 4 +++- .../web/api/web_workers_api/using_web_workers/index.md | 8 +++++--- .../en-us/web/api/webrtc_api/session_lifetime/index.md | 2 +- .../webrtc_api/signaling_and_video_calling/index.md | 2 +- files/en-us/web/api/worker/index.md | 2 +- files/en-us/web/api/xmlserializer/index.md | 1 - 16 files changed, 27 insertions(+), 27 deletions(-) diff --git a/files/en-us/web/api/document/lastmodified/index.md b/files/en-us/web/api/document/lastmodified/index.md index 8256bbc055ecae2..0ac969169484862 100644 --- a/files/en-us/web/api/document/lastmodified/index.md +++ b/files/en-us/web/api/document/lastmodified/index.md @@ -9,7 +9,7 @@ browser-compat: api.Document.lastModified {{APIRef("DOM")}} The **`lastModified`** property of the {{domxref("Document")}} -interface returns a string containing the date and time on which the current document +interface returns a string containing the date and local time on which the current document was last modified. ## Value @@ -85,10 +85,7 @@ if (Number.isNaN(lastVisit) || lastModif > lastVisit) { } ``` -> **Note:** WebKit returns the time string in UTC; Gecko returns a time in the local timezone. (See: [Bug 4363 – document.lastModified returns date in UTC time, but should return it in local time](https://webkit.org/b/4363)) - -If you want to know **whether _an external page_ has changed**, -please read [this paragraph about the `XMLHttpRequest()` API](/en-US/docs/Web/API/XMLHttpRequest_API/Using_XMLHttpRequest#get_last_modified_date). +If you want to know whether an _external_ page has changed, you can make a {{HTTPMethod("HEAD")}} request using the {{domxref("fetch()")}} API, and examine the {{HTTPHeader("Last-Modified")}} response header. ## Specifications diff --git a/files/en-us/web/api/document_object_model/how_to_create_a_dom_tree/index.md b/files/en-us/web/api/document_object_model/how_to_create_a_dom_tree/index.md index 176578ed1635c18..d5a752d84ab26d7 100644 --- a/files/en-us/web/api/document_object_model/how_to_create_a_dom_tree/index.md +++ b/files/en-us/web/api/document_object_model/how_to_create_a_dom_tree/index.md @@ -83,14 +83,14 @@ doc.appendChild(peopleElem); DOM trees can be: -- [queried using XPath expressions](/en-US/docs/Web/XPath/Introduction_to_using_XPath_in_JavaScript) -- converted to strings using [XMLSerializer](/en-US/docs/Web/Guide/Parsing_and_serializing_XML) -- [posted to a web server](/en-US/docs/Web/API/XMLHttpRequest) using `XMLHttpRequest` -- transformed using [XSLT](/en-US/docs/Web/XSLT) or [XLink](/en-US/docs/Glossary/XLink). +- [Queried using XPath expressions](/en-US/docs/Web/XPath/Introduction_to_using_XPath_in_JavaScript). +- Converted to strings using [XMLSerializer](/en-US/docs/Web/Guide/Parsing_and_serializing_XML). +- [Posted to a web server](/en-US/docs/Web/API/Fetch_API) using the Fetch API. +- Transformed using [XSLT](/en-US/docs/Web/XSLT) or [XLink](/en-US/docs/Glossary/XLink). ## See also - [XML](/en-US/docs/Web/XML) - [XPath](/en-US/docs/Web/XPath) - [Parsing and serializing XML](/en-US/docs/Web/Guide/Parsing_and_serializing_XML) -- [XMLHttpRequest](/en-US/docs/Web/API/XMLHttpRequest) +- [Fetch API](/en-US/docs/Web/API/Fetch_API) diff --git a/files/en-us/web/api/eventtarget/addeventlistener/index.md b/files/en-us/web/api/eventtarget/addeventlistener/index.md index 6f517614f8366ca..d5e8bae59d55500 100644 --- a/files/en-us/web/api/eventtarget/addeventlistener/index.md +++ b/files/en-us/web/api/eventtarget/addeventlistener/index.md @@ -12,7 +12,7 @@ The **`addEventListener()`** method of the {{domxref("EventTarget")}} interface sets up a function that will be called whenever the specified event is delivered to the target. Common targets are {{domxref("Element")}}, or its children, {{domxref("Document")}}, and {{domxref("Window")}}, -but the target may be any object that supports events (such as {{domxref("XMLHttpRequest")}}). +but the target may be any object that supports events (such as {{domxref("IDBRequest")}}). > **Note:** The `addEventListener()` method is the _recommended_ way to register an event listener. The benefits are as follows: > diff --git a/files/en-us/web/api/eventtarget/index.md b/files/en-us/web/api/eventtarget/index.md index ae8d0f63449cd1f..b77ad3b583f8ebb 100644 --- a/files/en-us/web/api/eventtarget/index.md +++ b/files/en-us/web/api/eventtarget/index.md @@ -12,7 +12,7 @@ In other words, any target of events implements the three methods associated wit {{domxref("Element")}}, and its children, as well as {{domxref("Document")}} and {{domxref("Window")}}, are the most common event targets, but other objects can be event targets, too. -For example {{domxref("XMLHttpRequest")}}, {{domxref("AudioNode")}}, and {{domxref("AudioContext")}} are also event targets. +For example {{domxref("IDBRequest")}}, {{domxref("AudioNode")}}, and {{domxref("AudioContext")}} are also event targets. Many event targets (including elements, documents, and windows) also support setting [event handlers](/en-US/docs/Web/Events/Event_handlers) via `onevent` properties and attributes. diff --git a/files/en-us/web/api/indexeddb_api/basic_terminology/index.md b/files/en-us/web/api/indexeddb_api/basic_terminology/index.md index 6d9e4378b3a4d2b..ea95f63ece15969 100644 --- a/files/en-us/web/api/indexeddb_api/basic_terminology/index.md +++ b/files/en-us/web/api/indexeddb_api/basic_terminology/index.md @@ -27,7 +27,7 @@ If you have assumptions from working with other types of databases, you might ge This transaction model is really useful when you consider what might happen if a user opened two instances of your web app in two different tabs simultaneously. Without transactional operations, the two instances could interfere with each other's modifications. If you are not familiar with transactions in a database, read the [Wikipedia article on transactions](https://en.wikipedia.org/wiki/Database_transaction). Also see [transaction](#transaction) under the Definitions section. -- **The IndexedDB API is mostly asynchronous.** The API doesn't give you data by returning values; instead, you have to pass a callback function. You don't "store" a value into the database, or "retrieve" a value out of the database through synchronous means. Instead, you "request" that a database operation happens. You get notified by a DOM event when the operation finishes, and the type of event you get lets you know if the operation succeeded or failed. This sounds a little complicated at first, but there are sanity measures baked in. It's not that different from the way that [XMLHttpRequest](/en-US/docs/Web/API/XMLHttpRequest) works. +- **The IndexedDB API is mostly asynchronous.** The API doesn't give you data by returning values; instead, you have to pass a callback function. You don't "store" a value into the database, or "retrieve" a value out of the database through synchronous means. Instead, you "request" that a database operation happens. You get notified by a DOM event when the operation finishes, and the type of event you get lets you know if the operation succeeded or failed. - **IndexedDB uses a lot of requests.** Requests are objects that receive the success or failure DOM events that were mentioned previously. They have `onsuccess` and `onerror` properties, and you can call `addEventListener()` and `removeEventListener()` on them. They also have `readyState`, `result`, and `errorCode` properties that tell you the status of the request. The `result` property is particularly magical, as it can be many different things, depending on how the request was generated (for example, an `IDBCursor` instance, or the key for a value that you just inserted into the database). - **IndexedDB uses DOM events to notify you when results are available.** DOM events always have a `type` property (in IndexedDB, it is most commonly set to `"success"` or `"error"`). DOM events also have a `target` property that indicates where the event is headed. In most cases, the `target` of an event is the `IDBRequest` object that was generated as a result of doing some database operation. Success events don't bubble up and they can't be canceled. Error events, on the other hand, do bubble, and can be cancelled. This is quite important, as error events abort whatever transactions they're running in, unless they are cancelled. - **IndexedDB is object-oriented.** IndexedDB is not a relational database with tables representing collections of rows and columns. This important and fundamental difference affects the way you design and build your applications. diff --git a/files/en-us/web/api/mediasource/endofstream/index.md b/files/en-us/web/api/mediasource/endofstream/index.md index 3e8f6efd2e22714..990d61d84cc7ade 100644 --- a/files/en-us/web/api/mediasource/endofstream/index.md +++ b/files/en-us/web/api/mediasource/endofstream/index.md @@ -29,8 +29,8 @@ endOfStream(endOfStreamError) - : Terminates playback and signals that a network error has occurred. This can be used create a custom error handler related to media streams. For example, you might have a function that handles media chunk requests, separate - from other network requests. When you make an [XMLHttpRequest](/en-US/docs/Web/API/XMLHttpRequest) call for a media - chunk, and `onabort` or `onerror` triggers, you might want + from other network requests. When you make a {{domxref("fetch()")}} request for a media + chunk and receive a network error, you might want to call `endOfStream('network')`, display a descriptive message in the UI, and maybe retry the network request immediately or wait until the network is back up (via some kind of polling.) diff --git a/files/en-us/web/api/pushmanager/index.md b/files/en-us/web/api/pushmanager/index.md index 395fca0d379e55b..3ed7cfb6ec163de 100644 --- a/files/en-us/web/api/pushmanager/index.md +++ b/files/en-us/web/api/pushmanager/index.md @@ -53,7 +53,7 @@ navigator.serviceWorker console.log(pushSubscription.endpoint); // The push subscription details needed by the application // server are now available, and can be sent to it using, - // for example, an XMLHttpRequest. + // for example, the fetch() API. }, (error) => { console.error(error); diff --git a/files/en-us/web/api/pushmanager/subscribe/index.md b/files/en-us/web/api/pushmanager/subscribe/index.md index 8f06bdb4d96dfed..6446539282ccee6 100644 --- a/files/en-us/web/api/pushmanager/subscribe/index.md +++ b/files/en-us/web/api/pushmanager/subscribe/index.md @@ -70,7 +70,7 @@ navigator.serviceWorker.ready.then((serviceWorkerRegistration) => { console.log(pushSubscription.endpoint); // The push subscription details needed by the application // server are now available, and can be sent to it using, - // for example, an XMLHttpRequest. + // for example, the fetch() API. }, (error) => { // During development it often helps to log errors to the diff --git a/files/en-us/web/api/serviceworkerregistration/pushmanager/index.md b/files/en-us/web/api/serviceworkerregistration/pushmanager/index.md index d45030c8622c42b..e9b4ed60d43157a 100644 --- a/files/en-us/web/api/serviceworkerregistration/pushmanager/index.md +++ b/files/en-us/web/api/serviceworkerregistration/pushmanager/index.md @@ -36,7 +36,7 @@ navigator.serviceWorker console.log(pushSubscription.endpoint); // The push subscription details needed by the application // server are now available, and can be sent to it using, - // for example, an XMLHttpRequest. + // for example, the fetch() API. }, (error) => { // During development it often helps to log errors to the diff --git a/files/en-us/web/api/streams_api/concepts/index.md b/files/en-us/web/api/streams_api/concepts/index.md index 7eb935b6d59f6a7..7e9448b548e7a02 100644 --- a/files/en-us/web/api/streams_api/concepts/index.md +++ b/files/en-us/web/api/streams_api/concepts/index.md @@ -15,7 +15,7 @@ A readable stream is a data source represented in JavaScript by a {{domxref("Rea There are two types of underlying source: - **Push sources** constantly push data at you when you've accessed them, and it is up to you to start, pause, or cancel access to the stream. Examples include video streams and TCP/[Web sockets](/en-US/docs/Web/API/WebSockets_API). -- **Pull sources** require you to explicitly request data from them once connected to. Examples include a file access operation via a [Fetch](/en-US/docs/Web/API/Fetch_API) or [XHR](/en-US/docs/Web/API/XMLHttpRequest/XMLHttpRequest) call. +- **Pull sources** require you to explicitly request data from them once connected to. Examples include a file access operation via a {{domxref("fetch()")}} request. The data is read sequentially in small pieces called **chunks**. A chunk can be a single byte, or it can be something larger such as a [typed array](/en-US/docs/Web/JavaScript/Guide/Typed_arrays) of a certain size. A single stream can contain chunks of different sizes and types. diff --git a/files/en-us/web/api/web_workers_api/index.md b/files/en-us/web/api/web_workers_api/index.md index 72629ef2caf923c..426bb3c948565c8 100644 --- a/files/en-us/web/api/web_workers_api/index.md +++ b/files/en-us/web/api/web_workers_api/index.md @@ -17,7 +17,9 @@ In addition to the standard [JavaScript](/en-US/docs/Web/JavaScript) set of func Data is sent between workers and the main thread via a system of messages — both sides send their messages using the `postMessage()` method, and respond to messages via the `onmessage` event handler (the message is contained within the {{domxref("Worker/message_event", "message")}} event's `data` property). The data is copied rather than shared. -Workers may in turn spawn new workers, as long as those workers are hosted within the same {{glossary("origin")}} as the parent page. In addition, workers may use [`XMLHttpRequest`](/en-US/docs/Web/API/XMLHttpRequest) for network I/O, with the exception that the `responseXML` and `channel` attributes on `XMLHttpRequest` always return `null`. +Workers may in turn spawn new workers, as long as those workers are hosted within the same {{glossary("origin")}} as the parent page. + +In addition, workers can make network requests using the {{domxref("fetch()")}} or [`XMLHttpRequest`](/en-US/docs/Web/API/XMLHttpRequest) APIs (although note that the {{domxref("XMLHttpRequest.responseXML", "responseXML")}} attribute of `XMLHttpRequest` will always be `null`). ### Worker types diff --git a/files/en-us/web/api/web_workers_api/using_web_workers/index.md b/files/en-us/web/api/web_workers_api/using_web_workers/index.md index 68ba32e696d571c..bf268c292e44eda 100644 --- a/files/en-us/web/api/web_workers_api/using_web_workers/index.md +++ b/files/en-us/web/api/web_workers_api/using_web_workers/index.md @@ -7,7 +7,7 @@ spec-urls: https://html.spec.whatwg.org/multipage/#workers {{DefaultAPISidebar("Web Workers API")}} -Web Workers are a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface. In addition, they can perform I/O using [`XMLHttpRequest`](/en-US/docs/Web/API/XMLHttpRequest) (although the `responseXML` and `channel` attributes are always null) or [`fetch`](/en-US/docs/Web/API/Fetch_API) (with no such restrictions). Once created, a worker can send messages to the JavaScript code that created it by posting messages to an event handler specified by that code (and vice versa). +Web Workers are a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface. In addition, they can make network requests using the {{domxref("fetch()")}} or {{domxref("XMLHttpRequest")}} APIs. Once created, a worker can send messages to the JavaScript code that created it by posting messages to an event handler specified by that code (and vice versa). This article provides a detailed introduction to using web workers. @@ -23,7 +23,9 @@ You can run whatever code you like inside the worker thread, with some exception Data is sent between workers and the main thread via a system of messages — both sides send their messages using the `postMessage()` method, and respond to messages via the `onmessage` event handler (the message is contained within the {{domxref("Worker/message_event", "message")}} event's data attribute). The data is copied rather than shared. -Workers may, in turn, spawn new workers, as long as those workers are hosted within the same origin as the parent page. In addition, workers may use [`XMLHttpRequest`](/en-US/docs/Web/API/XMLHttpRequest) for network I/O, with the exception that the `responseXML` and `channel` attributes on `XMLHttpRequest` always return `null`. +Workers may in turn spawn new workers, as long as those workers are hosted within the same {{glossary("origin")}} as the parent page. + +In addition, workers can make network requests using the {{domxref("fetch()")}} or [`XMLHttpRequest`](/en-US/docs/Web/API/XMLHttpRequest) APIs (although note that the {{domxref("XMLHttpRequest.responseXML", "responseXML")}} attribute of `XMLHttpRequest` will always be `null`). ## Dedicated workers @@ -807,7 +809,7 @@ To learn how to debug web workers, see the documentation for each browser's Java You can use most standard JavaScript features inside a web worker, including: - {{domxref("Navigator")}} -- {{domxref("XMLHttpRequest")}} +- {{domxref("fetch()")}} - {{jsxref("Global_Objects/Array", "Array")}}, {{jsxref("Global_Objects/Date", "Date")}}, {{jsxref("Global_Objects/Math", "Math")}}, and {{jsxref("Global_Objects/String", "String")}} - {{domxref("setTimeout()")}} and {{domxref("setInterval()")}} diff --git a/files/en-us/web/api/webrtc_api/session_lifetime/index.md b/files/en-us/web/api/webrtc_api/session_lifetime/index.md index 4c88b8ae3a92a2f..aaf6172e8e34d23 100644 --- a/files/en-us/web/api/webrtc_api/session_lifetime/index.md +++ b/files/en-us/web/api/webrtc_api/session_lifetime/index.md @@ -30,7 +30,7 @@ Why, you may wonder, is something fundamental to the process of establishing a W In particular, if a developer already has a method in place for connecting two devices, it doesn't make sense for them to have to use another one, defined by the specification, just for WebRTC. Since WebRTC doesn't live in a vacuum, there is likely other connectivity in play, so it makes sense to avoid having to add additional connection channels for signaling if an existing one can be used. -In order to exchange signaling information, you can choose to send JSON objects back and forth over a WebSocket connection, or you could use XMPP or SIP over an appropriate channel, or you could use {{domxref("XMLHttpRequest")}} over {{Glossary("HTTPS")}} with polling, or any other combination of technologies you can come up with. You could even use email as the signaling channel. +In order to exchange signaling information, you can choose to send JSON objects back and forth over a WebSocket connection, or you could use XMPP or SIP over an appropriate channel, or you could use {{domxref("fetch()")}} over {{Glossary("HTTPS")}} with polling, or any other combination of technologies you can come up with. You could even use email as the signaling channel. It's also worth noting that the channel for performing signaling doesn't even need to be over the network. One peer can output a data object that can be printed out, physically carried (on foot or by carrier pigeon) to another device, entered into that device, and a response then output by that device to be returned on foot, and so forth, until the WebRTC peer connection is open. It'd be very high latency but it could be done. diff --git a/files/en-us/web/api/webrtc_api/signaling_and_video_calling/index.md b/files/en-us/web/api/webrtc_api/signaling_and_video_calling/index.md index d5d050cef003e09..ec35e84014deac3 100644 --- a/files/en-us/web/api/webrtc_api/signaling_and_video_calling/index.md +++ b/files/en-us/web/api/webrtc_api/signaling_and_video_calling/index.md @@ -18,7 +18,7 @@ In this article, we will further enhance the [WebSocket chat](https://webrtc-fro Establishing a WebRTC connection between two devices requires the use of a **signaling server** to resolve how to connect them over the internet. A signaling server's job is to serve as an intermediary to let two peers find and establish a connection while minimizing exposure of potentially private information as much as possible. How do we create this server and how does the signaling process actually work? -First we need the signaling server itself. WebRTC doesn't specify a transport mechanism for the signaling information. You can use anything you like, from [WebSocket](/en-US/docs/Web/API/WebSockets_API) to {{domxref("XMLHttpRequest")}} to carrier pigeons to exchange the signaling information between the two peers. +First we need the signaling server itself. WebRTC doesn't specify a transport mechanism for the signaling information. You can use anything you like, from [WebSocket](/en-US/docs/Web/API/WebSockets_API) to {{domxref("fetch()")}} to carrier pigeons to exchange the signaling information between the two peers. It's important to note that the server doesn't need to understand or interpret the signaling data content. Although it's {{Glossary("SDP")}}, even this doesn't matter so much: the content of the message going through the signaling server is, in effect, a black box. What does matter is when the {{Glossary("ICE")}} subsystem instructs you to send signaling data to the other peer, you do so, and the other peer knows how to receive this information and deliver it to its own ICE subsystem. All you have to do is channel the information back and forth. The contents don't matter at all to the signaling server. diff --git a/files/en-us/web/api/worker/index.md b/files/en-us/web/api/worker/index.md index c74db38af8bfcbe..11a0437935c165a 100644 --- a/files/en-us/web/api/worker/index.md +++ b/files/en-us/web/api/worker/index.md @@ -13,7 +13,7 @@ Creating a worker is done by calling the `Worker("path/to/worker/script")` const Workers may themselves spawn new workers, as long as those workers are hosted at the same [origin](/en-US/docs/Web/Security/Same-origin_policy) as the parent page. -[Not all interfaces and functions are available](/en-US/docs/Web/API/Web_Workers_API/Functions_and_classes_available_to_workers) to scripts inside a `Worker`. Workers may use {{domxref("XMLHttpRequest")}} for network communication, but its `responseXML` and `channel` attributes are always `null`. ([`fetch`](/en-US/docs/Web/API/Fetch_API) is also available, with no such restrictions.) +Note that not all interfaces and functions are available to web workers. See [Functions and classes available to Web Workers](/en-US/docs/Web/API/Web_Workers_API/Functions_and_classes_available_to_workers) for details. {{InheritanceDiagram}} diff --git a/files/en-us/web/api/xmlserializer/index.md b/files/en-us/web/api/xmlserializer/index.md index ecc629ec351e722..c15b2e6015a206c 100644 --- a/files/en-us/web/api/xmlserializer/index.md +++ b/files/en-us/web/api/xmlserializer/index.md @@ -69,5 +69,4 @@ Once that's done, `insertAdjacentHTML()` is used to insert the `` element ## See also - [Parsing and serializing XML](/en-US/docs/Web/Guide/Parsing_and_serializing_XML) -- {{domxref("XMLHttpRequest")}} - {{domxref("DOMParser")}}