mdn
`image-set()` support data is incorrectly formatted
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?
https://github.com/mdn/browser-compat-data/pull/22902 https://github.com/mdn/browser-compat-data/pull/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
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 :)
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 https://github.com/mdn/browser-compat-data/issues/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:
https://github.com/mdn/browser-compat-data/blob/01d0b38788e12dda3c4ecc6bfa1fc9e3edac9e29/scripts/lib/compare-statements.ts#L8-L20
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.
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
I'm going to close this because this has to do with rendering on MDN pages, which is not handled in this repository. All rendering is handled in https://github.com/mdn/yari; we just provide the raw data.
