What's the earliest baseline_low_date?

[Elchi3]

Currently, if you create a feature-definition with well supported compat_features dating back to the beginning of the web, you end up with 2015-07-28 as the baseline_low_date which is the day Edge 12 released (the earliest release from the baseline browser set). Does this make sense?
If we ignore Edge 12, the next browser would be chrome_android 18 on 2012-06-27 and if we ignore that one, it would be chrome on 2008-12-11. :)
I don't know how important baseline_low_date is to us or our consumers. If it is important, maybe 2010-01-01 or some other special date could be used, indicating that the features are usable for a long time, predating the baseline effort?

name: Basic JavaScript arrays
description: Basic JavaScript arrays (ECMAScript 1 + 3)
status:
  baseline: high
  baseline_low_date: 2015-07-28
  chrome: "1"
  chrome_android: "18"
  edge: "12"
  firefox: "1"
  firefox_android: "4"
  safari: "1"
  safari_ios: "1"
compat_features:
  - javascript.builtins.Array
  - javascript.builtins.Array.Array
  - javascript.builtins.Array.concat
  - javascript.builtins.Array.join
  - javascript.builtins.Array.length
  - javascript.builtins.Array.pop
  - javascript.builtins.Array.push
  - javascript.builtins.Array.reverse
  - javascript.builtins.Array.shift
  - javascript.builtins.Array.slice
  - javascript.builtins.Array.sort
  - javascript.builtins.Array.toLocaleString
  - javascript.builtins.Array.toString
  - javascript.builtins.Array.unshift
  - javascript.grammar.array_literals

[ddbeck]

Copying the gist of my comment on #323 here.

I wrote down every idea I could come up with when it comes to indicating that a date is (possibly) out-of-bounds:

