Allow use of ranges (≤) before the Baseline low date #1208

foolip · 2024-06-07T10:25:50Z

The use_ranges_before_baseline_low_date field controls when generating
the status, but it could also be done in overrides.

Closes #1018.

foolip · 2024-06-07T10:49:10Z

I have tried sprinkling this onto the HTML element draft features and really like what it's doing. For example:

--- a/features/draft/html-elements/h1.yml.dist
+++ b/features/draft/html-elements/h1.yml.dist
@@ -11,5 +11,5 @@ status:
     edge: "12"
     firefox: "1"
     firefox_android: "4"
-    safari: "4"
-    safari_ios: "3.2"
+    safari: ≤4
+    safari_ios: ≤3.2

Not having to spend any time updating BCD to show that <h1> was actually supported in Safari 1 will be great.

foolip · 2024-06-07T10:51:48Z

index.ts

+    if (data.status?.support) {
+        const versions: string[] = Object.values(data.status.support);
+        if (versions.some((v) => v.startsWith('≤'))) {
+            if (data.status.baseline_low_date !== earliestBaselineLowDate) {


Should I change this to allow for ranges when the Baseline low date is before 2016? I'm on the fence.

I like this being a more specific thing to start, then expanded to later uses later (as needed).

ddbeck · 2024-06-10T08:55:24Z

features/search-input-type.yml

@@ -5,3 +5,4 @@ group: forms
 caniuse: input-search
 # TODO: investigate minor differences in the early support of the feature
 # between https://caniuse.com/input-search and our generated status.
+use_ranges_before_baseline_low_date: true


It only just occurred to me: should we consider indicating internal-only fields? For example, prefixing with an underscore? Doesn't have to happen in this PR, but it'd be nice to get your thoughts on it.

I think that would provide a useful clue to someone reading the source and wondering if they can use the data through a published package. However, it wouldn't make it any easier for us to filter out such keys, because in order to catch typos we have to enumerate all allowed keys.

ddbeck · 2024-06-10T08:57:01Z

features/search-input-type.yml.dist

-    chrome: "5"
+    chrome: ≤5
    chrome_android: "18"
    edge: "12"
-    firefox: "4"
+    firefox: ≤4
    firefox_android: "4"
-    safari: "5"
-    safari_ios: "4.2"
+    safari: ≤5
+    safari_ios: ≤4.2


I'm taking this to mean "Edge 12 is the very latest release to introduce support for this feature but other browsers may have come earlier than we report."

Yes, which is different from "it may have come earlier or later than we report" which would be a natural outcome of "we're not sure we trust this data and haven't reviewed it carefully." But, when throwing together a bunch of things, the most recent version is the one we use, so there's good reason to expect that the error will usually be mostly in the direction of claiming features are newer than they are.

ddbeck · 2024-06-10T09:03:08Z

index.ts

@@ -20,16 +20,20 @@ const nameMaxLength = 80;
 // The longest description allowed, to avoid them growing into documentation.
 const descriptionMaxLength = 300;

+// The earliest possible Baseline low date, the release date of Edge 12.
+const earliestBaselineLowDate = '2015-07-29';


I don't know if this is better exactly, but it feels more "correct":

Suggested change

const earliestBaselineLowDate = '2015-07-29';

// needs import { browser } from "compute-baseline/browser-compat-data";

const earliestBaselineLowDate = browser("edge").version("12").date.toString();

If taking one step I'd be tempted to take the next one, and compute from the core browser set what the earliest possible Baseline low date is.

But I think it would be just as good to just say that ranges are allowed for any pre-2016 data except the keystone release for each feature. Once it's 2026 this will be quite easy to justify too :)

OK, if this will eventually become a date, let's leave it as a date.

ddbeck · 2024-06-10T09:25:09Z

index.ts

+    if (data.status?.support) {
+        const versions: string[] = Object.values(data.status.support);
+        if (versions.some((v) => v.startsWith('≤'))) {
+            if (data.status.baseline_low_date !== earliestBaselineLowDate) {


I like this being a more specific thing to start, then expanded to later uses later (as needed).

ddbeck · 2024-06-10T09:37:33Z

index.ts

+    // Ensure that version ranges are only used for prehistoric features.
+    if (data.status?.support) {
+        const versions: string[] = Object.values(data.status.support);
+        if (versions.some((v) => v.startsWith('≤'))) {


I don't love adding uncertainty to potentially already-certain ranges in BCD, but I expect a future resolution to #1211 to fix this at a later date, so it's fine.

I get the discomfort. Should we instead have a single possible combination of ranged browser versions as described in #1018 (comment)?

Let's leave this for now too. I think bubbling up BCD's uncertainty will mess with a bunch of values anyway (especially dates), so let's sort that out first.

Alright, let me make some cosmetic changes around the Edge 12 date and land this.

ddbeck · 2024-06-25T16:14:30Z

@foolip I think this is ready to go, pending a main merge or rebase.

The `use_ranges_before_baseline_low_date` field controls when generating the status, but it could also be done in overrides. Closes web-platform-dx#1018.

foolip · 2024-06-27T09:46:39Z

This got in the way of grouping comments, see https://github.com/web-platform-dx/web-features/pull/1231/files#r1656826439. I'm considering if we should revert this as it's less important than #1231.

This reverts commit 9c7f22d.

…#1286) This reverts commit 9c7f22d.

github-actions bot added the feature definition Creating or defining new features or groups of features. label Jun 7, 2024

This was referenced Jun 7, 2024

Allow ranged dates and versions for non-threshold support information #1018

Open

Support ranges before a given year with status_uncertain_before #1206

Closed

foolip force-pushed the use_ranges_before_baseline_low_date branch from 7846d59 to c0afc72 Compare June 7, 2024 10:39

foolip commented Jun 7, 2024

View reviewed changes

foolip requested a review from ddbeck June 7, 2024 10:51

ddbeck approved these changes Jun 10, 2024

View reviewed changes

foolip force-pushed the use_ranges_before_baseline_low_date branch 2 times, most recently from 3335b72 to c58ed0f Compare June 10, 2024 14:39

foolip mentioned this pull request Jun 13, 2024

More features faster blockers #1240

Closed

5 tasks

tidoust approved these changes Jun 13, 2024

View reviewed changes

foolip force-pushed the use_ranges_before_baseline_low_date branch 2 times, most recently from 347d270 to dcc0587 Compare June 27, 2024 08:16

Allow use of ranges (≤) before the Baseline low date

c09ce0b

The `use_ranges_before_baseline_low_date` field controls when generating the status, but it could also be done in overrides. Closes web-platform-dx#1018.

foolip force-pushed the use_ranges_before_baseline_low_date branch from dcc0587 to c09ce0b Compare June 27, 2024 08:20

foolip merged commit 9c7f22d into web-platform-dx:main Jun 27, 2024
3 checks passed

foolip deleted the use_ranges_before_baseline_low_date branch June 27, 2024 08:27

foolip mentioned this pull request Jun 27, 2024

Group BCD keys in dist by status block #1231

Merged

foolip added a commit that referenced this pull request Jun 27, 2024

Revert "Allow use of ranges (≤) before the Baseline low date (#1208)"

9249c5a

This reverts commit 9c7f22d.

foolip mentioned this pull request Jun 27, 2024

Revert "Allow use of ranges (≤) before the Baseline low date" #1286

Merged

foolip added a commit that referenced this pull request Jun 27, 2024

Revert "Allow use of ranges (≤) before the Baseline low date (#1208)" (…

be5938c

…#1286) This reverts commit 9c7f22d.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow use of ranges (≤) before the Baseline low date #1208

Allow use of ranges (≤) before the Baseline low date #1208

foolip commented Jun 7, 2024

foolip commented Jun 7, 2024

foolip Jun 7, 2024

ddbeck Jun 10, 2024

ddbeck Jun 10, 2024

foolip Jun 10, 2024

ddbeck Jun 10, 2024

foolip Jun 10, 2024

ddbeck Jun 10, 2024

foolip Jun 10, 2024

ddbeck Jun 10, 2024

ddbeck Jun 10, 2024

ddbeck Jun 10, 2024

foolip Jun 10, 2024

ddbeck Jun 10, 2024

foolip Jun 10, 2024

ddbeck commented Jun 25, 2024

foolip commented Jun 27, 2024

	const earliestBaselineLowDate = '2015-07-29';
	// needs import { browser } from "compute-baseline/browser-compat-data";
	const earliestBaselineLowDate = browser("edge").version("12").date.toString();

Allow use of ranges (≤) before the Baseline low date #1208

Allow use of ranges (≤) before the Baseline low date #1208

Conversation

foolip commented Jun 7, 2024

foolip commented Jun 7, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ddbeck commented Jun 25, 2024

foolip commented Jun 27, 2024