Migrate to `@webref/css` for syntax data

[romainmenke]

Migrate to `@webref/css` for syntax data

[lahmatiy]

I have no such plans. While @webref/css offers a source of syntax data that could potentially enhance dictionaries like mdn/data, it cannot fully replace them. Utilizing @webref/css presents several challenges:

• Specification versions: Multiple levels (versions) exist for many specs. While subsequent levels sometimes merely extend their predecessors, allowing for the use of the latest version, this isn't always the case. Certain specifications might undergo deletions or modifications. Consequently, a syntax that is valid in one version might become obsolete in another, even if the older version remains prevalent and browser-supported. It's worth noting that browsers occasionally support intermediate syntax states, which once appeared in a specification but were not retained in its final version.
• Draft specs: The inclusion of syntaxes from draft specs is debatable. Even if a feature is supported by multiple browsers, its corresponding spec might still be in draft or another non-REC status. Conversely, some features might implemented by browser vendors in their initial draft state without without an alignment to the latest state for a long time.
• Syntax details in prose: @webref/css extracts syntaxes from definition sections. However, certain syntax nuances are elaborated in prose, necessitating manual extraction, which isn't currently facilitated.
• Proprietary syntaxes: vendor-prefixed or proprietary syntaxes, despite their widespread use in development, don't feature in official specs.

In essence, while @webref/css can validate how CSS aligns with the present or upcoming specification states, CSSTree's goal is to validate CSS against versions that browsers currently support, or have supported in the past. In this context, mdn/data, despite its imperfections, aligns more closely with this objective.

Absolutely, the merits of @webref/css are acknowledged, and it indeed addresses specific needs effectively. Nonetheless, for a more holistic approach to CSS validation, the creation of a distinct, comprehensive dictionary is advocated. This resource would amalgamate the strengths of @webref/css and a meticulously curated, manually updated support matrix akin to caniuse (though caniuse is not directly applicable in this context since it doesn't provide syntaxes).

This proposed dictionary would offer a consolidated, dynamic resource that integrates the detailed, spec-aligned syntax data from @webref/css with real-world browser support information. It would bridge the gap between theoretical specification adherence and practical, on-the-ground implementation, ensuring developers have access to a robust, accurate, and up-to-date resource for CSS validation. Currently mdn/data in this role.

[romainmenke]

I agree with your feedback.

I've been using @webref/css in various packages as a source of data and found that it frequently adds new and broken syntax definitions only to remove these again a few days later. Because it reflects the main branch on csswg-drafts there is too much happening there that will (or should) never ship in browsers.

I never used it as a production dependency and after gaining some experience with it I would advise against this. It is a very good resource in build scripts, or for more manual data scraping. Things where eventually a human still interprets the data.

---

My main concern was seeing that mdn/data is considered to be deprecated and that @webref/css is listed as the replacement.

I don't think @webref/css can be a replacement for mdn/data in its current form.

This issue is answered for me and can be closed.

[romainmenke]

Almost forgot...

Thank you @lahmatiy for the detailed answer 🙇
Very valuable insights.