Using front matter properties instead of macros for displaying banners

[leon-win]

Hi all!

Recently I've been working on synchronizing the use of some macros in translations. This is a rather monotonous and necessary process)) Therefore, the idea arose to improve/automate the work with some macros.

I started looking for information about this problem and found (https://github.com/orgs/mdn/discussions/199#discussioncomment-618185, mdn/yari#350), but could not understand what conclusions we came to and why we were unable to implement such automation.

Therefore, once again I propose to consider the following:

1. Use information from the front matter instead of macros

Use information from the front matter status property instead of manually calling {{SeeCompatTable}}, {{Non-standard_Header}} and {{Deprecated_Header}} macros to display appropriate banners.

Advantages:

1. We remove duplication of information: now it is in front matter and in macros, but it will only be in front matter;
2. We simplify the synchronization of translations: in mdn/translated-content there is no need to monitor the appearance/deletion of a macro in mdn/content.

Are there any advantages to manually adding banners?
Could there be a situation where the document has status.experimental, but we don't want to display the {{SeeCompatTable}} banner (or vice versa)?

2. Add new front matter properties

Add new front matter properties to replace the {{AvailableInWorkers}} and {{SecureContext_Header}} macros and proceed by analogy with point 1.

[bsmth]

Thanks a lot for raising this one. There's a related discussion here about where to put inline macros: https://github.com/orgs/mdn/discussions/654 and I think moving this data up into front matter has come up before in discussion: https://github.com/orgs/mdn/discussions/254#discussioncomment-4232611

There is a lot of work ongoing relating to banners happening at the moment (availability in workers, experimental/status, baseline, etc.) and defining these via front-matter is going to be a consideration to help with authoring. I think we can bring this up again in the next community call to get some more feedback on it.

Also relating to manually adding these macros, it might be worth checking with @OnkarRuikar if there's any overlap, since there is automation to add these in en content:

• mdn/content@cb1c745#diff-27f9c519a0b44b678486d689ad20dea75756493d673497764f6daa1620b3ef64R43

• Synchronize with BCD v5.5.25 content#33405

[ferdnyc]

The only thing I can think of that would be a barrier to this, is that macros have the added flexibility that they can appear anywhere on the page.

See, for example, https://developer.mozilla.org/en-US/docs/Web/API/DataTransfer

The source in mdn/content/files/en-us/web/api/datatransfer/index.md, has a {{SeeCompatTable}} on line 36 of the file, under the ### Gecko properties heading.

Of course, it also doesn't have the banner listed in the front matter. So if the macros are still available, and the change is just to make them automatic/unnecessary on pages where they're redundant with the front matter, then maybe that's good enough. The macro could just be left as-is, on that particular page.

I believe that would defeat Advantage 2, tho.

[OnkarRuikar]

The issue is not about just inline status macros; it is also related to left sidebar status icons, which are derived from front-matter status properties. And the front-matter status properties are derived from BCD. BCD is the single source of truth.

---

Also relating to manually adding these macros, it might be worth checking with @OnkarRuikar if there's any overlap, since there is automation to add these in en content:

The BCD synchronisation automation covers only mdn/content repo. Unfortunately for other repos it has to be done manually. The automation is a stopgap solution till mdn/yari implements it using BCD data.

---

In the past discussions (on GitHub or in chat rooms), everyone agreed that inline and sidebar status icons should be handled by the yari platform directly using BCD data from mdn/browser-compat-data repo. At the moment yari is undergoing massive restructuring. So this major change may not be taken up for another year.