Avoid Baseline status for the Array object itself

foolip commented 8 months ago

If we make a new release of web-features including https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/array.yml, https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array will get a Baseline high banner. However, that page talks about some APIs which are only Baseline low, like the of() method and Array.fromAsync().

Excluding the javascript.builtins.Array path from the feature would avoid the problem, but that raises the question of which feature that BCD path should be part of. None at all?

@LeoMcA @fiji-flo what kind of solution would work best for you here? Is it only for pages that have javascript.builtins.Array as its BCD key that you'd like to avoid a Baseline banner for now?

foolip commented 8 months ago

@ddbeck FYI, let's not make a release before we've figured this out.

jgraham commented 8 months ago

It seems like maybe this is a data model problem on the MDN side (with the proviso that I don't know anything about the MDN data model :) ).

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array isn't really a page about a single feature; it's a page that groups together multiple features under the Array object. I think there needs to be a way to account for that on the MDN side rather than trying to map every page to a single BCD key.

Ideally as a user on the Array page I'd like to see multiple statuses; those methods and features which are baseline and especially those subparts which are not.

Elchi3 commented 8 months ago

I agree with James. Array as a whole has multiple statuses and a renderer could decide to do something about that.

I think there are (at least) three situations for MDN:

1) Exact match between an MDN page's compat table and a web-features list

Two examples for this situation:

Example 1: web-features defines a group of just one feature:

BCD: javascript.builtins.Array.fromAsync
web-features: https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/array-fromasync.yml
MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/fromAsync#browser_compatibility

Example 2: web-features defines a bundle consisting of all of an interface's members

BCD: api.BroadcastChannel.*
web-features: https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/broadcast-channel.yml
MDN: https://developer.mozilla.org/en-US/docs/Web/API/BroadcastChannel#browser_compatibility

(I believe that there are currently no issues with this situation on MDN.)

2) An MDN page's compat table lists more than in a web-features list

Example for this one is the array situation that Philip outlines above:

BCD: javascript.builtins.Array.*
web-features: https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/array.yml
MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array

3) A web-features list has more features than an MDN page's compat table

Example 1: (Unproblematic) web-features defines a bundle consisting of 2 related features, the both have the same support. MDN shows them on different pages.

BCD: javascript.builtins.Array.at
web-features: https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/array-at.yml
MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/at

Example 2: (Problematic) web-features defines a bundle consisting of many features, but they have different support. So far we have avoided creating such bundles in web-features. Sometimes even by commenting things out or using editorial overrides. See https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/trusted-types.yml for example.

So, imho, MDN should decide in which of these situations it wants to display the baseline banner for now and in which situations more work is needed either in MDN's rendering logic or in web-features' data.

If you ask me, I would recommend:

For situation 1: If you have an exact match, render the baseline banner.

For situation 2: If the MDN page renders more compat rows than you can find in the web-features list, don't render the baseline banner for now. As a renderer you could do more in this situation, though. For example, you could find the baseline status for all javascript.builtins.Array.* features and say "Mixed availability: 85% baseline high, 5% baseline low, 10% limited availability". I guess that would require an additional UX design, though.

For situation 3: If a web-features list has more feature than an MDN page's compat table, render the baseline banner for now and hope that we have authored sensible groups ;-)

Elchi3 commented 8 months ago

I just realized there can be a forth situation:

4) A BCD key appears in more than one web-features list

I don't think something like this has landed in web-features yet, but I also don't think we have anything in place that would prevent us from adding BCD keys to more than one group. If there isn't a dedicated MDN page for the feature, then no baseline banner will be shown. However, if there is, then I don't know how MDN would decide which baseline status to show.

svg2-script-html-equivalence: compat_features:

api.SVGScriptElement.async
api.SVGScriptElement.defer
svg.elements.script.async
svg.elements.script.defer
svg.elements.script.type.module

javascript-modules: compat_features:

html.elements.script.nomodule
html.elements.script.type.module
javascript.statements.export
javascript.statements.export.default
javascript.statements.import
svg.elements.script.type.module

foolip commented 8 months ago

@Elchi3 with that approach, which features should we add javascript.builtins.Array to? All array-related features?

ddbeck commented 8 months ago

For the purposes of "is this blocking?", I think setting a status for Array is not a blocker.

I was on a call with some MDN folks on Thursday. Leo wasn't around, so we didn't get a definitive answer about whether MDN would pick up a release immediately. It's possible that a release, in and of itself, won't have any impact on MDN until there's action by a developer over there. But even if it were picked up and presented a problem, the folks on the call seemed to suggest that they'd just suppress a Baseline banner if it proved disruptive

(It's not clear to me that it would be disruptive. I think developers are broadly familiar with, for instance, certain values of a CSS property not being supported, even when the overall property is. It'd be nice to test this theory out.)

But to take on the rest of this, I think we have a series of distinct questions. We might consider breaking these out into distinct issues, though I think most of them will be for MDN to respond to and for us to figure how web-features can support a path forward, depending on the answers.

Q1: Is it OK to set a Baseline status knowing that it might cause a banner to appear that an author would not deliberately place, if they had the choice? (I think this is a reasonable question for web-features.)
Q2: Is it OK to show a Baseline banner when it's representing only a portion of a page (e.g., the initial support feature) and that status conflicts with some portions (e.g., later feature additions)? (I think this is a question for MDN.)
- Q2a: If it's not OK, then how should such conflicts be resolved? With more banners? A "mixed" status banner? A miniature status dashboard for that page? Baseline banners on compat table rows? Something else? (I'm pretty sure this is an area that @atopal is interested in, even if it's strictly speaking MDN's call on what to do.)
Q3: Is it OK to show a Baseline banner when the page's compat key is part of two or more web-features features? (These are questions for MDN.)
- Q3a: …when the statuses are the same?
- Q3b: …when the statuses are the same but the dates differ?
- Q3c: …when the statuses differ?
- Q3d: If not (to any of the preceding), see Q2a.

ddbeck commented 8 months ago

FWIW, I think part of the answer to a lot of these questions will lead somewhere like:

re-author high-level pages to choose web-features IDs instead of compat keys (or use deeper conflicts as a signal that pages need to be broken up or authors need to put baseline indicators per-section)
explicitly communicate feature membership on MDN pages (e.g., say that some method is part of a bigger feature)

ddbeck commented 8 months ago

Oh, I suppose Q2.5 or Q4: Is it OK for a compat key to be included in multiple features? In other words, should we guarantee that a compat key can be included in one and only one feature? (This is a question for web-features.)

foolip commented 8 months ago

I've updated the title to not claim that this is a release blocker.

web-platform-dx / web-features