Split and merge `syntaxes.json` into `functions.json` and `types.json`

[yarusome]

What information was incorrect, unhelpful, or incomplete?

syntaxes.json contains data for both CSS functional notations and CSS types, but there already exist functions.json and types.json for such data.

I'm working on a script for diffing mdn/data and w3c/webref, and the existence of syntaxes.json would make the script less useful since this file increases the complexity of comparison bewteen the two data sources.

What did you expect to see?

This file be split and merged into functions.json and types.json.

Incidentally, functions.md is not at all explaining the structure of functions.json, so it should be corrected as well.

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

I'll make a PR if this reorganization is agreed but no one does it, but that would be after I having finished writing and testing the script (probably in June).

[github-actions[bot]]

It looks like this is your first issue. Welcome! 👋 One of the project maintainers will be with you as soon as possible. We appreciate your patience. To safeguard the health of the project, please take a moment to read our code of conduct.

[lahmatiy]

I missed when functions.json was added. As to me it should be merged back into syntaxes.json. The types.json is actually contains generic types, in other words types that has no syntax definition but a prose definition in CSS specs. Having a split in functions and other types makes no sense in terms of CSS.

[yarusome]

I found that types.json contain both prose-only types (such as <number>) and types that do have syntaxes (such as <display-internal>), meanwhile the schema for types.json doesn't allow for a syntax key. I could add a special case to split types into syntaxes.json and types.json based on the presence/absence of syntax, but this dichotomy seems unnecessary :thinking: (I'll leave units.json as it is despite of the fact that their types are "value" in Webref).

So there're two ways to move forward:

1. Split any data in Webref of the "type" type into syntaxes.json and types.json based on the presence/absence of syntax.
2. Change the schema for types.json, and split syntaxes.json into funtions.json and types.json.

[caugner]

Thank you for opening this issue, and sorry for the long waiting time. 🙏

Unfortunately, I'm not very familiar with mdn/data, so I must be missing some important context here.

@yarusome As I understand, the combined syntaxes.json makes it more difficult for you to diff mdn/data and w3c/webref. Can you explain the background of this diff?

The documented plan has been to deprecate this package in favor of w3c/webref, which is blocked by references to mdn-data in yari. Since this package is used a lot with 26 million weekly downloads, we need to have a very good reason for this breaking change.

If all the data in mdn-data can be derived from w3c/webref (can it?), then it might make sense to publish mdn-data v3 such that it extracts the data from w3c/webref and merely presents it in the current format. But I'm not sure what the advantage of mdn-data's representation is in comparison to w3c/webref?

[caugner]

@yarusome Can you please take a look at my previous comment?