Re: [csswg-drafts] [css-values-4][Editorial] `<condition>` type that other specs reference (#10457)

The CSS Working Group just discussed ``[css-values-4][Editorial] `<condition>` type that other specs reference``, and agreed to the following:

* `RESOLVED: Add <boolean-expr[...]> as a value definition syntax function multiplying its argument into a boolean expression microsyntax`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: we have a lot of places we'<br>
&lt;TabAtkins> fantasai: we're using the not/and/or microsyntax - MQs, SQs, style queries, etc<br>
&lt;TabAtkins> fantasai: and now if()<br>
&lt;TabAtkins> fantasai: So we decided it would be more understandable to factor out that commonality into its own syntax "multiplier"<br>
&lt;TabAtkins> fantasai: similar to * and # in grammars<br>
&lt;TabAtkins> fantasai: So we introduced `&lt;boolean [&lt;grammar-here>]>`<br>
&lt;TabAtkins> fantasai: This isn't for authors to write, it's part of our Value Definition Syntax<br>
&lt;fantasai> https://drafts.csswg.org/css-values-5/#boolean<br>
&lt;TabAtkins> fantasai: whatever's inside the brackets is a parameter for the boolean tree (it's the leaves of the and/or/not tree)<br>
&lt;fantasai> https://drafts.csswg.org/css-values-5/#value-defs<br>
&lt;TabAtkins> fantasai: It's defined here, and also in the valdefs list<br>
&lt;TabAtkins> fantasai: [describes the syntax]<br>
&lt;TabAtkins> astearns: Currently it's just in Values 5, hasn't moved to toher specs?<br>
&lt;TabAtkins> fantasai: right<br>
&lt;dbaron> btw my comment about naming was about sounding like true/false rather than and/or/not<br>
&lt;fantasai> TabAtkins: we have an example of applying it to @container queries, since that's a complex grammar<br>
&lt;fantasai> TabAtkins: makes it easier to understand<br>
&lt;fantasai> astearns: [reads dbaron's comment]<br>
&lt;fantasai> TabAtkins: Lea also had this comment<br>
&lt;fantasai> TabAtkins: open to suggestions<br>
&lt;TabAtkins> fantasai: we didn't want to go with "condition" because it's such a generic term, seemed like it would actually be less clear<br>
&lt;TabAtkins> dholbert: "boolean-condition"?<br>
&lt;TabAtkins> fantasai: note that it is a functinoal syntax, not just `&lt;boolean>` by itself, there's something between the [].<br>
&lt;TabAtkins> astearns: do we want any particular resoltion?<br>
&lt;TabAtkins> fantasai: if we're happy, we can accept adding it to the VDS<br>
&lt;TabAtkins> astearns: I think I'd like to noodle on the name a bit more<br>
&lt;TabAtkins> astearns: but i don't really have an idea of what to repalce it with<br>
&lt;TabAtkins> fantasai: we could make it longer with `&lt;boolean-expression [...]>` but unsure if that's clearer<br>
&lt;TabAtkins> dholbert: makes it clearer it's not just true/false in the programming sense<br>
&lt;TabAtkins> dholbert: in the issue I saw a bunch of `&lt;*-condition>` grammar terms used with it, so maybe `&lt;boolean-condition>` would be good to follow it<br>
&lt;TabAtkins> fantasai: What we're trying to say is that this is the epxression syntax, not the conditions themselves. The condition is inside the []<br>
&lt;fantasai> &lt;boolean[ &lt;test> ]> = not &lt;boolean-group> | &lt;boolean-group><br>
&lt;fantasai>                                             [ [ and &lt;boolean-group> ]*<br>
&lt;fantasai>                                             | [ or &lt;boolean-group> ]* ]<br>
&lt;fantasai> &lt;boolean-group> = &lt;test> | ( &lt;boolean[ &lt;test> ]> ) | &lt;general-enclosed><br>
&lt;TabAtkins> fantasai: [explains]<br>
&lt;TabAtkins> fantasai: it's kinda a syntactic function in the same way as + is, just more sophisticated<br>
&lt;fantasai> &lt;container-query> = &lt;boolean[ &lt;cq-test> ]><br>
&lt;TabAtkins> astearns: I think I do prefer boolean-expr in that last example<br>
&lt;TabAtkins> fantasai: ok<br>
&lt;kbabbitt> I like &lt;boolean-expression[...]> as well<br>
&lt;TabAtkins> fantasai: so should we resolve to add boolean-expression?<br>
&lt;kbabbitt> boolean-expr is fine too<br>
&lt;TabAtkins> TabAtkins: i really want to shorten it to expr, I did that reflexively when minuting<br>
&lt;fantasai> PROPOSED: Add &lt;boolean-expression[...]> as a value definition syntax function multiplying its argument into a boolean expression microsyntax<br>
&lt;TabAtkins> fantasai: i'm fine, tho we don't usually use shortened terms<br>
&lt;fantasai> fantasai: it would be exposed in @property?<br>
&lt;TabAtkins> astearns: let's propose it with boolean-expr<br>
&lt;fantasai> TabAtkins: no, not unless we say so<br>
&lt;TabAtkins> astearns: objection?<br>
&lt;fantasai> RESOLVED: Add &lt;boolean-expr[...]> as a value definition syntax function multiplying its argument into a boolean expression microsyntax<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10457#issuecomment-2461076362 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 7 November 2024 00:27:54 UTC