[css-conditional-values-1] Fix Bikeshed errors

Author: LeaVerou

css-conditional-values/Overview.bs

@@ -52,28 +52,57 @@ Boolean constants: ''true'' and ''false''  {#bool-constants}
 	<dfn export>&lt;boolean-constant></dfn> = <dfn export>'true'</dfn> | <dfn export>'false'</dfn>
 </pre>
 
-Logical comparisons: The <<condition>> type
+Logical comparisons: The <<condition>> type {#condition}
 ---------------------------------------------
 
 <pre class="prod def" nohighlight>
-	<dfn export>&lt;condition></dfn> = not <<condition-in-parens>>
+	<dfn>&lt;condition></dfn> = not <<condition-in-parens>>
 	                     | <<condition-in-parens>> [ and <<condition-in-parens>> ]*
 	                     | <<condition-in-parens>> [ or <<condition-in-parens>> ]*
-	<dfn export>&lt;condition-in-parens></dfn> = ( <<condition>> ) | <<atomic-condition>>
-	<dfn export>&lt;atomic-condition></dfn> = <<comparison-operand>> <<comparison-operator>> <<comparison-operand>> | <<boolean-constant>>
-	<dfn export>&lt;comparison-operand></dfn> = <<dimension>> | <<number>> | <<percentage>> | <<ident>>
+	<dfn>&lt;condition-in-parens></dfn> = ( <<condition>> ) | <<atomic-condition>>
+	<dfn>&lt;atomic-condition></dfn> = <<comparison-operand>> <<comparison-operator>> <<comparison-operand>> | <<boolean-constant>>
+	<dfn>&lt;comparison-operand></dfn> = <<dimension>> | <<number>> | <<percentage>> | <<ident>>
 	<dfn>&lt;comparison-operator></dfn> = [ '=' | '>=' | '>' | '<' | '<=' ]
 </pre>
 
 <<condition>> values are logical expressions that resolve to a <<boolean-constant>>
 by performing simple comparisons and following basic boolean operators.
-When using 'and' or 'or' operators, precedence must be enforced with parentheses.
-The ''not'' operator does not require this, and has higher precedence than ''and'' and ''or''.
+When using `and` or `or` operators, precedence must be enforced with parentheses.
+The `not` operator does not require this, and has higher precedence than `and` and `or`.
 
-Both <<comparison-operand>> values in <<atomic-condition>> need to be of the same type. If they are not, the entire condition becomes an
-<dfn export>invalid condition</dfn> and evaluates as 'false'.
+Each of these grammar terms is associated with a boolean result,
+as follows:
 
-Issue: Do we need a third, "invalid" state here?
+: <<condition>>
+: <<condition-in-parens>>
+:: The result is the result of the child subexpression.
+
+: not <<condition-in-parens>>
+:: The result is the negation of the <<condition-in-parens>> term.
+	The negation of unknown is unknown.
+
+: <<condition-in-parens>> [ and <<condition-in-parens>> ]*
+::
+	The result is true if all of the <<condition-in-parens>> child terms are true,
+	false if at least one of the <<condition-in-parens>> is false,
+	and unknown otherwise.
+
+: <<condition-in-parens>> [ or <<condition-in-parens>> ]*
+::
+	The result is false if all of the <<condition-in-parens>> child terms are false,
+	true if at least one of the <<condition-in-parens>> is true,
+	and unknown otherwise.
+
+These rules are consistent with the way conditions are resolved in [[css-conditional-3]].
+
+Issue: Together with this, there are currently 3 specs
+([[css-conditional-3]], [[mediaqueries-4]]) using boolean operators,
+and two defining how they work ([[css-conditional-3]] and this).
+Ideally, this should be defined in one place, and cited everywhere else.
+
+Both <<comparison-operand>> values in <<atomic-condition>> need to be of the same type.
+If they are not, the entire condition becomes an
+<dfn export>invalid condition</dfn> and evaluates to unknown.
 
 These operations are only defined on <a>computed values</a>.
 (As a result, it is not necessary to define, for example,
@@ -91,14 +120,12 @@ these relative values resolve in the same way as regular values in the declarati
 
 Note: Why are we using ''='' for equality and not ':' as is established in [[css-conditional-4]] already?
 Because a lot of third party code (syntax highlighters etc) assumes that colons separate declarations and would break.
-Also, ''foo: bar'' establishes a key-value pair,
+Also, `foo: bar` establishes a key-value pair,
 whereas in equality comparisons the two operands are of equal weight,
 and do not establish a key-value pair.
 
 Issue: Do we need a "not equals" operator or is 'not(op1 = op2)' sufficient?
 
-Issue: How low level should this be? Do we need to define how logical operators work?
-
 The <<condition>> is resolved at computed value time, though its calculation tree may be simplified earlier.
 
 <div class=example>
@@ -112,7 +139,7 @@ The <<condition>> is resolved at computed value time, though its calculation tre
 Computed Value</h4>
 
 The [=computed value=] of a <<condition>> value
-is its [=calculation tree=] [=simplified=],
+is its [=calculation tree=] simplified,
 using all the information available at [=computed value=] time.
 (Such as the ''em'' to ''px'' ratio,
 how to resolve percentages etc.)
@@ -126,16 +153,17 @@ a <<condition>> always simplifies down to a single <<boolean-constant>>.
 
 Issue: Define these concepts for comparisons (currently they point to calc())
 
-Inline conditionals: The ''if()'' function
+Inline conditionals: The ''if()'' function {#if}
 ===========================================
 
-The ''if()'' function allows authors to set a property value (or parts thereof)
+The <dfn>if()</dfn> function allows authors to set a property value (or parts thereof)
 to different values based on certain conditions.
 
 <pre class="prod def">
-<<if()>>  = if( <<condition>>, <<consequent>> [, <<antecedent>>]?)
-<<consequent>> = <<declaration-value>>
-<<antecedent>> = <<declaration-value>>
+
+<<if()>> = if( <<condition>>, <<consequent>> [, <<antecedent>>]?)
+<dfn>&lt;consequent></dfn> = <<declaration-value>>
+<dfn>&lt;antecedent></dfn> = <<declaration-value>>
 </pre>
 
 Issue: How can authors specify consequents or antecedents that include commas?
@@ -148,7 +176,7 @@ Alternative syntax that adresses this, though may be hard to read when consequen
 </pre>
 
 <div class=example>
-	Authors can write mini media queries by comparing viewport and absolute units:
+	Authors can write inline media queries by comparing viewport and absolute units:
 
 	<pre>flex-flow: if(100vw > 500px, row, column);</pre>
 </div>
@@ -183,6 +211,8 @@ as the ''var()'' function, for the same reasons.
 Issue: How to disambiguate when used in a place where arguments are disambiguated by type?
 Unlike ''var()'', this cannot just be resolved at substitution,
 because we need to be able to interpret the values to compute the condition and perform the substitution accordingly.
+One way to address this would be to mandate that both <<consequent>> and <<antecedent>> need to be of the same type.
+How much does that limit use cases?
 
 Privacy and Security Considerations {#priv-sec}
 ===============================================