[css-conditional-5] `CSSContainerRule.containerName`/`containerQuery` should return a list

[cdoublev]

(Follow-up on this comment.)

According to this resolution, the @container prelude grammar accepts a list of <container-condition>s:

@container <container-condition># { <block-contents> }

<container-condition> = [ <container-name> ]? <container-query>

But CSSContainerRule.containerQuery and CSSContainerRule.containerName still return a single container query/name.

Can you please tell me if there is any reason to withhold the appropriate changes on the CSSOM? Do you plan to rename the attributes? To remove them? To return a list of strings or a string of comma-separated values?

The current version of Chrome/FF (at least) only accept a single <container-condition>.

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional-5] `CSSContainerRule.containerName`/`containerQuery` should return a list, and agreed to the following:

• RESOLVED: Editors will figure out how to fix the OM to match the new behavior, and bring it back to the group for review

The full IRC log of that discussion

<TabAtkins> astearns: miriam, this was months ago, but you put this on the agenda last year
<TabAtkins> miriam: okay, let's review...
<TabAtkins> miriam: we resolved earlier that a @container prelude could accept a list of conditions, but we didn't update the CSSOM to return a list
<TabAtkins> miriam: so the proposal is that CSSOM should reflect that list back to us
<TabAtkins> astearns: it's mentioned that none of the impls do it yet
<TabAtkins> miriam: at least, last yes, yes
<emilio> s/yes, yes/year, yes
<TabAtkins> astearns: so proposed resolution is to update CSSOM to match the resolution?
<kbabbitt> seems reasonable to me
<TabAtkins> miriam: yes
<TabAtkins> emilio: is the proposal to return a readonly sequence?
<TabAtkins> TabAtkins: i was thinking about that too. either it's readonly, or it could be settable but the list you get from the getter is "dead", doesn't reflect back into the object if you mutate
<TabAtkins> astearns: i think guillaume's PR doens't mention the read/write nature of the list
<TabAtkins> emilio: some back compat too. for the single-condition case, it might need to still return a string
<TabAtkins> astearns: do you think it's reasoanble to resolve on returning the list and find out if we have compat problems?
<emilio> TabAtkins: if today we allow a comma-separated list, how is it reflected? Just comma-separated list?
<emilio> ... if so it might be worth keeping the property alone
<emilio> ... and just have a function to get the listified version
<TabAtkins> miriam: maybe more complicated, containerName wouldn't make sense if it was returning the whole prelude
<TabAtkins> miriam: maybe nobody is usign the feature yet?
<TabAtkins> TabAtkins: propose we just reoslve to fix, and let editors figure out what it should look like
<TabAtkins> astearns: and who shoudl edit it?
<TabAtkins> TabAtkins: miriam or emilio?
<TabAtkins> emilio: this sounds reasonable. note that Firefox doesn't support multiple conditions yet, so it's not an issue for us.
<TabAtkins> emilio: maybe other browsers dont' eitehr, presumably they'd have run into this containerName issue too
<TabAtkins> astearns: so proposed resolution is we'll accommodate our intent in the CSSOM spec, but leave details to the editors to figure out what is possible given the constraints
<TabAtkins> miriam: can we get a little further? do we just have one property that returns a list, or a string property plus a list accessor?
<TabAtkins> astearns: i'd prefer only one, but i don't know if it's possible
<TabAtkins> emilio: i agree if we coudln't return a list...
<TabAtkins> emilio: but also the name is optional. if you have multiple container conditions, what are the names...?
<TabAtkins> emilio: if you have three conditions, only the first and third have a name...
<TabAtkins> TabAtkins: this is why i suggested leaving the details to the editors, i think they'd be pretty obvious once you start working it out
<TabAtkins> emilio: yeah, we can try to sort it out and come back with a more fleshed out proposal
<TabAtkins> miriam: sure
<TabAtkins> astearns: so we're resolved to fix this, and bring the solution back to the group
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Editors will figure out how to fix the OM to match the new behavior, and bring it back to the group for review

[mirisuzanne]

It looks like we currently return an empty string for containerName when no name is defined. I imagine we would do the same thing in a returned list.

We also resolved to allow name-only queries, which means the containerQuery can also become empty – which needs to be updated as well. I expect that should also return an empty string when missing? And then would return an empty string in a list if there are multiple?

It's not clear to me if conditionText should remain a string of all conditions, or if it should also become a list of names/conditions?

/cc @emilio

[emilio]

Probably worth for conditionText to keep the whole thing for consistency with @media and so on.

And I guess that mean that you could reconstruct all the conditions by "zipping" the names and queries.

[mirisuzanne]

@emilio If that sounds good to you, I'd call it a design / proposal. At this point I still feel very unfamiliar with defining CSSOM, especially the grammars. I could open a PR with a prose description of the proposed behavior, but would need help with the details.