diff --git a/files/en-us/_redirects.txt b/files/en-us/_redirects.txt index 3bc9157900389d0..4dc75966ef64aed 100644 --- a/files/en-us/_redirects.txt +++ b/files/en-us/_redirects.txt @@ -10423,6 +10423,7 @@ /en-US/docs/Web/API/StorageQuota/queryInfo /en-US/docs/Web/API/StorageManager /en-US/docs/Web/API/StorageQuota/requestPersistentQuota /en-US/docs/Web/API/StorageManager /en-US/docs/Web/API/StorageQuota/supportedTypes /en-US/docs/Web/API/StorageManager +/en-US/docs/Web/API/Storage_Access_API/Related_website_sets /en-US/docs/Web/API/Storage_Access_API /en-US/docs/Web/API/StyleSheet.disabled /en-US/docs/Web/API/StyleSheet/disabled /en-US/docs/Web/API/StyleSheet.href /en-US/docs/Web/API/StyleSheet/href /en-US/docs/Web/API/StyleSheet.media /en-US/docs/Web/API/StyleSheet/media diff --git a/files/en-us/mdn/writing_guidelines/page_structures/banners_and_notices/index.md b/files/en-us/mdn/writing_guidelines/page_structures/banners_and_notices/index.md index 61d544225ebca4b..d6954aae583fc28 100644 --- a/files/en-us/mdn/writing_guidelines/page_structures/banners_and_notices/index.md +++ b/files/en-us/mdn/writing_guidelines/page_structures/banners_and_notices/index.md @@ -74,4 +74,4 @@ It is important to clarify the current standardization status of such features t - Adding a "Standards positions" section to the same page as the above banner, as a sub-section of the standard "Specifications" section. > [!NOTE] -> See [Related Website Sets](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets) for an example of the "Standards positions" section and what it should contain, as well as the landing page banner. +> See [Shared Storage API](/en-US/docs/Web/API/Shared_Storage_API) for an example of the "Standards positions" section and what it should contain, as well as the landing page banner. diff --git a/files/en-us/mozilla/add-ons/webextensions/api/publicsuffix/getdomain/index.md b/files/en-us/mozilla/add-ons/webextensions/api/publicsuffix/getdomain/index.md index ee65265894ca61b..354b1312afb3415 100644 --- a/files/en-us/mozilla/add-ons/webextensions/api/publicsuffix/getdomain/index.md +++ b/files/en-us/mozilla/add-ons/webextensions/api/publicsuffix/getdomain/index.md @@ -63,10 +63,10 @@ Using `allowIPAddress` to return IP addresses as-is: ```js console.log( - browser.publicSuffix.getDomain("192.0.2.1", { allowIPAddress: true }) + browser.publicSuffix.getDomain("192.0.2.1", { allowIPAddress: true }), ); // "192.0.2.1" console.log( - browser.publicSuffix.getDomain("[2001:db8::1]", { allowIPAddress: true }) + browser.publicSuffix.getDomain("[2001:db8::1]", { allowIPAddress: true }), ); // "2001:db8::1" ``` @@ -74,7 +74,7 @@ Using `allowPlainSuffix` to return hostnames that are public suffixes: ```js console.log( - browser.publicSuffix.getDomain("co.uk", { allowPlainSuffix: true }) + browser.publicSuffix.getDomain("co.uk", { allowPlainSuffix: true }), ); // "co.uk" ``` @@ -83,11 +83,11 @@ Using `allowUnknownSuffix` to handle private or local domains: ```js console.log( browser.publicSuffix.getDomain("mydevice.local", { - allowUnknownSuffix: true - }) + allowUnknownSuffix: true, + }), ); // "mydevice.local" console.log( - browser.publicSuffix.getDomain("host.intranet", { allowUnknownSuffix: true }) + browser.publicSuffix.getDomain("host.intranet", { allowUnknownSuffix: true }), ); // "host.intranet" ``` @@ -97,16 +97,16 @@ Using `encoding: "display"` for internationalized domain names: // "xn--nxasmq6b.com" is the punycode form of "βόλος.com" console.log( browser.publicSuffix.getDomain("sub.xn--nxasmq6b.com", { - encoding: "display" - }) + encoding: "display", + }), ); // "βόλος.com" // Domains with confusable characters remain in punycode // "xn--bs-red.com" has characters confusable with another script console.log( browser.publicSuffix.getDomain("sub.xn--bs-red.com", { - encoding: "display" - }) + encoding: "display", + }), ); // "xn--bs-red.com" ``` diff --git a/files/en-us/web/api/barcodedetector/getsupportedformats_static/index.md b/files/en-us/web/api/barcodedetector/getsupportedformats_static/index.md index 3db0c793c05149f..fa72da83e3acb27 100644 --- a/files/en-us/web/api/barcodedetector/getsupportedformats_static/index.md +++ b/files/en-us/web/api/barcodedetector/getsupportedformats_static/index.md @@ -35,7 +35,7 @@ No exceptions are thrown. ## Examples -The following example calls the `getSupportFormat()` static method and logs +The following example calls the `getSupportedFormats()` static method and logs the results to the console. ```js diff --git a/files/en-us/web/api/barcodedetector/index.md b/files/en-us/web/api/barcodedetector/index.md index fd5da62b3dd7783..1a9c5bfc67afeae 100644 --- a/files/en-us/web/api/barcodedetector/index.md +++ b/files/en-us/web/api/barcodedetector/index.md @@ -52,7 +52,7 @@ if (!("BarcodeDetector" in globalThis)) { ### Getting Supported Formats -The following example calls the `getSupportFormat()` static method and logs the results to the console. +The following example calls the `getSupportedFormats()` static method and logs the results to the console. ```js // check supported types diff --git a/files/en-us/web/api/document/index.md b/files/en-us/web/api/document/index.md index d169307fb49ecdf..c4ea7c08843428a 100644 --- a/files/en-us/web/api/document/index.md +++ b/files/en-us/web/api/document/index.md @@ -281,7 +281,7 @@ _This interface also inherits from the {{DOMxRef("Node")}} and {{DOMxRef("EventT - {{DOMxRef("Document.requestStorageAccess()")}} - : Allows a document loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to request access to unpartitioned cookies, in cases where user agents by default block access to unpartitioned cookies by sites loaded in a third-party context to improve privacy. - {{DOMxRef("Document.requestStorageAccessFor()")}} {{deprecated_inline}} {{non-standard_inline}} - - : Allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). + - : Allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration). - {{domxref("Document.startViewTransition()")}} - : Starts a new {{domxref("View Transition API", "view transition", "", "nocode")}} and returns a {{domxref("ViewTransition")}} object to represent it. diff --git a/files/en-us/web/api/document/requeststorageaccessfor/index.md b/files/en-us/web/api/document/requeststorageaccessfor/index.md index fd58cb240bdfcf8..b82435aa88fdf27 100644 --- a/files/en-us/web/api/document/requeststorageaccessfor/index.md +++ b/files/en-us/web/api/document/requeststorageaccessfor/index.md @@ -11,7 +11,7 @@ browser-compat: api.Document.requestStorageAccessFor {{APIRef("Storage Access API")}}{{deprecated_header}}{{non-standard_header}} -The **`requestStorageAccessFor()`** method of the {{domxref("Document")}} interface allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). It returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied. +The **`requestStorageAccessFor()`** method of the {{domxref("Document")}} interface allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration). It returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied. ## Syntax @@ -43,7 +43,7 @@ A {{jsxref("Promise")}} that fulfills with `undefined` if the access to third-pa - The document is not the top-level document. - The document has a `null` origin. - The supplied `requestedOrigin` is [opaque](https://html.spec.whatwg.org/multipage/browsers.html#concept-origin-opaque). - - The top-level and embedded sites are not in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). + - The top-level and embedded sites are not in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration). - The embedding {{htmlelement("iframe")}} is sandboxed, and the `allow-storage-access-by-user-activation` token is not set. - Usage is blocked by a {{httpheader("Permissions-Policy/storage-access", "storage-access")}} [Permissions Policy](/en-US/docs/Web/HTTP/Guides/Permissions_Policy). - Usage is denied by the user agent's permission request to use the API. diff --git a/files/en-us/web/api/storage_access_api/index.md b/files/en-us/web/api/storage_access_api/index.md index 5dc2e519d48c8d6..954f65099263bf0 100644 --- a/files/en-us/web/api/storage_access_api/index.md +++ b/files/en-us/web/api/storage_access_api/index.md @@ -67,7 +67,7 @@ Third party content embedded in an {{htmlelement("iframe")}} that needs to acces - Safari shows prompts for all embedded content that has not previously received storage access. - Firefox only prompts users after an origin has requested storage access on more than a threshold number of sites. - Chrome shows prompts for all embedded content that has not previously received storage access. - It will however automatically grant access and skip prompts if the embedded content and embedding site are part of the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). + It will however automatically grant access and skip prompts if the embedded content and embedding site are part of the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration). 3. Permission is granted or denied based on whether the content meets all the security requirements — see [Security considerations](#security_considerations) for general requirements, and [Browser-specific variations](#browser-specific_variations) for some browser-specific security requirements. The {{jsxref("Promise")}}-based nature of `requestStorageAccess()` allows you to run code to handle success and failure cases. @@ -311,8 +311,8 @@ Documentation for Firefox's new storage access policy for blocking tracking cook - : New name for {{domxref("Document.hasStorageAccess()")}}. - {{domxref("Document.requestStorageAccess()")}} - : Allows content loaded in a third-party context (i.e., embedded in an {{htmlelement("iframe")}}) to request access to third-party cookies and unpartitioned state; returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied. -- {{domxref("Document.requestStorageAccessFor()")}} {{experimental_inline}} - - : A proposed extension to the Storage Access API that allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). Returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied. +- {{domxref("Document.requestStorageAccessFor()")}} {{deprecated_inline}} + - : A non-standard deprecated extension to the Storage Access API that allows top-level sites to request third-party cookie access on behalf of embedded content originating from another site in the same [related website set](https://privacysandbox.google.com/cookies/related-website-sets-integration). Returns a {{jsxref("Promise")}} that resolves if the access was granted, and rejects if access was denied. > [!NOTE] > User interaction propagates to the promise returned by these methods, allowing the callers to take actions requiring user interaction without requiring a second click. For example, a caller could open a pop-up window from the resolved promise without triggering Firefox's pop-up blocker. diff --git a/files/en-us/web/api/storage_access_api/related_website_sets/index.md b/files/en-us/web/api/storage_access_api/related_website_sets/index.md deleted file mode 100644 index c5b6670a0cc6415..000000000000000 --- a/files/en-us/web/api/storage_access_api/related_website_sets/index.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -title: Related Website Sets -slug: Web/API/Storage_Access_API/Related_website_sets -page-type: guide -status: - - deprecated - - non-standard -spec-urls: https://wicg.github.io/first-party-sets/ ---- - -{{DefaultAPISidebar("Storage Access API")}}{{Non-standard_Header}} - -> [!WARNING] -> This feature is currently opposed by two browser vendors. See the [Standards positions](#standards_positions) section below for details of opposition. - -Related website sets are a mechanism for defining a set of related sites that share trusted content. As a result, browsers can grant default access for these sites to [third-party cookies](/en-US/docs/Web/Privacy/Guides/Third-party_cookies) and [unpartitioned state](/en-US/docs/Web/Privacy/Guides/State_Partitioning#state_partitioning) when they have content embedded in other set members, without requiring users to grant access to the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) via a permission prompt. - -## Concepts and usage - -Let's consider situations where you have a series of related websites with different domain names, and you want to give site content access to third-party cookies and unpartitioned state when loaded in a third-party context inside other related sites (i.e., embedded in an {{htmlelement("iframe")}}). Typical use cases are: - -- App sites: A single application may be deployed over multiple sites, aiming to allow users to navigate between them seamlessly in a single session. -- Brand sites: A set of brand assets may be contained in a single site but then deployed over multiple domains, including session data relating to user preferences, customization, etc. - -Third-party cookie and unpartitioned state access is commonly blocked by browser policies. Still, you can work around it using the Storage Access API — see [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using) for details. - -Related website are a progressive enhancement mechanism that works alongside the Storage Access API. Supporting browsers grant third-party cookie and unpartitioned state access between websites in the same set _without_ having to go through the usual user permission prompt workflow, once {{domxref("Document.requestStorageAccess()")}} (or {{domxref("Document.requestStorageAccessFor()")}}) is called. This results in a more user-friendly experience for users of sites in the set. - -You should bear in mind that: - -- The Chrome-only {{domxref("Document.requestStorageAccessFor()")}} method — which allows top-level sites to request storage access on behalf of embedded origin content — is only supported on domains within a related website set. See [Using the Storage Access API](/en-US/docs/Web/API/Storage_Access_API/Using) for an example. -- When Chrome first supported the standard Storage Access API (that is, the {{domxref("Document.hasStorageAccess()")}} and {{domxref("Document.requestStorageAccess()")}} methods), it required calling sites to be part of a related website set. This is no longer the case. - -## How does RWS work? - -A related website set consists of one primary site and up to five associated sites. - -### JSON structure - -A set is represented by a JSON structure. A hypothetical example is as follows: - -```json -{ - "sets": [ - { - "contact": "email address or group alias if available", - "primary": "https://primary1.com", - "associatedSites": [ - "https://associateA.com", - "https://associateB.com", - "https://associateC.com" - ], - "serviceSites": ["https://servicesiteA.com"], - "rationaleBySite": { - "https://associateA.com": "Explanation of affiliation with primary site", - "https://associateB.com": "Explanation of affiliation with primary site", - "https://associateC.com": "Explanation of affiliation with primary site", - "https://serviceSiteA.com": "Explanation of service functionality support" - }, - "ccTLDs": { - "https://associateA.com": [ - "https://associateA.ca", - "https://associateA.co.uk" - ], - "https://associateB.com": [ - "https://associateB.ru", - "https://associateB.co.kr" - ], - "https://primary1.com": ["https://primary1.co.uk"] - } - } - ] -} -``` - -> [!NOTE] -> The affiliation explanations must include a clear description of how the affiliation to the primary site is presented to users of those sites. - -To use a set, its JSON must be added to the `related_website_sets.JSON` file available on the [Related Website Sets GitHub repository](https://github.com/GoogleChrome/related-website-sets/blob/main/related_website_sets.JSON), which Chrome then consumes to get the list of sets to apply RWS behavior to. - -### `.well-known` files - -Each site in the set must also serve a [`.well-known`](https://en.wikipedia.org/wiki/Well-known_URI) file at `/.well-known/related-website-set.json`, which serves to verify the set structure and the relationship between the sites in the set. - -The primary site's `.well-known` file must explicitly list out the full set structure. `https://primary1.com` in the above example would need a `https://primary1.com/.well-known/related-website-set.json` file similar to the following: - -```json -{ - "primary": "https://primary1.com", - "associatedSites": [ - "https://associateA.com", - "https://associateB.com", - "https://associateC.com" - ], - "serviceSites": ["https://servicesiteA.com"], - "rationaleBySite": { - "https://associateA.com": "Explanation of affiliation with primary site", - "https://associateB.com": "Explanation of affiliation with primary site", - "https://associateC.com": "Explanation of affiliation with primary site", - "https://serviceSiteA.com": "Explanation of service functionality support" - }, - "ccTLDs": { - "https://associateA.com": [ - "https://associateA.ca", - "https://associateA.co.uk" - ], - "https://associateB.com": [ - "https://associateB.ru", - "https://associateB.co.kr" - ], - "https://primary1.com": ["https://primary1.co.uk"] - } -} -``` - -Each associate and service site needs to specify its primary site in a `.well-known` file. Each non-primary site in the above example (e.g., `https://associateA.com`) would need a `/.well-known/related-website-set.json` file like this: - -```json -{ - "primary": "https://primary1.com" -} -``` - -For full details of the process, JSON syntax, and other requirements for submitting sets, see the [submission guidelines](https://github.com/GoogleChrome/related-website-sets/blob/main/RWS-Submission_Guidelines.md). Only domain administrators can create a set containing their sites. - -Bear in mind that the `.well-known` files are also verified as part of the submission process, so they need to be put in place before the associated set is submitted. - -### Active set benefits - -Once a set is active: - -- Requests from sites in the set (via {{domxref("Document.requestStorageAccess()")}}) to access third-party cookies and unpartitioned state that belong to sites in the set are automatically granted, and no user permission step is required. -- {{domxref("Document.requestStorageAccessFor()")}} calls can be made from top-level sites in the set to request third-party cookie access for other sites in the set. - -## RWS security - -RWS has been designed with security in mind. It would be disastrous if a bad actor site were able to claim to be part of a set and gain the privileges that entails. Lets consider a theoretical bad actor site, `evilsite.example.com`, and look at some examples of attacks it could try to make, all of which would fail: - -- **`evilsite.example.com` claims to be an associated site in another set**: If a site claiming to be in a set (i.e., by listing a primary in a `.well-known` file) is not included in the set submission and/or primary's `.well-known` file, it won't get the benefits of being in the set. -- **`evilsite.example.com` claims to be a primary site, and submits a set that includes some would-be victim sites**: The submission process requires that `.well-known` files hosted by non-primary sites explicitly list out their primary. If this primary doesn't match the set submission (i.e., if the associated/service sites expect to have a different primary, or don't expect to be in a set at all), the submission will be rejected. -- **`site1.example.com` and `site2.example.com` are intentionally in the same set, but `site1.example.com` gets hijacked by `evilsite.example.com`**: The impact of a site hijacking attack within a set isn't any worse than it would usually be, once the other sites are updated accordingly: - - The regular [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) requires an active opt-in by the embedded site, so `site2.example.com` can stop calling `document.requestStorageAccess()` when it's embedded in `site1.example.com`, avoiding a {{glossary("CSRF")}} attack. - - Use of `requestStorageAccessFor()` requires [CORS](/en-US/docs/Web/HTTP/Guides/CORS), so `site2.example.com` could choose not to respond with the appropriate CORS headers when network requests are coming from `site1.example.com`, thereby avoiding a CSRF attack. - -## Examples - -For code examples, see [Related Website Sets: developer guide](https://privacysandbox.google.com/cookies/related-website-sets-integration) on privacysandbox.google.com (2024) - -## Specifications - -{{Specifications}} - -### Standards positions - -Two browser vendors [oppose](/en-US/docs/Glossary/Web_standards#opposing_standards) this specification. Known positions are as follows: - -- Mozilla (Firefox): [Negative](https://mozilla.github.io/standards-positions/#first-party-sets) -- Apple (Safari): [Negative](https://webkit.org/standards-positions/#position-93) - -## See also - -- [Storage Access API](/en-US/docs/Web/API/Storage_Access_API) -- [Related Website Sets](https://privacysandbox.google.com/cookies/related-website-sets) on privacysandbox.google.com (2023) diff --git a/files/en-us/web/api/storage_access_api/using/index.md b/files/en-us/web/api/storage_access_api/using/index.md index ae8316be2557a3e..21b606b8eab1d8c 100644 --- a/files/en-us/web/api/storage_access_api/using/index.md +++ b/files/en-us/web/api/storage_access_api/using/index.md @@ -117,7 +117,7 @@ async function handleCookieAccess() { ### Related website sets -The Chrome-only [related website sets](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets) feature can be considered a progressive enhancement mechanism that works alongside the Storage Access API — supporting browsers grant default third-party cookie and unpartitioned state access between websites in the same set. This means not having to go through the usual user permission prompt workflow described above, meaning a more user-friendly experience for users of sites in the set. +The Chrome-only [related website sets](https://privacysandbox.google.com/cookies/related-website-sets-integration) feature can be considered a progressive enhancement mechanism that works alongside the Storage Access API — supporting browsers grant default third-party cookie and unpartitioned state access between websites in the same set. This means not having to go through the usual user permission prompt workflow described above, meaning a more user-friendly experience for users of sites in the set. ## Requesting storage access from the top-level site on behalf of embedded resources @@ -125,7 +125,7 @@ The Storage Access API features above allow an embedded document to request its The `requestStorageAccessFor()` method addresses challenges in adopting the Storage Access API on top-level sites that use cross-site images or scripts requiring cookies. It can enable third-party cookie access for cross-site resources directly embedded into the top-level site that are unable to request their own storage access, for example via {{htmlelement("img")}} or {{htmlelement("script")}} elements. -For `requestStorageAccessFor()` to work, both the calling top-level page and the embedded resource it is requesting storage access for need to be part of the same [related website set](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets). +For `requestStorageAccessFor()` to work, both the calling top-level page and the embedded resource it is requesting storage access for need to be part of the same [related website set](#related_website_sets). Typical usage of `requestStorageAccessFor()` looks like this (this time written in regular promise-style rather than async/await): diff --git a/files/en-us/web/api/webtransport/datagrams/index.md b/files/en-us/web/api/webtransport/datagrams/index.md index 9a69f12c600b3c0..6f9b9562dfc8283 100644 --- a/files/en-us/web/api/webtransport/datagrams/index.md +++ b/files/en-us/web/api/webtransport/datagrams/index.md @@ -20,13 +20,21 @@ A {{domxref("WebTransportDatagramDuplexStream")}} object. ### Writing an outgoing datagram -The {{domxref("WebTransportDatagramDuplexStream.writable")}} property returns a {{domxref("WritableStream")}} object that you can write data to using a writer, for transmission to the server: +This code uses the {{domxref("WebTransportDatagramDuplexStream.createWritable", "createWritable()")}} method, if it is supported, to get a {{domxref("WebTransportDatagramsWritable")}} instance that can be used for writing data to the transport. +Otherwise, it falls back to the {{domxref("WebTransportDatagramDuplexStream/writable", "writable")}} property {{deprecated_inline}} {{non-standard_inline}}, which returns a {{domxref("WritableStream")}} object that you can write data to using a writer, for transmission to the server: ```js -const writer = transport.datagrams.writable.getWriter(); +const writableStream = + typeof transport.datagrams.createWritable === "function" + ? transport.datagrams.createWritable() + : transport.datagrams.writable; // Deprecated and non-standard. + +const writer = writableStream.getWriter(); const data1 = new Uint8Array([65, 66, 67]); const data2 = new Uint8Array([68, 69, 70]); +await writer.ready; writer.write(data1); +await writer.ready; writer.write(data2); ``` diff --git a/files/en-us/web/api/webtransportdatagramduplexstream/index.md b/files/en-us/web/api/webtransportdatagramduplexstream/index.md index 4dae43ea62e8f01..7feaadefa5d4025 100644 --- a/files/en-us/web/api/webtransportdatagramduplexstream/index.md +++ b/files/en-us/web/api/webtransportdatagramduplexstream/index.md @@ -36,13 +36,21 @@ This is accessed via the {{domxref("WebTransport.datagrams")}} property. ### Writing outgoing datagrams -The {{domxref("WebTransportDatagramDuplexStream.writable", "writable")}} property returns a {{domxref("WritableStream")}} object that you can write data to using a writer, for transmission to the server: +This code uses the {{domxref("WebTransportDatagramDuplexStream.createWritable", "createWritable()")}} method, if it is supported, to get a {{domxref("WebTransportDatagramsWritable")}} instance that can be used for writing data to the transport. +Otherwise, it falls back to the {{domxref("WebTransportDatagramDuplexStream/writable", "writable")}} property {{deprecated_inline}} {{non-standard_inline}}, which returns a {{domxref("WritableStream")}} object that you can write data to using a writer instead: ```js -const writer = transport.datagrams.writable.getWriter(); +const writableStream = + typeof transport.datagrams.createWritable === "function" + ? transport.datagrams.createWritable() + : transport.datagrams.writable; // Deprecated and non-standard. + +const writer = writableStream.getWriter(); const data1 = new Uint8Array([65, 66, 67]); const data2 = new Uint8Array([68, 69, 70]); +await writer.ready; writer.write(data1); +await writer.ready; writer.write(data2); ``` diff --git a/files/en-us/web/html/reference/attributes/index.md b/files/en-us/web/html/reference/attributes/index.md index 90c588fe322274d..13744a6faf82911 100644 --- a/files/en-us/web/html/reference/attributes/index.md +++ b/files/en-us/web/html/reference/attributes/index.md @@ -101,7 +101,7 @@ Elements in HTML have **attributes**; these are additional values that configure All elements - Modifies an element's state or properties in the accessibility tree. Applicability depends on the specific ARIA attribute. + Modifies an element's state or properties in the accessibility tree. Applicability depends on the specific ARIA attribute. diff --git a/files/en-us/web/privacy/guides/privacy_sandbox/index.md b/files/en-us/web/privacy/guides/privacy_sandbox/index.md index f048f75cab6022f..d02efa5629ab046 100644 --- a/files/en-us/web/privacy/guides/privacy_sandbox/index.md +++ b/files/en-us/web/privacy/guides/privacy_sandbox/index.md @@ -23,7 +23,7 @@ Google's **privacy sandbox** project is a series of proposals to satisfy cross-s - : Provides functionality for controlling content embedded in {{htmlelement("fencedframe")}} elements, which enable content to be embedded while solving the privacy issues of {{htmlelement("iframe")}}s. - [Private State Token API](/en-US/docs/Web/API/Private_State_Token_API) - : Provides a mechanism for conveying trust in a user's authenticity from one browsing context to another, without sharing the user's identity or allowing their activity across websites to be tracked. -- [Related website sets](/en-US/docs/Web/API/Storage_Access_API/Related_website_sets) {{deprecated_inline}} +- [Related website sets](https://privacysandbox.google.com/cookies/related-website-sets-integration) {{deprecated_inline}} - : A mechanism for a company to declare relationships between different sites. Supporting browsers will then allow limited third-party cookie access across those sites for specific purposes, via the [Storage Access API](/en-US/docs/Web/API/Storage_Access_API). - [Shared Storage API](/en-US/docs/Web/API/Shared_Storage_API) {{deprecated_inline}} - : A client-side storage mechanism that enables unpartitioned, cross-site data access while preserving privacy (i.e., without relying on tracking cookies). diff --git a/files/jsondata/GroupData.json b/files/jsondata/GroupData.json index a1bd61ea5a5037d..71d34294dc9c327 100644 --- a/files/jsondata/GroupData.json +++ b/files/jsondata/GroupData.json @@ -1610,10 +1610,7 @@ }, "Storage Access API": { "overview": ["Storage Access API"], - "guides": [ - "/docs/Web/API/Storage_Access_API/Using", - "/docs/Web/API/Storage_Access_API/Related_website_sets" - ], + "guides": ["/docs/Web/API/Storage_Access_API/Using"], "interfaces": ["StorageAccessHandle"], "methods": [ "Document.hasStorageAccess()",