- From: andruud via GitHub <noreply@w3.org>
- Date: Sat, 14 Jun 2025 08:01:37 +0000
- To: public-css-archive@w3.org
> > 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. -- GitHub Notification of comment by andruud Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12330#issuecomment-2972458383 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 14 June 2025 08:01:38 UTC