image-resolution: no browser supports it

[teoli2003]

The two spec/browser compat tables were broken: as nobody implements this feature, it has no bcd entry.

This PR:

• use spec-url in Yaml to link to the spec
• remove the {{Compat}} and replace it with a text instead of the broken table message.

[github-actions]

Preview URLs

• https://pr16026.content.dev.mdn.mozit.cloud/en-US/docs/Web/CSS/image-resolution

Flaws

URL: /en-US/docs/Web/CSS/image-resolution
Title: image-resolution
on GitHub
Flaw count: 1

• macros:
  • `/home/runner/work/content/content/node_modules/@mdn/yari/kumascript/macros/Specifications.ejs:1

1| <%
2| /*
3| Placeholder to render a specification section with spec_urls from BCD
4|

No first query argument or 'browser-compat' or 'spec-urls' front-matter value passed`

External URLs

URL: /en-US/docs/Web/CSS/image-resolution
Title: image-resolution
on GitHub

No new external URLs

[wbamberg]

@hamishwillee , @queengooborg , the same applies to this as to #16066, only in this case it's not even supported behind a pref.

Again I would prefer it if we had BCD for CSS properties like this:

• it gives a clear answer to BCD consumers (they can know whether it's actually not supported, or just hasn't been documented yet)
• it means we could have a clearer and simpler structure for CSS properties

[teoli2003]

I would be all for having something in bcd, or if not possible in YAML, that indicates that there is no support.

Also, we should be stricter in not accepting docs about features that are not yet implemented: they can stay forever (like this property) not implemented, they can change and this leads to false expectations for web developers.

[wbamberg]

Yeah I agree: we can decide not to have pages from some features that we think are a long way off implementation, but if we have pages, we should have BCD.

[hamishwillee]

but if we have pages, we should have BCD.

BCD normally takes the view that things need to at least have some kind of implementation. The reason being that quite a lot of things make it to spec and never go further.

Personally I'd like to have this in BCD but perhaps with infrastructure to make it more clear that a doc is a placeholder and everything below is not supported. E.g. "support": false rather than a tree for these cases.

[teoli2003]

Can we do something like:
if no browser-compat: YAML key, or if it leads to nothing, the {{Compat}} will display a standard message informing about no support?

(Note that if we use bcd as the source of trust for information about experimental/deprecated/non-standard, the problem will only thicken as we will need to deal with these cases too)

[queengooborg]

Before defaulting to saying that a feature isn't supported in any browser, I'd first like to come to a decision on the corresponding guideline, see mdn/browser-compat-data#10619 for details. While we have been removing features that are all false and not merging any new data, I'd still like to come to a concrete decision before we represent it in Yari.

As for the statuses, perhaps we can use a meta tag like "status" that acts as an intermediary if BCD data doesn't exist, similar to how spec_url works?