[css-containment] Reorganizaing the Containment specs about csswg-drafts

[frivoal]

Btw, https://lists.w3.org/Archives/Public/www-style/2023Nov/0004.html resolved that we should start a css-contain-4 spec for State Container Queries. This document has not been created yet, but if we go ahead with what I proposed above, that would become Level n+1 of wherever we move Container Queries to.

[mirisuzanne]

I think it's strange that we are alternating levels for fairly distinct features - so yes, I agree it would be helpful to split CQs into a different module.

[tabatkins]

I don't have a strong opinion either way here. Splitting out CQs into their own track sounds reasonable.

[css-meeting-bot]

The CSS Working Group just discussed [css-containment] Reorganizaing the Containment specs, and agreed to the following:

• RESOLVED: Move CQs from contain-3 to conditional-5
• RESOLVED: move contain-inline-size from contain-3 back to contain-2 to join its family

The full IRC log of that discussion

<TabAtkins> florian: In Contain 3, we have CQs
<TabAtkins> florian: This is actually a seaprate feature. It depends on 'contain', but not *about* containment.
<TabAtkins> florian: So for editorial/publication conveninece, it woudl b enice to have separate things in separate specs
<TabAtkins> florian: So proposal is to move CQs to either a standalone spec or to CSS Conditional.
<TabAtkins> florian: either makes sense to me
<TabAtkins> florian: And we have a similar sitaution in css-contain-2, which contains some extensions to containment but also holds content-visibility
<TabAtkins> florian: which similarlyl depends on containment but doesn't define containment
<TabAtkins> florian: the speed these features are edited/tested/etc is different, which makes it harder to publish
<TabAtkins> florian: so maybe move CQ to CSS Conditional, and content-visiblity out of css-contain to a new spec
<TabAtkins> q+
<bramus> scribe+
<bramus> TabAtkins: Moving CQ makes sense. large chunky feature with distinct timeline of advancement
<bramus> … we very often have specs that have slight might of ideas that advance at different rates
<bramus> … we dont atomize our specs that finely
<bramus> … unless its causing an issue with maintenance or publication, we should not pull out features that arent core to the spec concept
<florian> q+
<astearns> ack TabAtkins
<bramus> … we arleady got a lot of specs … if we were to apply taht remotely consistently we would quadruple (?) a lot of specs
<bramus> … I’m fine with CQ moving out though, its relatively separate
<astearns> ack florian
<TabAtkins> florian: for content-visibility, this isn't about theoretical purity, but a practical issue.
<TabAtkins> florian: that part of the spec changes faster and has been editted by multiple poeple
<TabAtkins> florian: every time i try to edit Contain 2 and get it ready for pub, I spend a lot more time figuring out the status of that than the status of the entire rest of the spec
<TabAtkins> florian: that's why it's not published in two years
<TabAtkins> florian: I agree it's thematically connected. Another issue that might work for me is moving it to level 3
<TabAtkins> florian: That doesn't stand in the way of republishing as much as it does now
<TabAtkins> q+
<TabAtkins> fantasai: waht's the status of contain-2?
<TabAtkins> florian: WD. getting close to CR
<TabAtkins> florian: I use <wpt> in my specs to link to all the tests. I don't udnerstand content-visibility nearly as well, and there are hundreds of tests about it.
<miriam> q+
<TabAtkins> florian: It keeps throwing warnings at me when I do the rest of the spec. not a blocker, but an editorial inconvenience.
<astearns> ack TabAtkins
<bramus> TabAtkins: in general im opposed to us maintaining levels at wd. if they have stability i want them to stay together
<bramus> … e.g. contain all existing at immature stability levels
<bramus> … wpt feature is causing issues in the spec
<fantasai> css-contian-1 is REC, so this is just between L2 and L3 afaict
<bramus> … you can drop all irrelevant ones
<bramus> … is the problem that we are adding more tests?
<bramus> florian: yes
<astearns> ack miriam
<bramus> TabAtkins: which is a good problem to have
<TabAtkins> miriam: I don't have strong feelings
<TabAtkins> miriam: when we first put CQs in the spec I think they were gonna be closer together in syntax, then we intentionally abstracted that relationship
<TabAtkins> miriam: so it makes some sense
<TabAtkins> miriam: i wonder if some of the issue is not just different features, but different editors as well, so we don't have a shared understanding
<astearns> ack fantasai
<TabAtkins> fantasai: Moving CQ to Conditional 5 makes sense to me, makes sense to have them with the other conditionals anyway
<TabAtkins> astearns: so proposed resolution si to move CQs to Conditional 5
<TabAtkins> RESOLVED: Move CQs from contain-3 to conditional-5
<bramus> TabAtkins: I had a minor objection moving content-visibility bc we have two WDs of both 2 and 3
<florian> PROPOSED: Move contain: inline-size from css-contain-3 to css-contain-2
<TabAtkins> astearns: I'm gonna move the rest of the discussion to the issue
<TabAtkins> fantasai: I think we can resolve onw hat florian just said tho
<TabAtkins> RESOLVED: move contain-inline-size from contain-3 back to contain-2 to join its family

[frivoal]

There is currently no css-contain-4 spec, but we do have it as a label for features deferred from level 3. Should I rename that label to css-conditional-6?