Clarification on multi-spec value definitions in consolidated CSS report

[pyoor]

According to the changelog:

The consolidation removes duplicates, merging extended definitions into a single feature. The definition from the latest spec level is used when a feature is defined in more than one level. If you need the definition from earlier levels, please raise an issue to describe your needs!

I use webref to determine what features are supported by a given browser. Often times, browsers do not support the latest version of a spec, especially when the spec was only recently released or changed.

Rather than using the latest definition, it would be preferable to either:

• Combine the syntax for all specs while removing duplicates (this is what I do currently)
• Include an array of all syntax definitions
• Expose all of the original specs as done in v6 in addition to the consolidated report

[tidoust]

I use webref to determine what features are supported by a given browser. Often times, browsers do not support the latest version of a spec, especially when the spec was only recently released or changed.

Trying to capture the use case more precisely, are you looking for:

1. a single combined syntax that only contains constructs supported in at least one browser;
2. a combined syntax per browser;
3. or simply the list of definitions so that you can make a choice on your own? (and how do you make a choice?)

Also, is looking at CSS levels the right approach? In other words, do they correctly distinguish between what's supported vs. what may not yet be supported?

We've been thinking about hooking into BCD to provide a consolidated syntax that would be tied to what core browsers actually support, thinking that there may be syntaxes that are not supported by browsers in practice even though the spec hasn't been changed for some time. Now that's harder to achieve as it requires analyzing the CSS syntaxes. It would also create a sort of chicken and egg situation as BCD uses the information in Webref to assess support in browsers.

Combine the syntax for all specs while removing duplicates (this is what I do currently)

I'm not sure I get what you mean by that, could you expand a bit on how it differs from the current approach? Any example? Any pointer to a bit of code that would have the logic, perhaps?

* Include an array of all syntax definitions
* Expose all of the original specs as done in v6 in addition to the consolidated report

I understand that's less convenient than having the data in an NPM package but, in the meantime, even if we stop publishing v6, I note the data per spec remains available in the repo itself, and that should not change given that we need that data to run the consolidation in the first place. See the ed/css folder of the @webref/css@latest branch for the data that gets used in the latest published npm package.

Practically speaking, it also means it's easy to ship the data per spec (the v6 view) in the npm package. If we do that, we might want to tweak the way we review package releases to avoid lengthy and somewhat duplicated diffs in the review PR.

[pyoor]

Trying to capture the use case more precisely, are you looking for:

1. a single combined syntax that only contains constructs supported in at least one browser;

2. a combined syntax per browser;

3. or simply the list of definitions so that you can make a choice on your own? (and how do you make a choice?)

Number 3. I make this decision on my own by generating base values for each of the terminal types and evaluating them in the browser. The result of which is the CSS value definition syntax that is supported in a particular browser and version.

Also, is looking at CSS levels the right approach? In other words, do they correctly distinguish between what's supported vs. what may not yet be supported?

They don't and that's why I evaluate them myself.

Combine the syntax for all specs while removing duplicates (this is what I do currently)

I'm not sure I get what you mean by that, could you expand a bit on how it differs from the current approach? Any example? Any pointer to a bit of code that would have the logic, perhaps?

The general idea is that a browser may still support a deprecated feature of a spec as well as the latest editors draft. Consider the following:

// Spec version 1
<type1> = "a" | "b" | "c"

// Spec version 2
<type1> = "c" | "d" | "e"

// Resulting value
<type1> ="a" | "b" | "c" | "d" | "e"

I would then iterate over each possible value to determine which aspects of the old and new specs are supported.

I understand that's less convenient than having the data in an NPM package but, in the meantime, even if we stop publishing v6, I note the data per spec remains available in the repo itself, and that should not change given that we need that data to run the consolidation in the first place. See the ed/css folder of the @webref/css@latest branch for the data that gets used in the latest published npm package.

Using the repo directly is certainly an option for me, though obviously a bit less convenient. I originally filed this bug because I noticed the message in the changelog.