- From: Roman Komarov via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Nov 2024 23:01:24 +0000
- To: public-css-archive@w3.org
As a note for my original test case: I see how it could be ambiguous, but in that test case I did not intend it to be `true` (it having `lightgreen` was misleading). I wanted to eventually follow up on this ambiguity as well, but @andruud did it first :) I agree that it is better to treat it as `false` or `unknown`. I don't know which will be better. From an author perspective, `false` would be more expected, and Safari TP seems to treat it this way: `@container not style(--test: b)` there results in container query matching. If it were `unknown`, it would result in `unknown`, with the container query not matching, unless I misunderstand the [Kleene logic](https://en.wikipedia.org/wiki/Three-valued_logic#Kleene_and_Priest_logics) that is [mentioned in the specs](https://drafts.csswg.org/css-values-5/#boolean-logic), and which I am not too familiar with. That said, will the `style(--test: b)` be IACVT in this case? We should be able to know that the `b` does not match the `syntax` of `--test`, and it will be akin to a comparison like `const foo = 10; if (foo === 'b')` in JS: we know that the types do not match, so we can be certain that this is just `false`. I know that the intent after the `unknown` is to be future-compatible, but maybe this should not apply to registered custom properties? -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11143#issuecomment-2452697423 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 1 November 2024 23:01:25 UTC