Suggestions on css/syntaxes.json

[lahmatiy]

Currently css/syntaxes.json contains various types of syntaxes. Most of them are for values, rest are for at-rules and others. I believe those syntaxes should be stored in diferent dictionaries or have a special marker, since those syntaxes using diferrent grammar.

As we know this data was originally used on MDN. That's why some symbols like <, >, & and others were escaped (for safety inject to HTML documents I guess). Some syntaxes has <var> in their definition. It's verbose and doesn't need in non-HTML context. Mostly it can be automatically excaped when needed.

Probably format should be extended to store additional infomation about syntax as reference to spec, standart or not, etc.

Suggestions:

• split css/syntaxes.json into values syntaxes and something else (or move it to appropriate dictionary, e.g. to css/at-rules.json), or just remove non-value syntaxes away
• remove html-excaping from syntaxes (and from other fields, if possible, and in every files)
• extend dictionary format to store additional info

[SebastianZ]

I was never perfectly happy with the syntaxes construct but couldn't come up with a better solution, so, I'm happy you mention it now.

… Some syntaxes has <var> in their definition. It's verbose and doesn't need in non-HTML context. Mostly it can be automatically excaped when needed.

How do you imagine the automatic escaping to work? How should those variables be stored then?

Probably format should be extended to store additional infomation about syntax as reference to spec, standart or not, etc.

Do you refer to the group and status properties of the other JSON files? Or do you mean detailed spec. information like spec. URLs and their status?

Note that the spec. information is currently still stored on MDN within the SpecName and spec2 templates, but will be moved to GitHub at some point, too. This will probably be done in bug 1280225.

Suggestions:

• split css/syntaxes.json into values syntaxes and something else (or move it to appropriate dictionary, e.g. to css/at-rules.json), or just remove non-value syntaxes away

Note that the values related to at-rules are also syntaxes, and are even shared among at-rules and properties in some cases. E.g. <keyframes-name> is used for the animation-name property as well as the @keyframes rule, so I believe they should be kept at a shared place.
Though maybe it should be renamed to better reflect what they mean.

• remove html-excaping from syntaxes (and from other fields, if possible, and in every files)

I think I had to do that on MDN side for some reason. Need to investigate that again.
If there are no issues anymore, I'm fine to change that.

After all, this issue should be split up, so its different parts can be tackled individually.

Sebastian

[lahmatiy]

How do you imagine the automatic escaping to work? How should those variables be stored then?

<var> is used for just two syntaxes (an-plus-b and minmax()) and I don't know why. But I mean special symbols escaping for HTML-context, i.e.

"cf-mixing-image": "<percentage>? && <image>",

should be stored as:

"cf-mixing-image": "<percentage>? && <image>",

Do you refer to the group and status properties of the other JSON files? Or do you mean detailed spec. information like spec. URLs and their status?

Any additional information can be useful. Sometimes is too hard to find details about property or syntax - and no clue what it uses for.

Note that the values related to at-rules are also syntaxes, and are even shared among at-rules and properties in some cases.

I talk about syntaxes that use non CSS Values and Units Module grammar, in particular:

• an-plus-b
• feature-type
• feature-value-block
• feature-value-declaration
• general-enclosed
• keyframe-block
• mf-plain
• mf-range
• page-body
• page-margin-box
• page-margin-box-type
• pseudo-page
• var

I think I had to do that on MDN side for some reason.

Well, dictionary already splitted into several files. So, I believe changes are possible ;) All you need is simple convertor...

After all, this issue should be split up, so its different parts can be tackled individually.

Agree. I would like to discuss the opportunity before creating issues for specific tasks.

[Elchi3]

There are multiple suggestions in this issue, and I want to mention that I also would like to avoid HTML entities in the JSON. (<number> and not <number>). It would make reviewing a lot easier. Can we split the issues discussed here into separate ones and work on those where we agree already?

[lahmatiy]

@Elchi3 Done! 👌
Feel free to fix issue descriptions if something wrong.

[Elchi3]

Thanks for all these suggestions! I think we can continue in the separated issues.