1. Use an editorial override to set a reasonable sounding historical date (e.g., we go look at the feature's history and pick a reasonable looking date in our expert judgment). We might need to update the Baseline definition document to communicate that this is an option.
2. Indicate an out-of-bounds low condition with a string instead of a date ("out-of-bounds").
3. Do the above, but with a really fake date ("1900-02-29", Excel style, perhaps).
4. Don't provide a date at all (i.e., baseline: "high" without a date means "since approximately forever").
5. Have a special value for baseline: "heirloom", "high", "low" and false.

[atopal]

Thanks for enumerating Daniel! I guess which way we go and how much it matters depends on what we are trying to achieve with Baseline. The primary purpose is to make it clear what is and isn't available on the web platform today. So, from that perspective, I'm thinking that any of those should work fine, since 2015 is far enough in the past that for almost all practical purposes it won't matter whether something was shipped earlier than that. So, beyond that immediate goal, I'm thinking we also want to make it easy to work with the data, so people can integrate it into tooling and the workflow that devs already have. And lastly, it would be nice if we could trace the development of the platform over time, so we can compare whether we are getting better at landing things on the platform. For the latter case, I'm thinking we'd ideally have a definition of Baseline that goes back further than 2015, but that would necessitate including Trident/IE/Edge and won't serve much practical purpose, so I'm not sure the effort would be warranted. For the tooling purpose, I'm not sure what the requirements would be.

…

On Thu, Feb 15, 2024 at 1:49 PM Daniel D. Beck ***@***.***> wrote: Copying the gist of my comment on #323 <#323> here. I wrote down every idea I could come up with when it comes to indicating that a date is (possibly) out-of-bounds: 1. Use an editorial override to set a reasonable sounding historical date (e.g., we go look at the feature's history and pick a reasonable looking date in our expert judgment). We might need to update the Baseline definition document to communicate that this is an option. 2. Indicate an out-of-bounds low condition with a string instead of a date ("out-of-bounds"). 3. Do the above, but with a really fake date ("1900-02-29", Excel style, perhaps). 4. Don't provide a date at all (i.e., baseline: "high" without a date means "since approximately forever"). 5. Have a special value for baseline: "hierloom", "high", "low" and false. — Reply to this email directly, view it on GitHub <#623 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEIGHBXY3ORETKPF7N7ZBDYTX75ZAVCNFSM6AAAAABDKCH4MSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBWGAZTKNZYGM> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ddbeck]

I guess it would be good to hear from two possibly different groups on this:

• Consumers on what they'd expect the data for such a thing to look like, or at least what would be easy to work with in terms of types, optional fields, magic values, etc. I created a label for this kind of thing.

• The folks here about display preferences. I suspect the major thing is that there's interest in putting features in annual buckets (e.g., Baseline 2024, 2023, etc.). How would you want that to appear for the oldest group? Would we be okay with many, many "Baseline 2015" features? What if we added another browser later, would we be OK with dates advancing or retreating as a consequence? This might put some constraints on how the data works.

[captainbrosset]

My vote goes to using a keyword for this like browser_set_start or something.

For any feature sufficiently old, it feels weird to make it seem like Edge 12 was the browser that last implemented it, and it feels weird for it to be dated to 2015. I'm not very keen on using another date either, as it could change if we add other browsers in the future.

My next favorite option is to drop the baseline_low_date in these cases.

[foolip]

From our definition of Baseline it follows that 2015-07-28 is the earliest possible date, and I think we should record that unless we change the definition.

We should document that this is the earliest possible date. It means "available in the core browser set since 2015-07-28" (no earlier) or "available in browsers used at the time since 2015-07-28 or earlier".

But I would also like to hear from consumers if they want to special case this and if they need more data in web-features.

For a "heirloom" status or similar I think we should use a number of years, not a fixed point in the past. If we pick 10 years then the problem of 2015-07-28 will be solvable next year...

[romainmenke]

I think we need to honor the intent of the current Baseline definition, but not the definition itself.

Did a feature have broad browser support in 2014, 2013, ...
If it did, then it doesn't really matter if this was in an area when the set of browsers was IE 11, IE 10, Safari, Chrome, ...

I think that at this point it time this is largely theoretical because the current set has been the dominant set for a while. But these things change.

---

Would we be okay with many, many "Baseline 2015" features? What if we added another browser later, would we be OK with dates advancing or retreating as a consequence?

I think we should avoid this.

---

For a "heirloom" status or similar I think we should use a number of years, not a fixed point in the past. If we pick 10 years then the problem of 2015-07-28 will be solvable next year...

This seems fair to me.

It think this is better than larger and more sudden shifts.

[foolip]

Trying to capture anything that happened before Edge 12 creates extra work and requires updating the definition of Baseline to allow for dates before 2015-07-28.

If someone is willing to do the work then I am of course not opposed, but I would not be happy about guidelines requiring the work to happen.

How about we bring in the trusted ≤ symbol from BCD and record "≤2015-07-28" instead of "2015-07-28"? That tells consumers this date is special, and makes it possible to later burn down such uncertain data points one by one, given a guideline that says what date to pick.

[Elchi3]

How about we bring in the trusted ≤ symbol from BCD and record "≤2015-07-28" instead of "2015-07-28"? That tells consumers this date is special, and makes it possible to later burn down such uncertain data points one by one, given a guideline that says what date to pick.

I like this idea. It certainly has worked well in BCD and "≤" also gives consumers a signal in case they wish to ignore ("boring") features that are baseline for a very long time already.

[foolip]

Coming back to this, I think there are 3 reasonable options.

1. Document that 2015-07-29 is the earliest possible date but make no change to the schema or data

2. Use ranges for features supported in IE, drafted in Use ≤2015-07-29 for features also supported in IE #667.

3. Update the definition of Baseline to treat IE+Edge as a single line of browser releases, allowing dates before 2015-07-29. This would make the earliest possible date 2008-12-11 (Chrome 1) instead.

(Note that mdn/browser-compat-data#22286 changed the date from 2015-07-28 to 2015-07-29.)

I prefer option 1 or 2. Option 3 moves too far into the past. Uncertainty about the BCD data in code review will require testing very old browser releases, older than mdn-bcd-collector supports even. For example, if BCD claims Chrome 9 for parts of a feature and Chrome 11 for other parts, I don't want to spend time figuring out which is correct.

[ddbeck]

I prefer option 2 (along with some guidance on how to refer to such features, if you're referencing a year otherwise). It feels like a tidy way to suggest that a feature's Baseline date falls on a particular date but, strictly speaking, its Baseline status is not defined prior to the introduction of the youngest browser. Plus, I'd still like to have consumer feedback on this and throwing something odd in their way will provoke it. 😈

Option 1 is an OK alternative, but might be too easily ignored by consumers.

I don't like option 3. It has a number of problems, not least of which is that we end up with a less-frequently-but-still-not-never used special value in 2008.

[romainmenke]

I think Option 2 is probably best.
Option 1 is too easy to get wrong as a consumer of the dataset and Option 3 is too much work.

---

The more I think about this issue the more I see two problems:

• it isn't practical to measure up to the start of browsers, there needs to be a cut off point. This cut off point needs to be communicated to consumers of the dataset.
• when a completely new engine is added to the core set, the dates will shift

---

For the second problem it might make sense to track support changes instead of the first browser version that has support.

For example rgb() : https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/rgb#browser_compatibility

This has Edge 12 (Released 2015-07-29).
But this is not a change in support status, it initially shipped with support.

While Opera 3.5 (Released 1998-11-18) is a change in support because Opera 3 didn't have support.

Ignoring initial versions with support makes the dataset more resilient to changes of the core browser set.

Not saying that we should record/indicate dates this far back but it does solve the problem of adding new engines/browsers to the set in the future.

[foolip]

If we do change the core browser set, I think the solution to these kinds of problem is to treat the core browser set itself as changing over time, and saying that it was Chrome+Edge+Firefox+Safari before some date, and the new set after that date. This way the historical data would not change or need to be recomputed.

In other words, I'm not so worried about the earliest baseline_low_date changing in the future, we can just define our way out of the problem.

[LeoMcA]

Seems like the consensus is either documenting the date, or using ≤ before the date. Both seem fine from the perspective of consuming this data on MDN, but some thoughts:

For option 1, it would be nice to export this as a constant BASELINE_CUTOFF_DATE or something, so we don't have to manually hard code this and maintain it if it ever changes in the future.

For option 2, one downside is there's no differentiation from the ranged dates being exposed by #1398: does the ≤ signify that this feature is the earliest possible baseline date or just that there's some uncertainty in the browser compatibility data which may be clarified in the future?

What might help the decision is thinking about how consumers should be advised to display this data. Should the description on MDN be something like:

This feature is well established and works across many devices and browser versions. It’s been available across browsers since before July 2015.

(and if so, should features with an uncertain low date due to browser version ranges in BCD also display "before" in the banner? if not, we'd require something more like option 1 or differentiation between the two states in option 2)

Or should we forego the date and say something more like:

This feature is well established and works across many devices and browser versions. It’s been available across browsers longer than you need to know.

(which would again require something more like option 1, or differentiation in option 2)

[ddbeck]

For option 1, it would be nice to export this as a constant BASELINE_CUTOFF_DATE or something, so we don't have to manually hard code this and maintain it if it ever changes in the future.

This isn't exactly that, but publishing browser version information (see #1047) would implicitly establish the lower-bound, by enumerating all of the possible releases referenced by web-features. I've opened #1514 toward that.