Clarify semantics of CSS extracts

[dontcallmedom]

It emerges in #1288 that the ambiguity that exists in the CSS-related dfn-type of the DFN contract has sipped into our model of CSS extracts.

In particular, #1288 stems for our tests currently flagging <combinator> in css-mixins-1 as duplicate of <combinator> in selectors-4, whereas the two names are not in the same namespace: the latter is used to parse a selector, the former to parse a CSS value, but both appears under a values list with a type: type.

Unless we find spec-evidence that the two names are in fact meant to be in the same namespace (and thus the test failure would be a sign of a spec bug), we need to not fail in such a situation, which I think entails surfacing that namespacing one way or another.

My personal interpretation of values in our CSS extracts was to match https://drafts.csswg.org/css-values-4/#value-defs , in which case <combinator> should not appear under such a list in selectors.json, and we would need either to find a way to ignore these constructs in reffy, or (probably preferably) find a way to surface them in a different structure.

[tidoust]

In particular, #1288 stems for our tests currently flagging in css-mixins-1 as duplicate of in selectors-4, whereas the two names are not in the same namespace: the latter is used to parse a selector, the former to parse a CSS value, but both appears under a values list with a type: type.

I'm still not clear about what a "CSS value" is, and how it is to be scoped. In this particular example: <combinator> in css-mixins-1 is being used by the definition of the @function at-rule for expressing the grammar of <type> next to the returns keyword. What makes it something used to parse a CSS value? That's not really the right hand side of anything. Why is it conceptually different from a construct used to parse a selector?

Similarly, with that logic, what should <function-name> be?

Unless we find spec-evidence that the two names are in fact meant to be in the same namespace (and thus the test failure would be a sign of a spec bug), we need to not fail in such a situation, which I think entails surfacing that namespacing one way or another.

Isn't the fact that these two names cannot be defined in one spec with appropriate definition types evidence that the names are, so far at least, meant to be in the same namespace? If you combine the two definitions in one spec, Bikeshed will report a multiple local 'type' <dfn>s error.

You could elect to use value instead of type for the value. In theory, any value must be namespaced to something. That makes value impractical for constructs such as those used in function definitions. Well, no doubt that requirement is not well respected in practice across specs.

Anyway, I would focus more initially on finding ways to surface the distinction in the specs rather than in our extracts. I'm at step zero today: I don't see a clear distinction, and I don't know how to surface it ;)