[css-conditional][css-values] Allow setting type for style() condition comparisons

[mirisuzanne]

The style() condition in @container and if() behaves differently depending on the type of the custom property being queried. If --color is registered with the <color> syntax, and --token is not, but both are assigned the red value, then style(--color: #f00) will be true, and style(--token: #f00) will be false.

Ideally, authors should be able to assign a type for the condition instead of relying on the registration of individual properties. I raised this on a separate issue about function parameter types, and @tabatkins suggested --foo as <type>: val for a syntax. This should also work in a range syntax: 10px < --foo as <length> < 20px.

[andruud]

I don't think this would be needed for ranges. --foo in your ranged example would anyway be "coerced" into a <length> if it indeed contains something that parses as a length.

Will we ever need to type-ify a literal value without a property to lean on? E.g. red as <color> => rgb(255, 0, 0).

[mirisuzanne]

I don't think this would be needed for ranges. --foo in your ranged example would anyway be "coerced" into a if it indeed contains something that parses as a length.

Good point. That is still true in a range like style(--min < --current < --max), right?

Will we ever need to type-ify a literal value without a property to lean on? E.g. red as <color> => rgb(255, 0, 0).

I'm not sure I understand when type would be technically necessary. If we can already compare px with rem and get resolved value comparisons, is there a reason that color names would need to be explicitly typed for a comparison?

[andruud]

I don't think this would be needed for ranges. --foo in your ranged example would anyway be "coerced" into a if it indeed contains something that parses as a length.

Good point. That is still true in a range like style(--min < --current < --max), right?

Yes.

Will we ever need to type-ify a literal value without a property to lean on? E.g. red as <color> => rgb(255, 0, 0).

I'm not sure I understand when type would be technically necessary. If we can already compare px with rem and get resolved value comparisons, is there a reason that color names would need to be explicitly typed for a comparison?

For the style(--prop:value) form, it's not needed. If --prop if is a <color>, then the right hand side is also treated as a color. However, if we invent a way to compare two literal values (non-numeric ones), then we don't have --prop to lean on; something else needs to tell us the type. I don't think we have a way to compare two literal <color>s at the moment: if(style(rgb(255, 0, 0) = rgb(255, 0, 0):true;else:false) is false per the proposal we resolved on elsewhere, since = only understands numeric values (for now).

So maybe it's not needed right now, but it could still affect this discussion since <literal> as <type> isn't going to work: e.g. as as type(as+) is ambiguous.