Replace inline status macros (Deprecated_Inline, Experimental_Inline, Non-standard_Inline)

[caugner]

The Web APIs docs uses inline status macros to indicate to users whether a listed feature is deprecated, experimental, or non-standard (see here).

Currently, this requires a scheduled workflow run by @OnkarRuikar that syncs the content with BCD releases, by adding or removing inline macros where necessary. (Note: It also manages the status: frontmatter value.)

In this comment, Onkar cites the sync_bcd.yml workflow in OnkarRuikar/temp that runs daily, executes the minified script in this Gist applying the changes, and opens a content PR.

While this workflow works, it updates the content, and therefore requires manual changes in translated-content to reflect the updates statuses.

Overall, it seems better if this was more dynamically handled in Rari itself.

One solution I have in mind is to add a StatusInline macro that takes a BCD key as parameter:

{{StatusInline('api.ShadowRoot.referenceTarget')}}

The advantage of this is that this creates a clear link between an item in content and a BCD feature, and would allow to show Baseline statuses in the feature, without requiring content updates.

PS: Although the ReadOnlyInline parameter does not indicate a status, and is mostly stable, one could imagine introducing an APIStatusInline macro that adds both the read-only indicator (if deducible from IDL), and the status indicators. However, this wouldn't work for non-standard features, because they don't appear in any IDL.

[OnkarRuikar]

Can we increase the scope to consider all three status indicators that the workflow(sync bot) handles:

• frontmatter status key (used for adding status icons to left sidebar)
• header status macros
• inline status macros

For details of all the status indicators, refer How are feature statuses specified in content? section.

---

Overall, it seems better if this were more dynamically handled in Rari itself.

👍 We have been waiting for this for a very long time. Status micros inside the content are hard to maintain(mostly keeping up-to-date is a big issue). Also, we manually removed all the inline status macros from paragraphs and 'see also' lists because they were hard to track and maintain, and most of them were outdated.

---

One solution I have in mind is to add a StatusInline macro that takes a BCD key as a parameter:

There are thousands of definition lists in the content, each containing multiple list items. Adding a macro and a personalized BCD query to each will be a cumbersome task. Also, authors won't like it to add a macro with BCD query for each item in the definition list.

I think we could approach it like the following:
Rari code should use the browser-compat frontmatter value to get statuses from BCD json, and not read it from the page's status frontmatter values.

a. Header banners; Render header banners directly using BCD. This would allow us to get rid of the three header macros: {{Deprecated_Header}}, {{SeeCompatTable}}, {{Non-standard_Header}}.
b. Sidebar statuses: While rendering a sidebar rari code looks at each feature's page to get the status to put an icon next to the list entry. The rari code needs to look at browser-compat frontmatter value instead of the status frontmatter value. This would allow us to get rid of the status frontmatter key.
c. Inline statuses: Do not explicitly mark all the definition terms, instead figure out all the definition terms in def lists and populate badges. Here is how the bot handles it:

1. Get all the feature items covered in the BCD data point pointed by the browser-compat query.

2. In our content, the definition terms(<dt>) are specified in a fixed manner:

   - `positionX`
     - : ...
   - `"souce_debug_key"`
     - : ...
   - {{domxref("AudioListener.positionX")}}
     - : ...
   - [positionX](/en-us/docs/...)
     - : ...

   Use regex to find all the locations of the above found feature items in definition lists. This would be way easier in Rari code with the compiled document and Cheerio querying.

3. Populate/update statue badges using BCD data.

   Note: If a definition item is status marked using browser-compat query, but the author wants to override and use status from other BCD location, then we can use the overriding macro call InlineStatuses("api.a.common.name.feature") to mark the definition term.