[css-contain] Is <container-name> conflicting with <'container-name'>?

[cdoublev]

The CSS - property - value definition syntax says:

Property value ranges, which represent the same pattern of values as a property bearing the same name. These are written as the property name, surrounded by single quotes, between < and >, e.g., <'border-width'>, <'background-attachment'>, etc.

It does not disallow <container-name> to represent a value that is different than the value definition of container-name.

But <container-name> creates a precedent that prevents re-using <property> as a type that would represent the value definition of property (without ignoring #).

Is it voluntary? Is it problematic?

[tabatkins]

But it prevents re-using as a type that would represent the value definition of property (without ignoring #).

I'm not sure what you mean by this, could you elaborate?

[cdoublev]

I do not have good example. Assuming that border-top and outline would be defined with the same syntax, which would include a comma-separated value, you would not be able to define the outline property with <border-top>.

But it seems that aliasing another property value definition would be the only use case.

However, I am less interested by the potential use cases for re-using a property value definition with <property>, than by a clean CSS value definition syntax that would prevent confusing the meanings of <'property'> and <property>.

[cdoublev]

Nevermind, there is a long-standing precedent with <color>, which happens to be the exact value definition of color.

Maybe CSS Values should just clarify that <'...'> is the only way to re-use the value definition of a property, and that <foo> does not represent the value definition of any existing property named foo.

[tabatkins]

I'm not sure what needs to be clarified, to be honest. We never imply that <foo> refers to a 'foo' property. It's just an arbitrary non-terminal, which is a very common concept across all grammar-based description languages. The only connection with a given property is the explicitly-called out alternate syntax of <'foo'>, which isn't valid as a non-terminal otherwise.

[cdoublev]

I have a small experience in these languages but I think it could have been usefull to expand <foo> with the value definition of the property named foo. A consequence is that there could not have been non-terminals bearing the same name as a property and expanding to a different value definition.

As a practical example, one may parse the input of grid-template-areas against <grid-template-areas>, and register a function associated to this non-terminal name to further validate the result from parsing against its basic syntax.

But as commented above, parsing color, which is defined with <color>, would probably be broken.

This was only my humble opinion and there are workarounds for the above example, of course.