[css-contain] Allow container query style features to evaluate in a boolean? #8127

mirisuzanne · 2022-11-22T18:33:27Z

Dimensional media/container queries can evaluate in a boolean context. This isn't terribly useful (dimensional queries aren't the main use-case for booleans), but it works:

@container (inline-size) {
  /* element has an inline-size container 
      with inline-size greater than 0 */
}

With style queries, a boolean check is much more useful:

@container style(gap) {
  /* remove margins when a gap is defined? */
}

@container style(--button-theme) {
  /* shared styles for all button themes? */
}

@container style(--reverse) {
  /* styles for something that's reversed? */
}

I think all these checks are possible in the current spec by querying for initial and negating the query, so allowing boolean queries would just be syntax sugar:

@container not style(gap: initial) {
  /* remove margins when a gap is defined? */
}

@container not style(--button-theme: initial) {
  /* shared styles for all button themes? */
}

@container not style(--reverse: initial) {
  /* styles for something that's reversed? */
}

The text was updated successfully, but these errors were encountered:

LeaVerou · 2023-01-30T15:02:26Z

+1 to this. There are use cases, and it's congruent with the principle of least surprise, since all other types of queries support this.

In fact, this seems straightforward enough that maybe we can resolve on async?

una · 2023-01-30T15:16:38Z

+1 to this, here's an example where I needed it to reduce redundancy: https://codepen.io/una/pen/LYBrYGX. If I could check for the presence of the --detail boolean, I wouldn't have to re-write shared logic.

LeaVerou · 2023-01-30T15:25:42Z

@astearns @atanassov do you think we could resolve async on this?

mirisuzanne · 2023-01-30T18:49:34Z

This should be defined in a way that also works with standard properties as well as custom properties, right? If the query is checking for a value other than 'guaranteed invalid', that would only work on custom properties. Would we check for a value other than the defined initial value? Or would we need some other definition of truthy/falsey values?

@container

@container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e

astearns · 2023-02-02T22:49:12Z

Can this be resolved async for both custom properties and regular properties, or does the definition need to be worked through first? Please add a proposed resolution if you want to go the async route

LeaVerou · 2023-02-03T15:02:20Z

I think the definition is pretty straightforward: it evaluates to true if the property is NOT initial. Some kinks still need to be ironed out for regular properties and registered custom properties (e.g. if a property is explicitly set to its initial value, e.g. font-weight: normal does it evaluate to false? That seems unintuitive, but not sure how else to design something reasonably implementable) but we can still resolve to add the feature, and work through issues related to the design like any other issue on any other spec.

Loirooriol · 2023-02-03T17:39:52Z

Checking revert instead of initial might also be interesting.

mirisuzanne · 2023-02-03T18:04:58Z

Checking revert instead of initial might also be interesting.

Good point, for regular properties this is much more likely to match author expectations.

una · 2023-02-07T17:44:03Z

What is @container(--var) if we have --var: false?

It's kind of funky, but according to how we're discussing this, I would expect @container(--var) to return true since --var is defined, and would by default be a string value. It looks like this shouldn't conflict with @property-defined CSS custom properties either, considering boolean isn't an available syntax type (correct me if I'm wrong because that would then be an issue).

But because of this confusion ^ we should define if this is a "presence" query or if this a boolean query and discuss it as such.

andruud · 2023-02-07T20:07:11Z

@Loirooriol It's unfortunately not possible to check revert. #7080 (comment)

lilles · 2023-02-22T13:24:00Z

What is @container(--var) if we have --var: false?

It's kind of funky, but according to how we're discussing this, I would expect @container(--var) to return true since --var is defined, and would by default be a string value. It looks like this shouldn't conflict with @property-defined CSS custom properties either, considering boolean isn't an available syntax type (correct me if I'm wrong because that would then be an issue).

<boolean> is not a syntax, but you can register a syntax which has two keywords, true and false, and have false as the initial value. Then (assuming we're choosing the initial value comparison), false can evaluate to false in the boolean context.

But because of this confusion ^ we should define if this is a "presence" query or if this a boolean query and discuss it as such.

It's not a boolean query, but "evaluated in a boolean context", which is phrased like that because that's how the same thing is phrased in the media queries spec, which basically means evaluated without a value/comparison.

css-meeting-bot · 2023-03-22T16:17:39Z

The CSS Working Group just discussed [css-contain] Allow container query style features to evaluate in a boolean?, and agreed to the following:

RESOLVED: style queries can accept properties in boolean context; false if matches initial value, true otherwise

The full IRC log of that discussion

<emeyer> miriam: Container query style features can query custom properties, so the question is, can you query without the value to see if it has initial value
<emeyer> …Thus getting true or false back
<emeyer> …False if it’s the default value, true if it’s changed
<Rossen_> q?
<fantasai> sgtm
<fremy> +1
<lea> +1 obvs
<emeyer> dholbert: Would anything special be needed for Houdini registered properties?
<emeyer> miriam: Yes, you’d be checking to see if it’s the initial value, by default that would be the guaranteed value
<TabAtkins> s/guaranteed value/guaranteed-invalid value/
<emeyer> Rossen: Any questions or objections?
<emeyer> (silence)
<fantasai> RESOLVED: style queries can accept properties in boolean context; false if matches initial value, true otherwise

Per resolution in w3c#8127, style() queries can query properties without a value which evaluates to true if the computed value is different from the initial value for that property.

@container

@container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e

Per resolution in #8127, style() queries can query properties without a value which evaluates to true if the computed value is different from the initial value for that property. Co-authored-by: Rune Lillesveen <[email protected]>

@container

@container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209086 Code-Coverage: Findit <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1132964}

@container

@container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209086 Code-Coverage: Findit <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1132964}

@container

@container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209086 Code-Coverage: Findit <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1132964}

