Move IndexedDB out of draft

[Elchi3]

So, this was first added as a draft here: #1342 what do we still need to sort out to have this in?

[autonome]

Added and removed here too #1773 (comment)

[ddbeck]

Moving @autonome's comment from #2347 (comment) to here:

Caniuse has IndexedDB and IndexedDB 2.0 as separate features.

This aligns with how the specification is being developed as "major versions", cf IndexedDB 3.0 (https://w3c.github.io/IndexedDB/) which is what MDN points to.

Aside from being a departure from how we've named Web Features so far, it seems to align with reality to make a feature for each major version, and distribute the keys and compute status to match Caniuse for the ones it has listed so far:

• The initial core feature w/o the late additions is usable

• The new features are distinct enough to stand alone (at least up to 2.0, not sure what's in 3.0...)

• The support timeline results in distinct baseline dates for the first two

[ddbeck]

I held up IndexedDB based on the stuff in the comment at the top of the file:

web-features/features/draft/indexeddb.yml

Lines 1 to 12 in bebe956

	# A known hard part here is that api.IDBFactory.open has a showstopper bug in
	# some releases of Safari 14: https://bugs.webkit.org/show_bug.cgi?id=226547
	# It's likely that api.IDBFactory.open should be marked as having an
	# interruption (or partial_implementation) in support there. This would break
	# consistency caniuse, however. To fix *that* would require PRs on both BCD and
	# web-features. It's also probable that we would want to add a note to the
	# feature about this fact, see:
	# https://github.com/web-platform-dx/web-features/issues/557
	#
	# Unknown hard parts are that there may be other parts of IndexedDB with such
	# issues. Someone who's knowledgeable about IndexedDB ought to author or review
	# this feature.

Since this was written, we've relaxed how we're doing alignment with caniuse, so we could probably land this with only the change to the BCD on api.IDBFactory.open, so it shows the break in continuous support around Safari 14. Everything else we could tend to later.

[ddbeck]

On the 2.0 split, I kinda thought that was sufficiently historic that there was not a lot of value in teasing that part out. For example, there are very few Stack Overflow questions that mention "IndexedDB 2.0" and none that mention "IndexedDB 1.0". The lack of "IndexedDB 1.0" as a backformation seems like a very strong indicator that the 2.0 distinction is not a relevant one for developers.

[Elchi3]

so we could probably land this with only the change to the BCD on api.IDBFactory.open, so it shows the break in continuous support around Safari 14. Everything else we could tend to later.

Do have more precise information than "around Safari 14"? In the bug report I see iOS 14.7 and/or macOS 11.5 where the fix landed but I'm not sure what Safari version this maps to and I don't think if BCD has the potential minor Safari versions released more than 3 years ago. Is this worth the effort?

[ddbeck]

Is this worth the effort?

I think so. If you search "Safari IndexedDB" almost all the results are about this and earlier Safari bugs. Basically, I think we need some way to show that Safari has only continuously supported Safari since version 15. To do otherwise is going to make us look silly.

If we don't want to backfill Safari releases, we could do a bit of a hack in BCD (e.g., doing a "version_removed": "14.1" immediately followed by a "version_added": "15").

[Elchi3]

The BCD changes for IDBFactory.open are in the dist file of this PR now.
Do we need a compute_from on that key or what is the thinking here?

[ddbeck]

The BCD changes for IDBFactory.open are in the dist file of this PR now. Do we need a compute_from on that key or what is the thinking here?

Yes, I think adding open to compute_from and refreshing the dist will do what we need to get this feature to a point where we can send it out without needing to figure out notes/partials/etc.