Browser-compat-data: Relabel “Basic support” to feature id?

[chrisdavidmills]

See https://discourse.mozilla.org/t/getting-rid-of-basic-support-in-compatibility-tables/36240. Cross posting here to solicit more opinions.

[ExE-Boss]

I think we should also update the {{Compat}} macro to auto‑squash versions with the same compatibility data.

We’ll also have to un‑squash WebExtensions data which was squashed manually in this repository.

[jpmedley]

Chris,

+1000. An API is only as useful as its members and the member entries tell you what you really need to know. Shrinking every table isn't a bad thing either.

[Elchi3]

Please see https://github.com/mdn/kumascript/pull/1088 for how I meant this exactly.

Squashing data could be done at some point, too. Not proposing to do that now, though.

[foolip]

If basic support is removed there would be some interfaces left that have no own methods and no constructor, like https://developer.mozilla.org/en-US/docs/Web/API/HTMLUnknownElement.

Since there are interfaces where the interface object is not exposed, for some interfaces the only signature of existence is that the UA can create them and return them via some other API.

Related to https://github.com/mdn/browser-compat-data/issues/3528.

[ExE-Boss]

Instead of “Basic Support”, it would show the interface name, in this case HTMLUnknownElement.

[wbamberg]

As @ddbeck says in https://discourse.mozilla.org/t/getting-rid-of-basic-support-in-compatibility-tables/36240/5, it's good to be clear on exactly what is being proposed.

It sounds like some people are talking about removing the "Basic support" row and only showing subfeatures.

I don't think only showing subfeatures is going to work. Many items don't have subfeatures. Even where there is very solid subfeature set, there is a real concept of "Basic support". Maybe subfeatures include extra parameter values, but there's still a basic "can I call this function" question that needs to be represented. I guess to that extent I disagree with the comment that "the member entries tell you what you really need to know" - compat isn't always reducible to subfeatures.

Florian's proposal (https://github.com/mdn/kumascript/pull/1088) is not this. It is as far as I can tell to keep everything the same but instead of labelling the row "Basic support", label it with the feature identifier.

I think my worry about this is that: when a feature has __compat but also has subfeatures, then giving the data from feature.__compat the special name "Basic support" is a way (maybe a quite confusing way) to indicate that it's different in kind from the data from feature.subfeature1.__compat.

For example, https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme#Browser_compatibility's compat table is like:

Basic support      some stuff
images             some other stuff
colors             yet more

if we implement Florian's proposal, we will get (I think? maybe?):

theme              some stuff
images             some other stuff
colors             yet more

...there's no indication that images and colors are things that live underneath theme - or rather, that they are aspects of the support story for theme. Would it be better then to do:

theme                    some stuff
theme.images             some other stuff
theme.colors             yet more

I'm not quite sure how much that helps though, because, while I understand that "Basic support" is confusing, it's confusing not because of the words but because of the concept. The changed table above has the same concepts, just different labels.

[ExE-Boss]

We could also display a ., which in file systems refers to the current directory.

[foolip]

Instead of “Basic Support”, it would show the interface name, in this case HTMLUnknownElement.

That currently refers to a constructor, for example here:
https://github.com/mdn/browser-compat-data/blob/5dd3709088ebba16fb6b8d54d0b5f6b3e05939d4/api/Document.json#L50-L53

Overloading it to also mean something else doesn't sound great, then the human-readable description would be required to interpret the data, i.e. whether new Document() should show a warning in an IDE using BCD.

There are cases where "basic support" is fully redundant with other entries, so maybe it should be made optional?

[ExE-Boss]

Instead of “Basic Support”, it would show the interface name, in this case HTMLUnknownElement.

That currently refers to a constructor

No, it doesn’t, because in your case, “Basic Support” would change to Document, whereas the constructor displays: “Document() constructor”, which is different.

[chrisdavidmills]

It sounds like some people are talking about removing the "Basic support" row and only showing subfeatures.

Yeah, sorry, this is not what we mean. My wording of the title of this issue did not help. We are talking about relabelling it with the overall feature.

...there's no indication that images and colors are things that live underneath theme - or rather, that they are aspects of the support story for theme.

I think this is a reasonable concern; to make this easier, and avoid having to manually update loads of subfeature identifiers, we could just bold the overall feature name (and possibly even indent the subfeatures) to give an idea of hierarchy.

