search

mdn / browser-compat-data

This repository contains compatibility data for Web technologies as displayed on MDN
https://developer.mozilla.org
Creative Commons Zero v1.0 Universal
4.9k stars 1.97k forks source link

Mirroring between statements (e.g., api.HTMLLinkElement.crossOrigin -> html.elements.link.crossorigin) #18368

Open gsnedders opened 1 year ago

gsnedders commented 1 year ago

What would you like to see added to BCD?

It would good to be able to mirror between statements.

For example, html.elements.link.crossorigin probably actually matches api.HTMLLinkElement.crossOrigin (currently Chrome has different versions; I suspect this is a data bug, but I haven't checked), and it would be good to have them mechanically mirrored.

How impactful do you think this enhancement will be?

This will allow us to eliminate a lot of duplication between html and api that we have today, and fill in a variety of missing values in doing so. It also provides us with m

The statements in api are more likely to be kept up-to-date and accurate than those in html, as they can be derived by mdn-bcd-collector, whereas html requires manual curation, which often doesn't happen.

Do you have anything more you want to share?

See also https://github.com/mdn/browser-compat-data/issues/17911 for a related case between css.types and css.properties.

Also, see https://bugs.webkit.org/show_bug.cgi?id=236009#c9 for an example of someone being misled by the manually curated support tables being incomplete.

foolip commented 1 year ago

https://github.com/mdn/browser-compat-data/issues/6571 is a proposal for a very similar problem, where mirroring would achieve the same thing as a equivalence lint.

Historically it has been very common for content attributes to be supported before the reflected properties (IDL attributes) and mishaps continue to happen, so in one way it is correct to represent these differently. However, just like with events and their event handler properties, I think it would probably be better to treat these as the same and use notes where there are discrepancies that matter.

Regarding the crossorigin, it's not trivial to figure out if the two should go together or not. https://chromium.googlesource.com/chromium/src/+/21e65a63bf8e3947ff4b4d34cb73866c413106e2 is the relevant commit, and it looks like the attribute wasn't used by HTMLLinkElement before, but it's easy to be fooled and not know about uses that aren't in the diff. But I'll send a PR to update the data because I'm 80% sure it should match.

gsnedders commented 1 year ago

Historically it has been very common for content attributes to be supported before the reflected properties (IDL attributes) and mishaps continue to happen, so in one way it is correct to represent these differently. However, just like with events and their event handler properties, I think it would probably be better to treat these as the same and use notes where there are discrepancies that matter.

This is definitely true—but either manually overriding the mirroring or relying on notes would presumably work for these cases?

At the moment it feels like we're optimising for the historic cases where they sometimes differed, to the detriment of the current cases where they rarely differ, and that means we miss relevant updates.

foolip commented 1 year ago

I've sent https://github.com/mdn/browser-compat-data/pull/18451.

@gsnedders I agree on both points, the current structure makes a distinction that rarely matters, and moreover many claimed differences are just wrong because the HTML data is harder to maintain. Whether we mirror, lint, or merge entries altogether, we'll be able to deal with the cases where the differences matter.