fix(docs): add a page describing everyging about standardization stat…

…uses

files/en-us/mdn/writing_guidelines/experimental_deprecated_obsolete/index.md

@@ -20,7 +20,7 @@ For a technology marked **experimental**, one or more of the following condition
 - It is only supported through configuration changes such as preferences or flags, regardless of the number of supported rendering engines.
 - Its defining specification is likely to change significantly in backwards-incompatible ways (i.e., it may break existing code that relies on the feature).
 
-> **Note:** A feature that is only released on one rendering engine is still considered experimental even if it is available on preview builds of other rendering engines (or by setting a preference or flag).
+> **Note:** A feature released only on one rendering engine is still considered experimental even if it is available on preview builds of other rendering engines (or by setting a preference or flag).
 
 The **experimental** status of a technology may expire if one or more of the following conditions is met:
 
@@ -72,14 +72,7 @@ If the item was _never_ implemented in a release version of _any_ browser, not e
 
 If the item was implemented in any release version of any one or more browsers but _only_ behind a preference or a flag, do not delete the item from the documentation immediately. Instead, mark the item as **deprecated** as follows:
 
-- If the item has any documentation pages describing only that one item (such as {{domxref("RTCPeerConnection.close()")}}), add the [`deprecated_header`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Header.ejs) macro to the top of the page and add the following `status:` front-matter entry:
-
-  ```yaml
-  status:
-    - deprecated
-  ```
-
-- On the overview page for the element, interface, or API, find the list of items that includes the item that's been removed from the specification and add the [`deprecated_inline`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Inline.ejs) macro after the item's name in that list.
+- Update the status data in `browser-compat-data` repository by [submitting a pull request](https://github.com/mdn/browser-compat-data/blob/main/docs/contributing.md#updating-the-compat-data) to the repository.
 - Search the informative text of the overview page for that interface, element, etc., for any references to the removed item. Add warning boxes in appropriate places with text along the lines of "\[item] has been removed from the specification and will be removed from browsers soon. See \[link to page] for a new way to do this."
 - Similarly, look for any discussion of the item in the guides and tutorials about the relevant API or technology. Add similar warnings.
 - Search MDN Web Docs for references to the removed item, in case there are discussions elsewhere. Add similar warning boxes there as well.
@@ -90,14 +83,7 @@ If the item was implemented in any release version of any one or more browsers b
 
 If the item was implemented in one or more release builds of browsers without requiring a preference or a flag, mark the item as **deprecated**, as follows:
 
-- If the item has any documentation pages describing only that one item (such as {{domxref("RTCPeerConnection.close()")}}), add the [`deprecated_header`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Header.ejs) macro to the top of the page and add the following `status:` front-matter entry:
-
-  ```yaml
-  status:
-    - deprecated
-  ```
-
-- On the overview page for the element, interface, or API, find the list of items that includes the item that's been removed from the specification and add the [`deprecated_inline`](https://github.com/mdn/yari/blob/main/kumascript/macros/Deprecated_Inline.ejs) macro after the item's name in that list.
+- Update the status data in `browser-compat-data` repository by [submitting a pull request](https://github.com/mdn/browser-compat-data/blob/main/docs/contributing.md#updating-the-compat-data) to the repository.
 - Search the informative text of the overview page for that interface, element, etc., for any references to the removed item. Add warning boxes in appropriate places with text along the lines of "\[item] has been removed from the specification and is deprecated. It may be removed from browsers in the future, so you should not use it. See \[link to page] for a new way to do this."
 - Similarly, look for any discussion of the item in the guides and tutorials about the relevant API or technology. Add similar warnings.
 - Search MDN Web Docs for references to the removed item, in case there are discussions elsewhere. Add similar warning boxes there as well.
@@ -117,3 +103,7 @@ For example, as of Jan 2019, the [`inputmode`](/en-US/docs/Web/HTML/Global_attri
 > **Warning:** Specification conflict: The WHATWG specification lists [`inputmode`](https://html.spec.whatwg.org/multipage/interaction.html#attr-inputmode) and modern browsers are working towards supporting it.
 > The [W3C HTML 5.2 spec](https://html.spec.whatwg.org/multipage/index.html#contents), however, no longer lists it (i.e. marks it as obsolete).
 > You should consider the WHATWG definition as correct, until a consensus is reached.
+
+## See also
+
+- [Standardization status macros](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status)

files/en-us/mdn/writing_guidelines/howto/write_an_api_reference/index.md

@@ -68,7 +68,7 @@ Before you start you should write down a list of all the pages you should create
 
 #### Overview pages
 
-A single API overview page is used to describe the role of the API, its top-level interfaces, related features contained in other interfaces, and other high level details.
+A single API overview page is used to describe the role of the API, its top-level interfaces, related features contained in other interfaces, and other high-level details.
 Its name and slug should be the name of the API plus "API" on the end. It is placed at the top level of the API reference, as a child of [https://developer.mozilla.org/en-US/docs/Web/API](/en-US/docs/Web/API).
 
 Example:
@@ -107,7 +107,7 @@ Examples:
 
 #### Constructor pages
 
-Each interface has 0 or 1 constructors, documented on a subpage of the interface's page. It describes the purpose of the constructor and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the constructor, which is exactly the same as the interface name, and the title is interface name, dot, constructor name, then parentheses on the end.
+Each interface has zero or one constructors, documented on a subpage of the interface's page. It describes the purpose of the constructor and shows what its syntax looks like, usage examples, browser compatibility information, etc. Its slug is the name of the constructor, which is exactly the same as the interface name, and the title is interface name, dot, constructor name, then parentheses on the end.
 
 Example:
 
@@ -145,7 +145,7 @@ Examples:
 
 #### Event pages
 
-Document events as sub pages of their target interfaces and use the slug _eventname_\_event with the title set to `Interface: eventName event`.
+Document events as subpages of their target interfaces and use the slug _eventname_\_event with the title set to `Interface: eventName event`.
 
 Don't create pages for `on` event handler properties. Mention both ways to access the event on the `eventName_event` page.
 
@@ -229,12 +229,7 @@ Now you should be ready to start writing your interface pages. Each interface re
 
 1. **\\{{APIRef}}**: Include the \\{{APIRef}} macro in the first line of each interface page, including the name of the API as an argument, so for example \\{{APIRef("Web Audio API")}}. This macro serves to construct a reference menu on the left-hand side of the interface page, including properties and methods, and other quick links as defined in the [GroupData](https://github.com/mdn/content/blob/main/files/jsondata/GroupData.json) macro (ask someone to add your API to an existing GroupData entry, or to create a new one, if it isn't already listed there). The menu will look something like the below screenshot.
    ![This screenshot shows a vertical navigation menu for the OscillatorNode interface, with multiple sublists for methods and properties, as generated by the APIRef macro ](apiref-links.png)
-2. **Standardization status**: The banner indicating the standardization status should be added next (these can be placed on the same line as the \\{{APIRef}} macro.):
-
-   - \\{{SeeCompatTable}} for an experimental feature (i.e. the spec is not at the CR level.)
-   - \\{{Deprecated_header}}
-   - \\{{Non-standard_header}}
-
+2. **Standardization status**: The [banner indicating the standardization status](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#standardization_status_page_banners) is [automatically added](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#how_to_add_or_update_standardization_statuses). For that you need to [update the status in `browser-compat-data` repository](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#how_to_add_or_update_standardization_statuses).
 3. **Description**: the first paragraph of the interface page should provide a short concise description of the interface's overarching purpose. You may also want to include a couple more paragraphs if any additional description is required. If the interface is actually a dictionary, you should use that term instead of "interface".
 4. **Inheritance diagram:** Use the [`\{{InheritanceDiagram}}`](https://github.com/mdn/yari/blob/main/kumascript/macros/InheritanceDiagram.ejs) macro to embed an SVG inheritance diagram for the interface.
 5. **List of properties, List of methods**: These sections should be titled "Properties" and "Methods", and provide links (using the \\{{domxref}} macro) to a reference page for each property/method of that interface, along with a description of what each one does. These should be marked up using [description/definition lists](/en-US/docs/MDN/Writing_guidelines/Howto/Markdown_in_MDN#definition_lists). Each description should be short and concise — one sentence if possible. See the "Referencing other API features with the \\{{domxref}} macro" section for a quicker way to create links to other pages.
@@ -277,13 +272,9 @@ Property pages must have the following sections:
 1. **Title**: the title of the page must be **InterfaceName.propertyName**. The interface name must start with a capital letter. Although an interface is implemented in JavaScript on the prototype of objects, we don't include `.prototype.` in the title, like we do in the [JavaScript reference](/en-US/docs/Web/JavaScript/Reference).
 2. **\\{{APIRef}}**: Include the \\{{APIRef}} macro in the first line of each property page, including the name of the API as an argument, so for example \\{{APIRef("Web Audio API")}}. This macro serves to construct a reference menu on the left-hand side of the interface page, including properties and methods, and other quick links as defined in the [GroupData](https://github.com/mdn/content/blob/main/files/jsondata/GroupData.json) macro (ask someone to add your API to an existing GroupData entry, or to create a new one, if it isn't already listed there). The menu will look something like the below screenshot.
    ![This screenshot shows a vertical navigation menu for the OscillatorNode interface, with multiple sublists for methods and properties, as generated by the APIRef macro ](apiref-links.png)
-3. **Standardization status**: The banner indicating the standardization status should be added next to the interface name (these can be placed on the same line as the \\{{APIRef}} macro):
+3. **Standardization status**: The [banner indicating the standardization status](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#standardization_status_page_banners) is [automatically added](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#how_to_add_or_update_standardization_statuses). For that you need to [update the status in `browser-compat-data` repository](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#how_to_add_or_update_standardization_statuses).
 
-   - \\{{SeeCompatTable}} for an experimental feature (i.e. the spec is not at the CR level.)
-   - \\{{Deprecated_header}}
-   - \\{{Non-standard_header}}
-
-4. **Description**: the first paragraph of the property page should provide a short, concise description of the property's overarching purpose. You may also want to include a couple more paragraphs if any additional description is required. Obvious extra information to include is its default/initial value, and whether it's read only or not. The structure of the first sentence must be:
+4. **Description**: the first paragraph of the property page should provide a short, concise description of the property's overarching purpose. You may also want to include a couple more paragraphs if any additional description is required. Obvious extra information to include is its default/initial value, and whether it's read-only or not. The structure of the first sentence must be:
 
    - For read-only properties
      - : The **`InterfaceName.property`** read-only property returns a \\{{domxref("type")}} that…
@@ -315,11 +306,7 @@ Method pages need the following sections:
 1. **Title**: the title of the page must be **InterfaceName.method()** (with the two terminal parentheses), but the slug (the end of the page URL) must not include the parentheses. Also the interface name must start with a capital. Although an interface is implemented in JavaScript on the prototype of objects, we don't put `.prototype.` in the title, like we do in the [JavaScript reference](/en-US/docs/Web/JavaScript/Reference).
 2. **\\{{APIRef}}**: Include the \\{{APIRef}} macro in the first line of each method page, including the name of the API as an argument, so for example \\{{APIRef("Web Audio API")}}. This macro serves to construct a reference menu on the left-hand side of the interface page, including properties and methods, and other quick links as defined in the [GroupData](https://github.com/mdn/content/blob/main/files/jsondata/GroupData.json) macro (ask someone to add your API to an existing GroupData entry, or to create a new one, if it isn't already listed there). The menu will look something like the below screenshot.
    ![This screenshot shows a vertical navigation menu for the OscillatorNode interface, with multiple sublists for methods and properties, as generated by the APIRef macro ](apiref-links.png)
-3. **Standardization status**: Next, the banner indicating the standardization status should be added (these can be placed on the same line as the \\{{APIRef}} macro):
-
-   - \\{{SeeCompatTable}} for an experimental feature (i.e. the spec is not at the CR level.)
-   - \\{{Deprecated_header}}
-   - \\{{Non-standard_header}}
+3. **Standardization status**: The [banner indicating the standardization status](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#standardization_status_page_banners) is [automatically added](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#how_to_add_or_update_standardization_statuses). For that you need to [update the status in `browser-compat-data` repository](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#how_to_add_or_update_standardization_statuses).
 
 4. **Description**: The first paragraph of the method page should provide a short concise description of the method's overarching purpose. You may also want to include a couple more paragraphs if any additional description is required. Obvious extra information to include is its default parameter values, any theory that the method relies on, and what the parameter values do.
 

files/en-us/mdn/writing_guidelines/page_structures/banners_and_notices/index.md

@@ -9,42 +9,45 @@ page-type: mdn-writing-guide
 Banners are added to some pages, in particular API reference, in order to highlight important factors that will affect how the described content is used.
 For example, banners are used to highlight when a particular interface, method or property is deprecated, and should not be used in production code.
 
-This article describes the more important banners, and how they are added.
+This article describes the more important banners and how they are added.
 
 ## How to add a banner
 
 Banners are added using macros.
-Banners macros should be inserted below the page metadata, alongside the page sidebar macro.
-For example, the `\{{SeeCompatTable}}` macro is added below to indicate that the [Ink API](/en-US/docs/Web/API/Ink_API) is [Experimental](/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete#experimental).
+Banner macros should be inserted below the page metadata, alongside the page sidebar macro.
+For example,
+the `\{{SecureContext_Header}}` macro has been used
+to indicate
+that the [Bluetooth API](/en-US/docs/Web/API/Bluetooth) is only available in a [secure context](/en-US/docs/Web/Security/Secure_Contexts).
 
 ```md
 ---
-title: Ink API
-slug: Web/API/Ink_API
-page-type: web-api-overview
+title: Bluetooth
+slug: Web/API/Bluetooth
+page-type: web-api-interface
 status:
   - experimental
-browser-compat: api.Ink
+browser-compat: api.Bluetooth
 ---
 
-\{{DefaultAPISidebar("Ink API")}}\{{SeeCompatTable}}
+\{{APIRef("Bluetooth API")}}\{{SecureContext_Header}}
 ```
 
 A page that has a banner will usually also have "complementary" page metadata.
-For example, a page that has `\{{SeeCompatTable}}` should usually have the `experimental` status added too (as shown above) to ensure that it has appropriate icons in the sidebar.
+For example, a page that has `\{{Compat}}` should usually have the `browser-compat` property added in front-matter.
 
 > **Note:** Banner macros do not _depend_ on the metadata, but some other macro-inserted content does.
 > For example, the `\{{Compat}}` macro depends on the `browser-compat` metadata value.
 
-## What banners can/should be added
+## What banners are/should be added
 
 The [Page type templates](/en-US/docs/MDN/Writing_guidelines/Page_structures/Page_types#templates) include the most important macros.
 In summary:
 
 - `\{{SeeCompatTable}}` — generates a **This is an experimental technology** banner that indicates the technology is [experimental](/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete#experimental).
-  Also add `status` of `experimental` to the page front-matter.
 - `\{{Deprecated_Header}}` — generates a **Deprecated** banner that indicates that use of the technology is [discouraged](/en-US/docs/MDN/Writing_guidelines/Experimental_deprecated_obsolete#deprecated).
-  Also add `status` of `deprecated` to the page front-matter.
 - `\{{Non-standard_Header}}` — generates a **Non-Standard** banner that indicates that use of the technology is not part of a formal specification, even if it is implemented in multiple browsers.
-  Also add `status` of `non-standard` to the page front-matter.
 - `\{{SecureContext_Header}}` — this generates a **Secure context** banner that indicates the technology is only available in a [secure context](/en-US/docs/Web/Security/Secure_Contexts).
+
+The first three standardization status related macros in the above list are [automatically added](/en-US/docs/MDN/Writing_guidelines/Page_structures/Standardization_status#how_to_add_or_update_standardization_statuses) to the content.
+Hence, there is no need to add them manually to the content.