image-set() support data is incorrectly formatted

[romainmenke]

What type of issue is this?

Incorrect support data (example: BrowserX says "86" but support was added in "40")

What information was incorrect, unhelpful, or incomplete?

The data is out of order and seems mangled on mdn :
https://developer.mozilla.org/en-US/docs/Web/CSS/image/image-set#browser_compatibility

What browsers does this problem apply to, if applicable?

No response

What did you expect to see?

I expected to see neat and orderly supports data

Did you test this? If so, how?

• our code failed on the latest bcd npm package version because of this data.
• I visited mdn and the supports data looked weird

Can you link to any release notes, bugs, pull requests, or MDN pages related to this?

#22902
#22939

Do you have anything more you want to share?

Maybe some of these mistakes can also be caught with a linter?

MDN URL

No response

MDN metadata

No response

[romainmenke]

Chrome states a prefix version was added and removed in 113

Firefox data is out of order

Safari data is out of order
Safari states a prefix version was added in 17, but also that it was added in 6 and removed in 14

Some of these might be ok, even if they seem incorrect to me :)

[foolip]

Chrome states a prefix version was added and removed in 113

This is the only way we currently have to say that a note or partial implementation status no longer applies. An alternative data model is discussed in #17857, but unfortunately it would be a huge amount of work to convert BCD.

data is out of order

I originally used a different order, but npm run lint will complain about any other order, and npm run fix turns it into the order we have now. Ordering rules are defined here:

browser-compat-data/scripts/lib/compare-statements.ts

Lines 8 to 20 in 01d0b38

	/**
	*
	*Sort a list of compatibility statements based upon reverse-chronological order in the following order:
	* 1. Statements with only version added (and potentially notes)
	* 2. Statements with alternative names or prefixes
	* 3. Statements with partial support
	* 4. Statements with flags
	* 5. Statements with a version removed (or otherwise no support)
	* @param a - The first support statement object to perform comparison with
	* @param b - The second support statement object to perform comparison with
	* @returns Direction to sort
	*/
	const compareStatements = (

Both "Statements with partial support" and "Statements with a version removed" pushes the partial impl. statement to come after the prefixed statement.

@queengooborg do you consider this a bug? I don't know all of the tradeoffs in ordering and what would appear "wrong" if we changed it.

[romainmenke]

If I understand it correctly, the current data is the correct way to record notes and partial implementation for both the prefixed and unprefixed version.

I do wonder how valuable it is to keep recording this data for the prefixed versions.

"chrome": [
  {
    "version_added": "113"
  },
  {
    "prefix": "-webkit-",
    "version_added": "113"
  },
  {
    "prefix": "-webkit-",
    "version_added": "20",
    "version_removed": "113",
    "partial_implementation": true,
    "notes": "Support for <code>url</code> images only and <code>x</code> is the only supported resolution unit."
  }
],

vs.

"chrome": [
  {
    "version_added": "113"
  },
  {
    "prefix": "-webkit-",
    "version_added": "20",
    "partial_implementation": true,
    "notes": "Support for <code>url</code> images only and <code>x</code> is the only supported resolution unit."
  }
],

The second example doesn't make it unambiguously clear that the prefixed version does have full support from 113. But is that still important/valuable after the unprefixed value or prop shipped?

---

Either way this is fine to close as answered, thanks