[css-contain-3] .conditionText and name vs query

[fantasai]

.conditionText is a single string, but there are two parts to the container query: the container name, and the query against it. Both of these form the condition of the rule, but it might be useful to have them represented independently in the API.

Suggestion: .conditionText is the entirety of the preamble, add .containerName and .containerQuery to represent the container name and query independently in the CSSContainerRule interface and the ContainerQueryList interface.

[mirisuzanne]

Since we never got official resolution on the existing API (see #7033) I think we should be able to resolve on both at once, potentially?

[mirisuzanne]

I think it would be good to get a resolution on this, and merge @andruud's PR if we can.

@atanassov if there's any space in the agenda…

[SebastianZ]

For what it's worth, @emilio already implemented .containerName and .containerQuery for Gecko a few days ago.

Sebastian

[css-meeting-bot]

The CSS Working Group just discussed [css-contain-3] .conditionText and name vs query, and agreed to the following:

• RESOLVED: Add .containerName and .containerQuery

The full IRC log of that discussion

<fantasai> Subtopic: [css-contain-3] .conditionText and name vs query
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/7190
<fantasai> miriam: Currently we have .conditionText which is a single string
<fantasai> miriam: but includes 2 parts, a name for name of container and a query for the conditions to match against that container
<fantasai> miriam: so proposal is to keep .conditionText as the entire query
<fantasai> miriam: but add .containerName and .containerQuery so you can get the parts yourself
<fantasai> astearns: if we have the parts, why do we need the concatenated thing?
<fantasai> TabAtkins: to match the other conditional rules
<fantasai> heycam: it inherits from ConditionalRule, so need to say what that property returns
<fantasai> astearns: Anyone with opinions?
<TabAtkins> +1
<fantasai> +1 from fantasai
<fantasai> heycam: makes sense to me
<TabAtkins> (and emilio already implemented it, apparently)
<fantasai> heycam: just question, the one that returns the expression
<fantasai> heycam: that doesn't include the parentheses?
<fantasai> miriam: that would include potentially multiple expressions
<fantasai> heycam: was asking about outermost parens
<fantasai> miriam: they're not required
<fantasai> miriam: no need to include them there
<fantasai> heycam: ah, so parens are part of the expression, not extra syntax
<fantasai> miriam: right
<fantasai> astearns: objections?
<fantasai> miriam: @andruud already posted a PR, so we could resolve to merge the PR
<fantasai> astearns: Not seeing anything about parens
<fantasai> miriam: if they are included, not part of the .containerQuery?
<fantasai> astearns: need to know whether to expect the parens
<fantasai> miriam: could merge the PR and add that as well
<astearns> ack fantasai
<heycam> fantasai: the syntax is like for MQs
<heycam> fantasai: so there are potentially a redundant set of parens around the entire expression, but in lots of cases you'll have ( expr ) or ( expr )...
<heycam> fantasai: any parens there should appear there
<heycam> fantasai: if we want to simplify, we should do it all the way through
<fantasai> heycam: I guess I wasn't suggesting simplification
<fantasai> heycam: wasn't sure if outermost parens were part of @container rule syntax
<fantasai> heycam: but sounds like it's part of the expression
<fantasai> astearns: so it's just as specified, with whatever parens
<fantasai> miriam: yes
<fantasai> astearns: then we can resolve to accept this PR and add these attributes
<fantasai> RESOLVED: Add .containerName and .containerQuery

[lilles]

Edits were made in https://github.com/w3c/csswg-drafts/pull/7293

[lilles]

Basic tests for containerName and containerQuery in https://wpt.live/css/css-contain/container-queries/idlharness.html