U - Fix CSS linter errors: data.browser_compatibility errors

[wbamberg]

The linter will check that pages correctly include this ingredient.

As per the spec for the linter, there are two specific errors that the linter raises here.

• "data.browser_compatibility/expected-heading" is raised when the page doesn't have an H2 "Browser compatibility".
• "data.browser_compatibility/expected-macro" is raised when the section does not include a call to the {{Compat}} macro.

Currently we have 42 "data.browser_compatibility/expected-heading" errors and 46 "data.browser_compatibility/expected-macro" errors. They are listed in the spreadsheet, all together in the "data.browser_compatibility" tab.

A substantial number of these will involve adding the BCD for these features.

Acceptance criteria

• There are zero errors reported by the linter for the "data.browser_compatibility" ingredient, when run against https://developer.mozilla.org/en-US/docs/Web/CSS

[rachelandrew]

This one has a lot of entries which seem to be fine so I'm not sure what to do with them. For example: https://wiki.developer.mozilla.org/en-US/docs/Web/CSS/place-self and other alignment properties.

There are some which have no BCD due to having no support yet. I could make a BCD showing no support? I guess that is useful to show people who might try and use it, what do you think @ddbeck

[rachelandrew]

I wonder if things like https://wiki.developer.mozilla.org/en-US/docs/Web/CSS/justify-content#Browser_compatibility are getting caught by the linter because they have a subheading?

[rachelandrew]

@ddbeck @chrisdavidmills this page https://wiki.developer.mozilla.org/en-US/docs/Web/CSS/filter-function is about the function as a value. Does it need it's own compat or would showing compat for the filter property which uses it be the thing to do?

[rachelandrew]

I have also noted in the spreadsheet the ones I have checked but which seem to have a heading and call to compat so I don't know why they are being flagged up.

[rachelandrew]

I've been through all of these, and either added a note as to why I think the linter report is spurious, added a PR for data, or a note for some which I don't think we can really give data (plus my comments above).

I haven't done the non-standard ones as I wasn't sure if we want to, there are a whole bunch of -moz ones listed.

[ddbeck]

I wonder if things like https://wiki.developer.mozilla.org/en-US/docs/Web/CSS/justify-content#Browser_compatibility are getting caught by the linter because they have a subheading?

Yeah, that's exactly what's happening. I brought this up in discussions while we were coming up with recipes for CSS pages. We have a few corner cases in CSS, where we have these grid/flex namespaces—there's no single "justify-content" feature. We talked about trying to represent that in BCD in a more intentional way, but that's when the layoffs hit. I don't have a solution for this right now, other than ignoring those errors for those pages.

Does it need it's own compat or would showing compat for the filter property which uses it be the thing to do?

I don't think it needs its own compat (another oddity revealed by this process: general types are hard to represent in BCD, since they manifest as individual properties' support for those types). Showing the compat for the filter property or omitting BCD would be agreeable to me.

[rachelandrew]

I don't think it needs its own compat (another oddity revealed by this process: general types are hard to represent in BCD, since they manifest as individual properties' support for those types). Showing the compat for the filter property or omitting BCD would be agreeable to me.

I think for someone looking at the type, that's what they want to know. Is it usable for the property they are likely to use it for? So I'll add the filter property info there.

[rachelandrew]

@chrisdavidmills I think the ones left in the spreadsheet now are -moz prefixed ones, I wasn't sure if you wanted to create BCD for these.

[chrisdavidmills]

@rachelandrew I'm not really sure if it is worth it. Only -webkit- prefixed stuff is really useful in a wider browser compat context, and it would probably take you a while. Although there is a voice in the back of my head saying that we probably do need it for consistency and completeness.

How many -moz- prefixed CSS properties do we have in BCD? I wonder if @ddbeck has any wisdom here?

[ddbeck]

I can get you an exact number if you like, but there's an upper bound of 78 properties' data files that contain one or more instances of '"prefix": "-moz-"' (90 in CSS overall, including at-rules and such). That's going to include some that have been removed, however (that is, where -moz- prefixes were previously supported but are now unsupported).

If it were up to me, I'd prioritize -moz- prefix data like this:

1. Currently-supported -moz- prefixes for standard names (i.e., would slot into existing data as alternative_names), if any.
2. Currently-supported -moz--only names which might be easily confused for standard names, if any.
3. -moz--only prefixes supported now or supported but removed in the last two years.

Anything else, I'd archive.

I'd be pleased if we got all of three categories into BCD, but, if you want skip any, I'd be almost as pleased if we had an issue open listing any known -moz- prefixes missing from BCD.