Fallback for missing BCD data

[jpmedley]

Is your feature request related to a problem? Please describe. Sometimes it's desirable to use the new BCD widget in before the data is available on MDN. (See this PR for an example.)

Describe the solution you'd like It would be useful if we could pass a fallback value to the widget for missing data. In the example PR above, we know the feature is shipping in Chrome 94 because the intent has it's three LGTMs. We just don't know when this information will be available in MDN's BCD database.

Describe alternatives you've considered A few options:

• Try to remember weeks from now that we need to go back update a web.dev article.
• We could also pass the widget something more vague than a number, something like an argument that will make it render "Complete" until the data is available.

Additional context Long-term, I'm worried about the accumulation of places where Fugu-style progress tables should be replaced but aren't. A feature like this would allow authors to update articles at what is for them the most convenient time. The linked PR is an example of this.

[jpmedley]

cc: @tomayac

[tomayac]

Thanks for looping me in, @jpmedley! @devnook, I think a fallback that expresses somehow that compatibility data is pending would make the most sense. Like that the widget would just magically update once the data becomes available.

[jpmedley]

"Pending" would imply that we're working on it. The fact is that "Pending" could be up months if no one can find time to prioritize BCD. That could also be misread as "it will be in Chrome, but not yet."

I'm trying to address a very narrow issue: we know a feature will be in a specific version because it has the required approvals.

[tomayac]

If "pending" raises hopes to high, maybe just displaying "n/a" in the widget could work.

[jpmedley]

And what does that mean?

[tomayac]

That no browser compatibility data is available (yet). ¯_(ツ)_/¯

[jpmedley]

Let me back up. How many times have you found an outdate piece of information in an article that you should have fixed months or even years ago? It's a chronic problem in documentation. I'm making a suggestion to mitigate rather than adding to it.

[tomayac]

I think we're talking past another. What I'm suggesting is the following:

• You know that BCD data will be available at api.FooInterface.
• You enter this info into @devnook's widget {% BrowserCompat 'api.FooInterface' %} and place the widget in an article about FooInterface.
• At build time, the widget notices there's no data yet, and, instead of a browser version number, writes N/A for the time being.
• Months pass…
• BCD now has data, and automagically the widget starts to display the support data as 95 or whatever.

[jpmedley]

I don't think we are. If you as the writer know the number, why not just enter it? I think you're assuming that the BCD will be updated in a timely manner. Based on experience, I'm telling you that that is not even remotely a safe assumption.

You can easily say, well the writer should remember to check BCD and open a PR if it's not there. Add that to the list of 1000 other things writers should remember to do each time. Then try to remember those 1001 things when you're in a rush to finish something for IO or CDS. Generally, 'remember to go back and fix it' is not a good strategy for documentation. This is why I always ask you to replace 'currently' with a specific Chrome version and why Pete organizes regular doc fixits for PWA.

[samthor]

To chime in as TL, I think something like "Not available" makes sense here, perhaps with a local build-time warning that something is missing (so if we end up with 100s it's interesting, rather than a harsher build failure).

It's also possible that BCD data goes away, say for a very old API.

[devnook]

Re: "You know that BCD data will be available at api.FooInterface."

Is it usual that we know exactly where the FooInterface will end up? e.g. Tat it will not go into api.someSubsection.FooInterface?

I'm sorry if I ask an uninformed question, but this is key to decide if we allow such widget to render or we discard it as incorrect.

[tomayac]

My understanding is that the names are directly based on the IDL from the spec, for example, PeriodicSyncManager, which is then used for the compatibility table.

[jpmedley]

This pattern is always api.InterfaceName.[memberName]. It seems unlikely that the keys would ever move since this matches the structure of APIs, the structure of IDL files, and the site structure of MDN itself.

[jpmedley]

These keys appear on every API reference page. For MDN to ever change this would be enormously painful.

[jpmedley]

@samthor Think about what a page might potentially look like if you say "Not Available". You could have text in the article itself, maybe next to the macro, mentioning a version number. Readers will just scratch their heads and say, "What?". I don't think we can absolutely exclude such references from the text. As soon as we say that, we'll start running into cases where it makes no sense.

[rachelandrew]

Given that we are moving all experimental content to DCC, I think that there should not be new instances on web.dev where the widget has no data. So it may not be worth working on a fallback.

[jpmedley]

Isn't @devnook working on feature parity between the two sites? Wouldn't that mean common code between the two sites? Are you saying we would never use this widget on an in-development feature?

[jpmedley]

Do I need to transfer this ticket to dcc?

[rachelandrew]

I don't think it's useful for an experimental feature as you already outlined. On DCC they are more likely to have the kind of status table we use (as things progress through origin trial etc.) so I think it's likely a case of this is a web.dev feature, for things with stable browser support.

[jpmedley]

I disagree. As new features progress actual data will gradually override the fallback data. We won't need to do anything.

[jpmedley]

I opened this ticket specifically because this macro has utility in cutting edge features.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. To prevent this from happening, leave a comment.

[tomayac]

The bot is about to close this. Have we come to a conclusion? It sounds like migrating the ticket to the DCC is the short-term thing to do.

[rachelandrew]

Commenting removes the stale flag, I think it's fine to leave here for now. Whatever we do with the widget is likely to apply to both sites anyway as we're trying to make all the components the same.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. To prevent this from happening, leave a comment.