- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Sep 2022 00:02:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-contain-1] contain:size shouldn't fragment as monolithic`, and agreed to the following: * `RESOLVED: Not make any changes to css-contain-1, possibly relax the monolithic requirement in later levels` <details><summary>The full IRC log of that discussion</summary> <fantasai> subtopic: [css-contain-1] contain:size shouldn't fragment as monolithic<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/5648<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/5648<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/5648<br> <heycam> florian: CSS Contain has several types of containment<br> <heycam> ... all these are establishing changes to how CSS normally behaves, to reason about inside/outside the element, breaking dependencies<br> <heycam> ... what's going on inside an element doesn't affect the outside<br> <heycam> ... we have size containment, the goal being when the inside changes, the size of the element doesn't<br> <heycam> ... and in particular within that, we want to deal with size changes in the case the element is fragmenting<br> <heycam> ... for that we have a double goal. 1. regardless fo how the element fragments, its total size shouldn't change. but nore than that, the size of the fragments shouldn't change either<br> <heycam> ... the spec says applying size containment causes the element to be monolithic<br> <heycam> ... fantasai opened an issue to say it doesn't need to be<br> <heycam> ... she correctly poitns out size containment causes the element to be fixed size<br> <heycam> ... so the total size of the element won't vary, regarldess of the breaking point<br> <heycam> ... but making it fixed size does not guarantee the fragment sizes won't change<br> <heycam> ... so I think we need something more than merely making the element fixed size<br> <heycam> ... I agree making the element monolithic is slightly overkill, in the sense that it will guarantee that not only the total size of the box and all fragmnets won't change, but it also means the content of the element will not be fragmented and will be sliced<br> <heycam> ... which isn't actually necessary in this case<br> <heycam> ... as long as we guarnatee fragment sizes to not change, we can still allow fragmentation<br> <heycam> ... fixed size fragments but content fragments is not a thing we have currently<br> <heycam> ... preference is to stick with the existing spec requirement that all size contained elements become monolithic, because it fulfills the requirement and is what is implemented<br> <heycam> ... in some later level possibly relax this to not be monolithic as long as you fulfil these specific constraints<br> <heycam> ... could do that without trouble, any implementation compliant today would be compliant in the future<br> <heycam> ... but this is the last open issue on css-contain-1<br> <heycam> ... not sure it's so interesting to change the spec to allow behavior nobody has at this point<br> <florian> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10671<br> <heycam> fantasai: that seems very weird to me<br> <heycam> ... don't think it's supposed to do that<br> <heycam> florian: it's interoperable<br> <heycam> fantasai: it should be drawing the box all the way to the bottom of the page, and not leaving a gap when it fragments<br> <heycam> florian: the total size does stay fixed, btu the size of the fragments doesn't<br> <heycam> fantasai: drawing the box sides all the way down to the end of the page or column, rather than ending at the fragmentation point, then the size of the fragments would not change based on the fragmentation position<br> <heycam> iank_: all of the fragmentation engines for most cases, when you fragment, you'll typically consume the remaining fragmentainer space<br> <heycam> fantasai: that's what I was epxecting to happen<br> <heycam> florian: Safari, Chrome, and Firefox all do this<br> <heycam> ... three line element fragment, just tall enough to contain the three lines, but the fragmentainer containing the element is 2.5 lines high. so the first fragment will be 2 lines, the third fragment will be 1 line. so there's a 0.5 line gap at the end of the first one<br> <heycam> ... whether that's the case or not depends on the content of the element<br> <heycam> ... maybe this is an interoperable spec violation, but I'm not convinced it's a spec violation<br> <astearns> The fragment heights stay the same in blink, but adjust in gecko<br> <heycam> fantasai: that's super weird. I wonder what's causing this to happen<br> <bradk> Wouldn’t box-decoration-break: clone cause the fragments to grow?<br> <heycam> fantasai: I could undersatnd if engines were like "oh for web compat reasons we can't conusme the extra space", but even when it's auto, it's not consuming down to the fragmentainer<br> <heycam> florian: because here we're not in a monolithic case, it doesn't want to have one full line of content [...]<br> <heycam> fantasai: the fact it's not working for auto is disturbing<br> <heycam> florian: that's the current behavior, and doesn't work for contain:size<br> <heycam> ... I propose sticking with monolithic for level 1, then maybe relaxing in a later level<br> <heycam> fantasai: rather defer the issue<br> <heycam> florian: would you object to the monolithic beahvior being allowed?<br> <heycam> fantasai: no, I think it's fine to allow that<br> <heycam> florian: all implementations behave this way, and you're agreeing it should be allowed. is it worth blocking the spec to make a change that's not testable and not invalidate any implementation?<br> <heycam> fantasai: I said I don't mind deferring<br> <heycam> RESOLVED: Not make any changes to css-contain-1, possibly relax the monolithic requirement in later levels<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5648#issuecomment-1240034875 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 September 2022 00:02:59 UTC