csswg-drafts
csswg-drafts copied to clipboard
[css-containment] Reorganizaing the Containment specs
It seems to me that Container Queries would be more suited to be a standalone spec. It has significant normative dependencies onto CSS-Contain, but isn't about defining containment itself.
I would suggest:
- moving Container Queries to a separate spec, either standalone (probably), or as part of one of the newer levels of
css-conditional - moving
inline-sizecontainment from level 3 to level 2 (this makes contain-3 empty)
While we're at it, I wonder if something similar should happen to content-visibility being pulled into its own spec. The same arguments seem to apply, although maybe not as strongly. Alternatively, content-visibility is what becomes level 3, and we let level 2 be only about containment in the strict sense (it would differ from level 1 by adding style and inline-size containment).
I think that would help with stabilizing the core part of containment faster, and would reflect the de-facto division of labor better.
Co-editors (@mirisuzanne @tabatkins @vmpstr ), what do you think?
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.
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.
I don't have a strong opinion either way here. Splitting out CQs into their own track sounds reasonable.
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-5RESOLVED: 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
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?
Should we republish css-contain-3 as a discontinued draft, now that it's empty?
Should we also update the working draft of css-conditional-5, so that this change doesn't result in container queries reverting from WD to ED?
@astearns I think we need two publishing resolutions here. It's a bit strange that in the meantime, Container Queries have been entirely removed from any public working draft.
Should we also update the working draft of css-conditional-5,
Yes, certainly. The previous TR publication was 21 December 2021 and we have a ton of changes since then. The changes list is not at all up to date. I will work on updating it, so that it is ready for publication.
Should we republish css-contain-3 as a discontinued draft, now that it's empty?
Yes, because the changes list is not empty, and those earlier changes are pointed to from css-contain-5.
Is there any downside to making it discontinued, if we want to later add stuff again? I don't recall that I published a discontinued document before.
The CSS Working Group just discussed [css-containment] Reorganizing the Containment specs, and agreed to the following:
RESOLVED: Publish new WD of Conditional 5
The full IRC log of that discussion
<TabAtkins> miriam: We resolved earlier to move CQ out of containment and into conditional<TabAtkins> miriam: That has meant, so far, that what has happened is CQ were removed from Contain and repubbed, but Conditional hasn't been repubbed yet.
<ChrisL> q+
<TabAtkins> miriam: So CQ doesn't exist outside of ED right now, which seems wrong
<TabAtkins> miriam: Seems we should publish Conditional
<TabAtkins> miriam: I don't know what else has happened in Conditional 5, dunno if I'm the right person to comment on if we can do that right away
<astearns> ack ChrisL
<TabAtkins> ChrisL: I've gone thru the changes on Conditional, doc is ready to be published
<ChrisL> +1
<TabAtkins> astearns: proposed resolution to publish new WD of CSS Conditional 5
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Publish new WD of Conditional 5
<TabAtkins> astearns: there was some discussion about whether we do Conditional 3 as a retired draft
<TabAtkins> astearns: I think its current state (just a parking doc that says "go look at Conditional 5") is fine. We can worry about it later.
<ChrisL> q+
<TabAtkins> astearns: Any concerns with no action?
<astearns> ack ChrisL
<TabAtkins> ChrisL: Not a concern, but unsure about consequences if we retire and then want to repub with something in it. Should know, but I don't. I think "no action" is fine.
<TabAtkins> astearns: Yeah, expect a discontinued draft being recontinued hasn't happened before.
<TabAtkins> astearns: So let's leave Contain 3 as it is.
Closing this, as I think it's done and published. @frivoal am I missing anything?