Rename open-closed to open-pseudo

[foolip]

Fixes #3239.

[ddbeck]

I guess we should have a pretty good idea about the -pseudo versus -pseudo-class suggestion discussed in #3436 (comment) before proceeding. Otherwise, I like this.

[captainbrosset]

@ddbeck just a thought (not blocking here): what happens if we later decide to change the ID again? Perhaps to open-pseudo-class? Would we just change this value to avoid multiple chained redirects? And if so, do we have an automated check for this kind of things (to avoid chained redirects)?

[ddbeck]

@ddbeck just a thought (not blocking here): what happens if we later decide to change the ID again? Perhaps to open-pseudo-class? Would we just change this value to avoid multiple chained redirects?

Yes, that's correct. In the documentation, we promise to consumers that redirects aren't chained and do not create cycles.

And if so, do we have an automated check for this kind of things (to avoid chained redirects)?

Yes, we guard against this here:

web-features/assertions.ts

Lines 4 to 13 in b9d34ba

	/**
	* Assert that a reference from one feature to another is an ordinary feature
	* reference (i.e., it's defined and not some kind of redirect).
	*
	* @export
	* @param {string} sourceId The feature that is referencing another feature
	* @param {string} targetId The feature being referenced
	* @param {WebFeaturesData["features"]} features Feature data
	*/
	export function assertValidFeatureReference(

web-features/index.ts

Lines 220 to 232 in b9d34ba

	case "feature":
	for (const alternative of feature.discouraged?.alternatives ?? []) {
	assertValidFeatureReference(id, alternative, features)
	}
	break;
	case "moved":
	assertValidFeatureReference(id, feature.redirect_target, features);
	break;
	case "split":
	for (const target of feature.redirect_targets) {
	assertValidFeatureReference(id, target, features);
	}
	break;

[captainbrosset]

This looks mergeable. @foolip are there any changes you'd like to make before we merge?