[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.

[mirisuzanne]

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

I think we should at the very least plan for something that is unambiguous with basic CSS types like colors. But I'm not sure we need it to be unambiguous with an arbitrary syntax like that?