while I understand that "Basic support" is confusing, it's confusing not because of the words but because of the concept. The changed table above has the same concepts, just different labels.

I'm not sure I agree with this; I think both are a problem. I think letting the overall feature name speak for itself is less confusing — I look at it and go "ah, so that's when the overall feature was first introduced, and other subfeatures were introduced later". Just by having a confusing label of "Basic support", you introduce a load of uncertainty about what it means, need to agonise over the definition and the fact that it seems to mean different things in different contexts, etc.

So the proposed changed might not get rid of all problems, but I think it is still a marked improvement.

[chrisdavidmills]

We could also display a ., which in file systems refers to the current directory.

Can you show an example of what you mean by this? Like Will did in his reply?

[foolip]

@ExE-Boss can you show what the JSON would look like for something that is a constructor, something that has an interface object exposed and something that does not? "Document() constructor" is part of the human-readable description, so my question is how tools could distinguish at least between things are constructors and things that aren't.

[Elchi3]

I'm not quite sure how much that helps though, because, while I understand that "Basic support" is confusing, it's confusing not because of the words but because of the concept. The changed table above has the same concepts, just different labels.

I think I disagree that it's totally the same. "Basic support" is a poorly defined term whereas actually putting the feature is more precise what it actually means and I think it reflects the BCD data better. "Basic support", "Initial support" or other terms that make a lot of room for interpretation. Putting the name of the Interface, or HTTP header, or CSS property, or HTML element there is not without ambiguity completely, I agree, but it seems like it is more closely to what the data actually wants to say imo.

For example, "css.properties.background.__compat" is rendered as "Basic support"
But actually this data tree is about the exposure or presence of background and whether it is -moz-background, or behind a pref or just supported under normal circumstances. We're labeling this tree "Basic support", but in BCD we store info for background in there and not a calculation of basic background support. There are sub features of background and in our data model this is indicated by going one level deeper, but in fact "css.properties.background.__compat" does only store info for the availability of background.
If we were to implement a real "basic support", we should, probably, for each feature, define all sub features or a collection of features and then do the support calculations.

To give another example: if we were to say "Basic support" for ServiceWorkers, there is probably ton of features that would go into that calculation. It is not just the ServiceWorker interface, where we currently say "Basic support" and make it sound like something other than just the standard exposure of this interface is supported in the given versions.

I think letting the overall feature name speak for itself is less confusing
Just by having a confusing label of "Basic support", you introduce a load of uncertainty about what it means, need to agonise over the definition and the fact that it seems to mean different things in different contexts, etc.

Yes, this is exactly my motivation as well.

[Elchi3]

I've updated the title of this issue to highlight again that we're not proposing to remove the main __compat tree for a feature, but we want to stop calling that one "Basic support" and relabel it to its feature name just like we do for every other feature in the BCD trees as well.

[chrisdavidmills]

Thanks @Elchi3, all makes sense.

[foolip]

@Elchi3, thanks for clarifying!

Putting the name of the Interface, or HTTP header, or CSS property, or HTML element there is not without ambiguity completely

Yeah, even using the name of the interface, the problem in https://github.com/mdn/browser-compat-data/issues/3528 remains.

[jpmedley]

How often is that 'basic support' boils down to the interface being present? Maybe the table should say, for example, 'Document interface' or 'AudioContext interface'. This would parallel 'Document() constructor' and 'AudioContext() constructor' and would more less explain itself by context.

Corollary to this proposal is finding other ways to deal with edge cases.

[foolip]

@jpmedley I'm sure it has happened that an interface has been exposed without the feature actually working, and sometimes the feature does work even though the interface isn't directly exposed, but "Document interface" still sounds good, notes could be used to explain the weird cases.

[Elchi3]

I think appending things to feature names can be useful.
"Document interface", or "\

Maybe we could explore that after we've shipped having feature names alone for starters.
The current proposed change would label things as "Document", or "\

[ddbeck]

How often is that 'basic support' boils down to the interface being present?

Bear in mind that the schema has meaning beyond what's in /api/. For something like CSS properties, knowing when the property was first recognized is useful independent of any of its subfeatures (for instance, if you're using one of the global keywords)

[Elchi3]

We've removed the "Basic support" label and are using feature names now. See https://github.com/mdn/kumascript/pull/1088 for details.

This hasn't populated to all wiki pages yet, so I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1539170 to track that.

Closing here.