cdoublev · 2023-04-21T04:41:11Z

<style-feature> has been updated according to the above resolution and is now explicitly defined with <ident> : <declaration-value> | <ident> instead of this sole prose:

The syntax of a <style-feature> is the same as for a declaration [...]

Note: it may also have to be updated with is a property name or is the same as for a declaration [...], the basic syntax can be simplified to <declaration> | <ident> or <ident> [: <declaration-value>]?, ~~and : should be quoted, according to CSS Values~~ (not according to CSS Syntax).

In #8735, I ask for clarifications about <declaration>. It is not defined, and I am not sure if it represents a valid declaration according to the CSS syntax or more specifically, a valid declaration according to the CSS grammar, ie. color: 1px is valid according to the CSS syntax but is invalid according to the CSS grammar.

(Sorry if I am using grammar and syntax terms incorrectly/inappropriately)

If <ident> can match an invalid property (which would then not be matched as <any-value>), <declaration> can match color: 1px and represents a valid declaration (structure).

lilles · 2023-04-21T09:09:44Z

@cdoublev Good catch, and it makes a difference because it decides whether these cases evaluate to false or unknown:

style(specced-but-not-implemented-property)
style(color: 1px)
style(color: specced-but-not-implemented-value)

How about reverting the syntax change and instead change the prose to something like:

"The syntax of a <style-feature> is either a valid declaration or a supported property name"

That would result in all of the style() queries in the block above to fall back to <general-enclosed> and evaluate to unknown.

Does that look reasonable?

cdoublev · 2023-04-21T10:01:25Z

Entirely.

I have no strong opinion but I would say that <declaration> can match invalid: anything and <ident> can match invalid-property.

Loirooriol · 2023-04-21T10:40:49Z

The syntax of a <style-feature> is either a valid declaration or a supported property name

This would exclude custom properties, wouldn't it?

@container

@container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209086 Code-Coverage: Findit <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1132964}

@container

…le() queries, a=testonly Automatic update from web-platform-tests [@container] Support boolean context style() queries @container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209086 Code-Coverage: Findit <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1132964} -- wpt-commits: c9d16e205399c4a7fe1932748e01ac1315a1853e wpt-pr: 38320

cdoublev · 2023-04-24T07:06:50Z

I think I caused a bit of confusion, sorry.

The evaluation of the query may not directly depend on the result of parsing. invalid-property matches <ident>, color: invalid matches <declaration>, and both evaluate to unknown.

I stand by my suggestion and extend it:

<style-feature> = <declaration> | <ident>

https://drafts.csswg.org/css-contain-3/#typedef-style-feature

<style-feature> is associated with a boolean result. If the UA does not accept that declaration (discarding it as a parse error) or property within a style rule, the result is false. If the computed value of the given property on the query container matches the given value (which is also computed with respect to the query container) or its initial value, the result is true. Otherwise it is unknown.

https://drafts.csswg.org/css-contain-3/#style-container

Remove the recently added grammar part for style-feature that was inaccurate. Do not accept invalid declarations or unsupported property names as a style-feature. The effect of that is that we do not need to store invalid declarations, but merely fall back to parse the style() query with the invalid declaration as a general-enclosed, which will evaluate to unknown.

lilles · 2023-04-24T10:10:04Z

