Remove "yes" as an option

[atopal]

We talked about this a while ago, but I didn't see it in the list of issues, so I thought I'd write it down.

In a previous round of user interviews, we asked people to explain the compat data table on MDN to us. When we asked about the use of "yes" in cells, almost no one had a correct understanding of that attribute. Some people thought yes meant that all versions of the browser support that feature, some thought that it means you don't have to worry about support. Nobody knew what it actually stands for: It's supported in the version that the person who added that attribute tested.

This is bad for 2 reasons:

1. People don't understand the current usage of it, and it's misleading
2. It never gets better. If someone added "yes" 3 years ago, it might still be "yes"now. Even if people understood what "yes" stands for, they have no idea whether that was added a day ago or 3 years ago.

My suggestion is to replace it either with the exact version or with something that says "at least since version x". While "at least since version x" might not be very useful today, if it's the current version of the browser, it will be all that people care about 3 years from now.

[Kravimir]

Yes, this is highly misleading! I wasn't certain what it meant. Where on MDN is that explained?

I noticed this on the Node.textContent property (IE is marked as "yes") and seem to recall having seen it elsewhere. I'm willing to spend some time helping out with this issue (for desktop browsers, since I have many versions of them to test in and relatively fewer for mobile).

Has anyone written a script (preferably in JS or PHP) to process these JSON files to look for data from specific browsers (which in my case would be Windows and MacOSX browsers)?

[saschanaz]

My suggestion is to replace it either with the exact version or with something that says "at least since version x".

So something like this?:

{
  "version_added": true,
  "first_observed": 44
}

[hi2u]

Yeah I've been wondering this for quite a while actually, and only thought to look into reporting this request today.

I agree that "Yes" is vague & confusing, and can't think of any benefits over just showing the version number? Which it already does... but only sometimes?

It's been especially obvious to me lately as I've just started programming in Node this year... and I don't think it ever shows the version number for the Node column?

And for features that have always been supported by the software in all versions, instead of "Yes" it would be much clearer to instead write "All".

There looks like some similar github issues on here talking about this stuff, so maybe it's already under way?

[saschanaz]

IMO the best way to fix this is get the exact number for all Yes things, via something like MDN-athon 😄

[connorshea]

First observed is an interesting idea though I wonder if it’d be worth the trouble, also I’m not sure how it would be represented in the table. I’m leaning toward being in support of it.

A simple fix right now would be to add alt text on the “Yes” to explain what it means.

[ExE-Boss]

First observed is an interesting idea though I wonder if it’d be worth the trouble, also I’m not sure how it would be represented in the table. I’m leaning toward being in support of it.

A simple fix right now would be to add alt text on the “Yes” to explain what it means.

I’m in favour of adding alt text.

[a2sheppy]

Alt text is fine for a stopgap; obviously the endgame is to eliminate "yes" and have actual version numbers for everything.

[saschanaz]

We can do some batch conversion for some cases: if IE is marked as supported and Edge is marked as yes, then most probably the version number is 12.

[jpmedley]

For the record, 'all' would be incredibly misleading for Chrome data currently 'yes'. In fact, it's so far off the mark that I (not to mention my company's legal department) would consider it deceptive.

[jpmedley]

'First observed' might be a problem too. I can imagine someone writing, for example, "first_observed": 60 on something that was enabled in version 20. That would also be incredibly misleading.

[saschanaz]

I can imagine someone writing, for example, "first_observed": 60 on something that was enabled in version 20.

earliest_record may be an alternative name as it looks more historical for me. Or just at_least (most?).

[ExE-Boss]

Or support the <=60 syntax, which would be displayed as “60 or earlier” (≤60) and considered valid when version 60 would be specified in the browser JSON file (I’ll go and prototype this for the linter).

[saschanaz]

<=60 looks like the feature support is only for <=60, though.

[ExE-Boss]

It would be in version_added, and "version_added": "<=60" means added in version 60 or earlier.

[foolip]

@Elchi3 is this the right issue for deciding on whether to allow <=60 or not? It really would come in handy in a case I'm looking at now, where I'm finding WebKitAnimationEvent was in the earliest versions of Chrome (15) and Safari (4) that I can get hold of, but there's not really a feasible way to check if it was supported in Chrome 1 and Safari 1.

[ExE-Boss]

I’ll open up the PR for allowing that syntax.

It will also require a companion PR in mdn/kumascript which will depend on mdn/kumascript#1010

[Elchi3]

We haven't decided this yet, I think.

I guess the assumption here is that it is better to have a syntax like "<=60" rendered to MDN Web Docs readers and other compat data consumers than it would be to have "Yes"/true delivered to them.

I would be interested in finding out if this assumption is true and also if other data consumers would be OK with working with data like "<=60" (most importantly VSCode and webhintio)

[ExE-Boss]

<=60 would be rendered as “Added in 60 or earlier”, or just “60 or earlier”

[jpmedley]

I'd prefer the latter. Tables are tight as it is. Joe Medley | Technical Writer, Chrome DevRel | [email protected] | 816-678-7195 *If an API's not documented it doesn't exist.*

…

On Wed, Feb 20, 2019 at 10:56 AM ExE Boss ***@***.***> wrote: <=60 would be rendered as “Added “ in 60 or earlier”, or just “60 or earlier” — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3021 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0viyoVccnV1Wn-MDoy7yG_Mp6BycxJks5vPZp1gaJpZM4X3yeE> .

[queengooborg]

I like the simplicity of "version_added": "<=60", as it doesn't use any additional fields, which allows for adding this into version_removed as well without conflict. In terms of the KR of 2019, we should not consider these as "real" values, as they're only slightly more effective than true in terms of obtaining real data. Perhaps we should also add a note along the lines of something like the following:

