De-XHR, part 1

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
 

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)

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:
 >

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.
 

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.

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.)

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);

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

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

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.
 

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
 

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()")}}
 

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.
 

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.
 

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}}
 

files/en-us/web/api/xmlserializer/index.md

@@ -69,5 +69,4 @@ Once that's done, `insertAdjacentHTML()` is used to insert the `<input>` element
 ## See also
 
 - [Parsing and serializing XML](/en-US/docs/Web/Guide/Parsing_and_serializing_XML)
-- {{domxref("XMLHttpRequest")}}
 - {{domxref("DOMParser")}}