The syntax of a <style-feature> is either a valid declaration or a supported property name

This would exclude custom properties, wouldn't it?

You mean the "supported property name" part? Custom property declarations are valid declarations, right?

I would like to avoid is having to parse and store invalid declarations. So where the current spec says that invalid property names and values evaluate to unknown, I'd rather make style() queries with invalid declarations fall back to general-enclosed parsing which would also evaluate to unknown.

@container

…le() queries, a=testonly Automatic update from web-platform-tests [@container] Support boolean context style() queries @container style(--foo) is syntactic sugar for: @container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209086 Code-Coverage: Findit <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Commit-Queue: Rune Lillesveen <[email protected]> Cr-Commit-Position: refs/heads/main@{#1132964} -- wpt-commits: c9d16e205399c4a7fe1932748e01ac1315a1853e wpt-pr: 38320

cdoublev · 2023-04-26T07:39:51Z

The term supported CSS property refers to a CSS property that the user agent implements, including any vendor-prefixed properties, but excluding custom properties.

https://drafts.csswg.org/cssom-1/#supported-css-property

I borrowed if it accepts that property in a style rule from the prose in CSS Conditionals 3 for <supports-decl>, which I would be fine if its result would be defined as true if the declaration is successfully parsed against <declaration>, defined as matching a declaration whose value is valid according to the grammar of the property that corresponds to its name.

lilles · 2023-04-26T12:47:45Z

The term supported CSS property refers to a CSS property that the user agent implements, including any vendor-prefixed properties, but excluding custom properties.

Got it.

How about: supported CSS property or a <custom-property-name> ?

https://drafts.csswg.org/cssom-1/#supported-css-property

I borrowed if it accepts that property in a style rule from the prose in CSS Conditionals 3 for <supports-decl>, which I would be fine if its result would be defined as true if the declaration is successfully parsed against <declaration>, defined as matching a declaration whose value is valid according to the grammar of the property that corresponds to its name.

I'm not able to understand what you're trying to say here. Where did you borrow that?

cdoublev · 2023-04-26T16:39:56Z

I'm not able to understand what you're trying to say here.

Oh, sorry.

<supports-decl>, which is defined with ( <declaration> ), evaluates to true if the CSS processor accepts that declaration within a style rule (the borrowed part). I suggested that <style-feature> evaluates to true if the CSS processor accepts that property (<ident>) within a style rule, because I knew that supported CSS property excludes custom properties.

In the next part of my comment (which I should have split), I say that I would have no problem if <supports-decl> were defined to evaluate to true if the result from parsing <declaration> represents a declaration that the CSS processor accepts within a style rule. (I think that is what you want, if I understood correctly.)

…e() queries, a=testonly Automatic update from web-platform-tests [container] Support boolean context style() queries container style(--foo) is syntactic sugar for: container not style(--foo: initial) w3c/csswg-drafts#8127 Bug: 1302630 Change-Id: I087207e11df858ac325610d935a4c303e5503e0e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4209086 Code-Coverage: Findit <findit-for-meappspot.gserviceaccount.com> Reviewed-by: Anders Hartvoll Ruud <andruudchromium.org> Commit-Queue: Rune Lillesveen <futharkchromium.org> Cr-Commit-Position: refs/heads/main{#1132964} -- wpt-commits: c9d16e205399c4a7fe1932748e01ac1315a1853e wpt-pr: 38320 UltraBlame original commit: ae1485857d9c0b134901e2b35661c6dc48820cfb

lilles · 2023-05-03T10:46:17Z

I'm not able to understand what you're trying to say here.

Oh, sorry.

<supports-decl>, which is defined with ( <declaration> ), evaluates to true if the CSS processor accepts that declaration within a style rule (the borrowed part). I suggested that <style-feature> evaluates to true if the CSS processor accepts that property (<ident>) within a style rule, because I knew that supported CSS property excludes custom properties.

In the next part of my comment (which I should have split), I say that I would have no problem if <supports-decl> were defined to evaluate to true if the result from parsing <declaration> represents a declaration that the CSS processor accepts within a style rule. (I think that is what you want, if I understood correctly.)

Thanks for the clarifications.

I have a PR here: #8756

It doesn't express it the way you suggest, but should mean the same. We can continue further discussions there. Added you as a reviewer in case you want to take a look.

* [css-contain-3] Tweak the spec for style() queries #8127 Remove the recently added grammar part for style-feature that was inaccurate. Do not accept invalid declarations or unsupported property names as a style-feature. The effect of that is that we do not need to store invalid declarations, but merely fall back to parse the style() query with the invalid declaration as a general-enclosed, which will evaluate to unknown. * Reformulate and add general-enclosed evaluation --------- Co-authored-by: Rune Lillesveen <[email protected]>

mirisuzanne added the css-contain-3 label Nov 22, 2022

mirisuzanne added the Agenda+ label Jan 26, 2023

astearns added the Async Resolution: Proposed Candidate for auto-resolve with stated time limit label Jan 31, 2023

chromium-wpt-export-bot mentioned this issue Feb 2, 2023

[@container] Support boolean context style() queries web-platform-tests/wpt#38320

Merged

astearns removed the Async Resolution: Proposed Candidate for auto-resolve with stated time limit label Feb 21, 2023

css-meeting-bot removed the Agenda+ label Mar 22, 2023

chromium-helper mentioned this issue Mar 22, 2023

[css-contain] Allow container query style features to evaluate in a boolean? chromium-helper/csswg-resolutions#82

Closed

atanassov added the Needs Edits label Mar 22, 2023

mozilla-apprentice mentioned this issue Mar 22, 2023

[css-contain] Allow container query style features to evaluate in a boolean? mozilla/wg-decisions#1079

Open

lilles mentioned this issue Apr 18, 2023

[css-contain-3] Support boolean context style() queries #8127 #8729

Merged

mirisuzanne added Closed Accepted by CSSWG Resolution and removed Needs Edits labels May 3, 2023

mirisuzanne closed this as completed May 3, 2023

cdoublev mentioned this issue May 5, 2023

[css-conditional-3] Define <declaration> #8795

Open

cdoublev mentioned this issue Sep 15, 2023

[css-animations-1] Undefined procedures to get/set CSSOM attributes #9364

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-contain] Allow container query style features to evaluate in a boolean? #8127