Support was first observed in [BROWSER] [VERSION], but may be supported in earlier versions. Please consider contributing to the BCD repo if you know the exact browser version this was implemented in.

[ExE-Boss]

I’m gonna work on adding support for this.

(will require #3739 to be merged and changes to the KumaScript {{Compat}} macro)

[Elchi3]

Thanks @ExE-Boss. We will have to discuss this and then make a call if we want to go down this route. I appreciate some patience.

[jpmedley]

Philip and I both support something like '<=60'. It's not perfect, but it moves us closer to the goal of having numbers or false everywhere.

[atopal]

@antross can you provide input for webhint.io? Is this something you could work with?

[atopal]

My own impression of the situation is that for at least some features we won't be able to tell when they were introduced without a lot of effort and it's of limited value to address whether something was implemented in Safari 1 or Safari 2 for example. That makes it somewhat difficult to say where the line is, but that's probably still better than providing no information, because we don't know for sure.

[atopal]

@octref can you provide input for VS Code?

[a2sheppy]

So basically, to be clear, if you know that a feature exists in Firefox 55 but don't know when it was added, you can do "version_added": "<=54"? Can you do "version_added": "<55"? What about "version_removed": "<=60"? Etc?

[connorshea]

Can someone @mention me whenever this change is merged? It'll probably break the data parsing setup I have for my BCD Explorer, so I'll need to put in some work once that happens.

[octref]

@atopal I have no problem with whichever decision you arrive at, just that "version_supported: ">=<Version>" would make more sense to me. (Or to make parsing easier, "version_supported_since" as a floating point field) Ultimately that's what people care. "version_added" with the <= has the slight twist that "feature is supported in some version less than <Version>, so every version since then are supported.

[jpmedley]

For what it's worth, I view this as a useful step in the direction of getting version numbers for everything. If I have a thousand 'yes' values where do I start? But say a feature landed in 26. Which is more useful, <=28 or <=60? There's the clue as to how I prioritize. I start with everything that's <=currentVersion and work backwards.

[antross]

@atopal Yes, this is something webhint can work with.

Given we focus on lack of support to trigger warnings we probably won't change our logic compared to "version_added": true (since we'd need to assume support back to version 1 to avoid false-positives). We'll need to update to parse the new syntax, but that's pretty minor so nothing blocking there.

[ExE-Boss]

@a2sheppy

So basically, to be clear, if you know that a feature exists in Firefox 55 but don't know when it was added, you can do "version_added": "<=54"? Can you do "version_added": "<55"? What about "version_removed": "<=60"? Etc?

If you know that it exists in Firefox 55, but aren’t sure when it was added (eg. it’s an old‑ish feature), you’d do: "version_added": "<=55", which means added in Firefox 55 or earlier.

[foolip]

Another way to look at it is that "version_added": "55" means "available in 55 and later" and "not available in 54 or earlier". The "<=55" form makes is making only the first of those claims.

Seeing BCD as a huge browser+version × supported table, it makes it possible to have a row with mixed null+true, where previously only false+true was possible.

What about "version_removed": "<=60"? Etc?

If supported, that means "not available in 60 or later" but doesn't imply anything about the versions between version_added and 60. So a mix or true+false+null for that row in the matrix.

[SebastianZ]

The use of "Yes" instead of the actual version I tested a feature in has been bothering me many years before the BCD project was born. It was also misleading, because it doesn't account for the cases in which a feature was removed and readded at some point. So I am happy this issue gets addressed now.

While it is an obvious fit to reuse "version_added" and "version_removed" for this, this is a breaking change for all projects expecting the value to be a number, like @connorshea's BCD Explorer.

So, if we decide on this syntax change, all project owners should get informed about it and given some time to adjust their implementations to account for that before the change happens.

Sebastian

[connorshea]

FWIW I’m fine with breaking changes, I don’t want my project to hold back progress of the BCD project :)

I would of course appreciate forewarning, but I follow the repo enough that I usually find out on my own.

[queengooborg]

At first, I was skeptical about this, and I was wondering whether this provided any real use. I was thinking that it would just be easier to try to find a better way to describe true, but recently, I've just run into numerous instances with IE and Edge where it would be great to mark the earliest version I was able to test in. IE 7 and below require an extension for development tools, making it hard to determine whether a CSS value is parsed. Furthermore, it doesn't seem like many testing platforms have Edge 12-14*, so being able to indicate "15 or earlier" greatly helps.

Bottom line, I'm in full support of this feature. Can't wait for it to be added!

* Seems like SauceLabs has Edge 13 and 14, by the way.

[foolip]

FWIW, I have Edge 12 in a VM, so given automated tests I can get results on request.

[queengooborg]

Glad to hear, @foolip! Since I’ve only got IE (the full collection) and Edge 15-18, I’ll most likely reach out to to you for assistance on some of the IE/Edge testing. 😉

[queengooborg]

Alright, so update on this:

In #4330, we decided to add support for version ranges, however only certain browsers may use these (specifically, WebView ≤37). Since it's so challenging to test such old versions of those browsers (and not to mention because of their age, they're not used at all), we're allowing specific browsers to indicate support may have been introduced in the older versions.

Overall, BCD's 2019 goal was to increase the quality of the compatibility data, which meant replacing true and null with actual version numbers. We were able to get through all of the CSS data, and are almost done with the JavaScript data, with only a little bit more to go. We have an issue open that refers to this goal, which not only works to removing "yes" (true), but also null.

I feel that it's best to close this issue to do a little repository cleanup, and since we're already working to disallow true in specific folders for specific browsers, so I will do so now. Thanks, everyone, for your valuable input!