Getting rid of "Basic support" in Compatibility tables

MDN
#1

This has been discussed many times (for example on discourse, on github), and we still don’t seem any closer to clearing up the confusion — it is just ambiguous as to what “Basic support” means, although the first link above does provide some attempts to provide definitions. Even so, they are still easy to confuse, and what it means is not necessarily consistent or accurate between different features.

I had suggested to @fscholz that we rename it “Initial support”, and make it mean “support for the first set of stuff that is implemented for this API/spec/feature/whatever”. I think this is kind of what we mean by basic support anyway, but initial support sounds less ambiguous. But it is still hard to get your head around — the initial support set will be different between different features, how do you know when support for a subfeature is included inside “Initial support” and not just not included on MDN at all, if it doesn’t have its own row.

FLorian countered with a better proposal — why don’t be just get rid of “Basic support” altogether, and just show all explicit subfeature rows?

From Florian — “If I remember correctly, right now, “basic support” is actually done as override to the feature names in the table generation code, so if we just remove that overriding, it should just display the feature names.”

We would like to try this, and see if it makes the tables less confusing. Does anyone have any strong opinions about this?

3 Likes
#2

That sounds like a good idea. In user testing it has become absolutely clear that at best “basic support” is confusing for users. That said, if we go ahead with this, it’s probably a good idea to collapse these rows under “basic support”. Having 10 rows for a single feature is disorienting with the current layout.

1 Like
#3

Agreed; “Basic support” was only useful in the days when we didn’t have automatic generation of compatibility tables that listed all the subfeatures. Now that we have this, it’s unnecessary.

The compatibility bar, when we get to it, can easily enough look through the data and figure out when the thing became available initially, if it matters, and when it reached some percentage of completion that makes it acceptable to use (or whatever metric we choose to decide when a feature is “ready”).

1 Like
#4

Thanks Chris!
Please see https://github.com/mdn/kumascript/pull/1088 for examples on how this would change things exactly. Also, please let me know if you can think of obscure cases where we replacing “Basic support” with the feature id would look bad.

#5

I’m confused by the description of the change. Is mdn/kumascript#1088 the implementation of this change? Or does your proposal go a step further, @chrisdavidmills?

To spell this out: when you talk about “getting rid of ‘Basic support’”, are you talking about about relabeling the first row in tables on MDN? Or are you talking about removing the first row of the tables on MDN?

For example, the status quo for a feature such as css.properties.font-weight and its subfeature css.properties.font-weight.number is a table with rows:

  1. Basic support
  2. <number> syntax

Supposing it’s relabeling, the new table would have rows:

  1. font-weight
  2. <number> syntax

Is that correct? Or are we talking about actually removing the row entirely, such that css.properties.font-weight would render as one row:

  1. <number> syntax

If it’s relabeling, then that’s great and I’m all for it. If it’s removing, I have lots of questions and concerns.

2 Likes
#6

I was proposing relabeling to feature name and not removing that row.

I’m not proposing to do any data squashing or row collapsing at the moment.

2 Likes
#7

For now at least, yeah, I agree the row should stay. I do wonder if perhaps it would be less confusing if the text of that first row weren’t just the feature name but " available" or " exists". That way, we are explicit that the first row indicates that the thing is there at all, not necessarily that it’s complete.

#8

Well, the WebExtension manifest (and possibly API) data doesn’t list all subfeatures, relying instead on “Basic support”:

Pull Requests

All the above PRs are now merged, so now all we need to do is check and correct the WebExtension API data.