[css-contain] Allow container query style features to evaluate in a boolean? #8127

mirisuzanne commented Nov 22, 2022

LeaVerou commented Jan 30, 2023 •

edited

Loading

una commented Jan 30, 2023 •

edited

Loading

LeaVerou commented Jan 30, 2023

mirisuzanne commented Jan 30, 2023

astearns commented Feb 2, 2023

LeaVerou commented Feb 3, 2023 •

edited

Loading

Loirooriol commented Feb 3, 2023

mirisuzanne commented Feb 3, 2023

una commented Feb 7, 2023

andruud commented Feb 7, 2023

lilles commented Feb 22, 2023

css-meeting-bot commented Mar 22, 2023

cdoublev commented Apr 21, 2023 •

edited

Loading

lilles commented Apr 21, 2023

cdoublev commented Apr 21, 2023 •

edited

Loading

Loirooriol commented Apr 21, 2023

cdoublev commented Apr 24, 2023 •

edited

Loading

lilles commented Apr 24, 2023

cdoublev commented Apr 26, 2023

lilles commented Apr 26, 2023

cdoublev commented Apr 26, 2023

lilles commented May 3, 2023

[css-contain] Allow container query style features to evaluate in a boolean? #8127

[css-contain] Allow container query style features to evaluate in a boolean? #8127

Comments

mirisuzanne commented Nov 22, 2022

LeaVerou commented Jan 30, 2023 • edited Loading

una commented Jan 30, 2023 • edited Loading

LeaVerou commented Jan 30, 2023

mirisuzanne commented Jan 30, 2023

astearns commented Feb 2, 2023

LeaVerou commented Feb 3, 2023 • edited Loading

Loirooriol commented Feb 3, 2023

mirisuzanne commented Feb 3, 2023

una commented Feb 7, 2023

andruud commented Feb 7, 2023

lilles commented Feb 22, 2023

css-meeting-bot commented Mar 22, 2023

cdoublev commented Apr 21, 2023 • edited Loading

lilles commented Apr 21, 2023

cdoublev commented Apr 21, 2023 • edited Loading

Loirooriol commented Apr 21, 2023

cdoublev commented Apr 24, 2023 • edited Loading

lilles commented Apr 24, 2023

cdoublev commented Apr 26, 2023

lilles commented Apr 26, 2023

cdoublev commented Apr 26, 2023

lilles commented May 3, 2023

LeaVerou commented Jan 30, 2023 •

edited

Loading

una commented Jan 30, 2023 •

edited

Loading

LeaVerou commented Feb 3, 2023 •

edited

Loading

cdoublev commented Apr 21, 2023 •

edited

Loading

cdoublev commented Apr 21, 2023 •

edited

Loading

cdoublev commented Apr 24, 2023 •

edited

Loading