[css-conditional-5] Evaluate IACVT style queries to false

[andruud]

The current spec can be interpreted to evaluate the following style query to true:

  @property --test {
    syntax: "a";
    initial-value: a;
    inherits: true;
  }
  @container style(--test: b) {
    body {
      background: lightgreen;
    }
  }

(Test case from @kizu.)

This is because the query value is described to go through the regular computed value process, and additionally non-cascade dependent keywords are allowed (that includes unset, which IACVT falls back to). This causes --test:b => IACVT => unset => a, which indeed is the computed value of --test on body.

I'm fairly certain that we want to evaluate any IACVT query to "false"? @mirisuzanne @lilles

[lilles]

I fairly certain that we want to evaluate any IACVT query to "false"? @mirisuzanne @lilles

Yes, I think so.

It's probably useful to consider what will happen with IACVT if/when we start supporting standard properties.

For instance @container style(color: var(--my-length)) and --my-length: 2px. Making that unset and have it match depending on whether the style container has the same computed color as its parent or not sounds strange, yes.

I don't remember if there was a discussion around allowing unset and inherit, but initial definitely makes sense.

[mirisuzanne]

I agree that IACVT should not evaluate true - but should it be false or unknown?

[kizu]

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 that is mentioned in the specs, 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?

[tabatkins]

Right, they should be false, not unknown. We're testing whether a given property's value equals a certain value; if the value we're testing against triggers IACVT, then the value that it is (which is, by definition, a valid value) is clearly not equal to that. This isn't the same as an unrecognized query, which might represent a question that would be true if the UA understood it.

(If the IACVT is due to something being unrecognized, then a more modern UA might understand it and return true, but this UA that's currently executing the query doesn't understand it, by definition, so it's not equivalent to any value the UA does understand.)

[andruud]

Proposed: A <style-feature> that is IACVT evaluates to false.

[astearns]

The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment.

Proposed Resolution: A <style-feature> that is IACVT evaluates to false.

[astearns]

RESOLVED: A <style-feature> that is IACVT evaluates to false.