Formalize a way to declare "No browsers support this" on unsupported CSS properties

[rachelandrew]

This issue https://github.com/mdn/content/issues/4030 is an example of the problem. In CSS we often have one property (or selector in this case) that is not supported anywhere despite the rest of the spec being well supported.

I think there is a case for having these things documented at least minimally, because if folk have seen info about them in the spec or elsewhere (often folk write articles about unimplemented things) then they may come to us to find out how to use it.

The BCD folks don't want tables for things with no support at all, which is understandable, but it would be good to show something to developers who come and thinking the property should be supported because everything else is usable. Can we come up with a formalized statement for these cases we can put on pages, as at the moment we end up with a no BCD message, asking people to submit BCD which we don't actually want!

[wbamberg]

This seems relevant to Temporal too, @meyerweb .

[meyerweb]

This seems relevant to Temporal too, @meyerweb .

Indeed! Thanks for the pointer.

[meyerweb]

Proposed text:

This page describes a feature that is not yet implemented in web browsers.

…wrapped in some sort of markup that let it be styled into some kind of obvious banner. Invoked with {{NotImplemented}}

[meyerweb]

Updated proposed text:

This page describes a feature or technology that is not yet implemented in web browsers.

[peterbe]

Could it be as simple as typing into the content...:

<h2>Browser compatibility</h2>

<p>This page describes a feature or technology that is not yet implemented in web browsers.</p>

or

<h2>Browser compatibility</h2>

<div class="notecard note">
  <p>This page describes a feature or technology that is not yet implemented in web browsers.</p>
</div>

[rachelandrew]

We can do that but it doesn't help with the message we get if we include the BCD macro (which asks people to contribute).

In an ideal world we would either show them all as false, which is clear. Or have some way to flag certain things as being in this state when the macro is called so we can show a tailored message.

[chrisdavidmills]

I think my vote would be to modify the {{compat}} macro to show something intelligent when a feature is new and doesn't have support yet, rather than building a new macro for the purpose. This way, changes to that status could be pushed down to the pages automatically, without needing to modify them. The question is what.

Are we happy to show an all-false table, or would it be better to show some kind of nice little message saying "This feature has not yet been implemented in browsers; watch this space for updates."

Then later on, if we do implement some kind of BCD updates mailing list or RSS feed, we could link to that in there as well...

[peterbe]

If we combine my comment above with Chris's would be that we output something very similar to what I suggested, but we do it from the Compat macro. (Technically, the Compat macro just puts in a marker which the Yari builder then takes over)

So basically, the JSX for the <BrowersCompatibilityTable/> component can do this:

const data = await loadDataFromJSON(dataQuery)
-return <Table data={data}/>
+if (isAllNotSupported(data)) {
+  return <NotecardAboutNotBeenImplementedYet/>
+} else {
+  return <Table data={data}/>
+}

[jpmedley]

I agree with Chris's proposal; however, I think this condition would actually need to be supported in BCD. There needs to be a distinction between data that is missing from BCD and features that aren't yet implemented anywhere. I don't know how you do that unless you alter the BCD. Maybe the solution is that everything below "support", which is a list of all browsers and their statuses, be replaced with a single value like "none". For example:

"SomeFeature": {
  "__compat": {
    "mdn_url": "https://developer.mozilla.org/docs/Web/API/SomeFeature",
    "spec_url": "https://html.spec.whatwg.org/somefeature",
    "support": "none"
    }
}

I would also recommend keeping the documentation minimal until there's an actual implementation. At least for APIs.

[Josh-Cena]

It has been three years and I don't think the issue has come up often again. Existing content of this kind is hard to discover and we've heard little complaint that it's confusing, so we think the status quo is satisfactory.