Use deprecation flag from BCD

[saschanaz]

Currently MDN has a separate deprecation tag and the header. Could it use the deprecated flag from BCD and autogenerate such header, so that there won't be two separate source of truth?

(BTW, is the Deprecated tag still a thing in Yari? I don't see it rendered anywhere, except the header.)

[ghost]

I did not understand if you intend to pass the data in query string from the links of the BCD to the next page or fetching 2 times the data of the BCD, 1 time for the page and 1 time for the table.

But does the BCD have any services? Where does the data come from?

[saschanaz]

Where does the data come from?

It's from:

yari/package.json

Line 33 in dc823a0

"@mdn/browser-compat-data": "3.0.0",

[ghost]

Intresting issue for do matching things, keys, address in JSON from location of HTML.

So... Should be intresting a little <table> on top of the page for status key.

https://github.com/mdn/browser-compat-data/blob/4c50bfdf43261a67d00b830fb0cd3a316a286400/api/HTMLMarqueeElement.json#L46

Status

Key 0	Key two words	Key 2
false ❌	true 👍	true 👍

See JSON file that contains this object of this table on GitHub

[saschanaz]

I'd rather keep the current design.

• Deprecated header example: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMarqueeElement
  
• Experimental: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/resetTransform
  
• Nonstandard: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWidgetAsOnScreen
  

[ghost]

Ok.
Is possibile and everytimes defined that You can access these 3 booleans knowing only the page URI and the main import of the dependency in the package.json?

[saschanaz]

Yes, it's fairly straightforward. Say the URI is /API/Foo/Bar, the corresponding BCD item is in api.Foo.Bar.

Edit: Maybe this should be a macro like Compat(). (... or should it?)

[ghost]

I like to rename things.

However, I think that by referring to the page some function should return the JSON file and then from there export either the initial div with the status or the BCD in order not to replicate the logic of the mapping between repositories.

I also think about additional services on the feature URL that return fractions of JSON.

API/Foo/Bar/status > returns an object
API/Foo/Bar/status/deprecated > returns a true or false JSON content type.

In any case I can't put comments on the Kumascript linked macro but only on the PRs.

Does BCT data be deployed as is so I can use fetch API?

[saschanaz]

You mean something like this? 👀 https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWidgetAsOnScreen/bcd.json

[ghost]

Questionable because we see that it was born for compatibility (support) and has more status and there is also something that speaks of HTML h3 of 6 titles 🤔

I imagine something similar but slightly revised to represent the page and therefore also the support table as a child of a big feature object.

Feature.method()

Status

... a table from an object ...

Content

...

Support

... a table from an object ...

[ghost]

Could this data pass via some meta before going to the article?

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta

[saschanaz]

I think fetching twice is okay as the response will be cached.

[ghost]

Draft of a PR

// We are in some lifecyle hook
fetch(Object.assign(new URL("https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawWidgetAsOnScreen/bcd.json"), {
// Something known in the global scope like properties from an URL object constructed from location
})
.then(response=>response.json())
.then(body=>{
 // Todo update the state of the component with the status Key and some if statments here or in the template 
this.status = body.status // Is here or more in depth?
})

This should be done in the Component or at App level and passed down via props.

(I can't PR or assign this issue to me just comment, I'm sorry).

[schalkneethling]

@ddbeck Thoughts? Close?

[ddbeck]

@schalkneethling There's a bit to unpack here. This discussion captures some of the issues involved: https://github.com/mdn/content/discussions/5549. That said, the underlying idea—drive this stuff from BCD—is a good idea. But there's two distinct tasks that would come from this:

• Generate usage ("traffic light") banners based on support and statuses (standard track, experimental, and deprecated). This would be a bit of a content/design/engineering effort.
• Remove existing macros and tags. A content effort, after the previous step.

Not sure if we should open separate issues, hijack this one, or what. Also related: #1400 (comment)

[schalkneethling]

@ddbeck Almost sounds like creating 2 separate issues with a clear definition of work makes more sense. We can the prioritise them along with all of the other items we have. Not sure who the best person is to create those but, I have a suspicion it might be you 😄

[caugner]

Closing in favor of duplicate #3929.