- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Jan 2025 17:52:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-rhythm-1] `block-step-size` should not establish an independent formatting context``, and agreed to the following: * `ACTION: fantasai to clarify that block-step doesn't impact computed sizes` * `RESOLVED Do establish BFC for block-step-size with details on when the extra space gets added to the bottom only to be determined in future conversations` * `RESOLVED: Do NOT establish BFC for block-step-size with details on when the extra space gets added to the bottom only to be determined in future conversations` <details><summary>The full IRC log of that discussion</summary> <bramus> jensimmons: block-step-size establishes a new BFC on the box tha tthe prop is applied to<br> <bramus> … authors are gonna apply block-step to article element and apply to every p inside, or every img in figure.<br> <bramus> … if we make all those have a BFC that is a lot<br> <bramus> … means blokc-step wont work on floated content<br> <bramus> … should not have establish an independent FC<br> <bramus> … there’s a few comments in the issue that shows photos tha<br> <bramus> … proposed resolution to no longer require an independent formatting context<br> <bramus> astearns: questions?<br> <bramus> … seems reasonable<br> <bramus> fantasai: complication here is about floats, not about sizing of floats but content that is impacted by a float<br> <bramus> … if you have a box that is impacted by floats and tries to avoid them. if it gets taller it might need to get narrower<br> <bramus> … gets complicated with shapes<br> <iank_> q<br> <iank_> q+<br> <bramus> … if we want to do this – which i think we do – we can try to determine how much of an impact there and limit the number of cycles<br> <bramus> … issue is that it moves the box down, e.g when using margin<br> <bramus> … creates a position vs size relationship<br> <bramus> … in case where it moves down and causes more complications, then we could say space goes to the ened<br> <bramus> … and in the future figure out cycle-breaking<br> <bramus> … would cover basic cases<br> <astearns> ack iank_<br> <dbaron> I think we have some similar sort of cycles already with BFC placement around floats, but I'm not sure if these are equivalent or worse.<br> <bramus> iank_: dont you already have this problem?<br> <bramus> … everything that avoids floats that is block level establishes new BFC of some varieyt<br> <bramus> … if you set block-step-size on some parent you already have the case where a new FW that avoids floats is adding to margins then it goes to next layout area<br> <bramus> fantasai: oh, i misremembered the issue, this is about wrapping<br> <bramus> … so you have a float and a box that has text in it that wraps to avoid the float<br> <bramus> … if that float has a complicated shape or ends before the end of the paragraph<br> <bramus> … when you say to have the p have a block-step-size of 1lh<br> <bramus> … and you want to add 1em to either side of the p<br> <bramus> … can cause all content to move down<br> <bramus> … which can cause calc of line boxes to ???<br> <bramus> … dont think we want to do that<br> <bramus> … or not all the time<br> <astearns> s/???/change and re-wrap<br> <bramus> … then that is what can cause the size to … if it rewraps end up with extra line which changes amount of space, which needs recalc of step size<br> <bramus> iank_: I see<br> <bramus> … seems problematic<br> <bramus> fantasai: proposal is to track to see if the impacted lines by how much<br> <bramus> … or if additiona lines become impact<br> <bramus> … if no change, then adjust space above and below<br> <bramus> … but if it does impact the space the only insert at the bottom<br> <bramus> … that way you get the rhtyhm that you requested<br> <bramus> … it goes all at th ebottom where it wont change the position of the lines<br> <bramus> iank_: doesnt that break the rhtyhgm?<br> <bramus> fantasai: not really. the function does not impact internal contents that might or not be on the rhtythm<br> <joshtumath> s/rhtyhgm/rhythm/<br> <bramus> … goal is that make sure that thing that is after the x, you resume the rhytm<br> <bramus> … to make sure the margin box is an ?? number of steps<br> <bramus> … we can say that “floats are impacting stuff and we dont want to end up with a cycle so we insert at the bottom“<br> <bramus> … in the future we can choose to try more layout options<br> <bramus> … so in cases where its safe to ?? then you get exactly what you wanted and if its not the case then we do bottom only<br> <bramus> iank_: i think thats fine as long … would prefer it to be if any of the content is affected by floats you always place at the end because we already have root layout scenarios that trigger things like clearance<br> <bramus> … or how does tha twork? might be problematic as well<br> <bramus> … how does this work with collapsing margins?<br> <bramus> fantasai: current spec says that you measure the box’s own specified margin to find its margin box and make that a ?? of the step size<br> <bramus> … means tha tin some cases that margin inside tha tis larger than outside margin will do the step sizing thing correctly<br> <bramus> … i specced it like that to keep it simple<br> <bramus> iank_: … might be problematic<br> <bramus> … doing content on border box moditifaction is fine, margin box inside of a block layout context gets problematic bc of interaction iwth collapsing margins and floats and float clearance which would break the feature<br> <bramus> astearns: so we need separate issue for that<br> <bramus> iank_: i'll file that<br> <bramus> … at the end of the day you wnat to shift the box’s posiition, not alter the margin<br> <bramus> fantasai: in terms of changing the margin we are not changing the computed value, only from a layout perspecttive<br> <bramus> iank_: so wouldnt be reflected in gCS<br> <bramus> … things like margin-trim do, though<br> <bramus> fantasai: does it?<br> <bramus> iank_: yep.<br> <bramus> … it’s complicated / nuanced<br> <bramus> astearns: lets set margin collapsing aside<br> <bramus> … talk about the desire to have a single behavior for block step size in the presence of floats<br> <bramus> … suggestion is to always place at the bottom<br> <bramus> … does that make sense?<br> <bramus> fantasai: as a first step yes<br> <bramus> … but later might want to do a layout check<br> <fantasai> ACTION: fantasai to clarify that block-step doesn't impact computed sizes<br> <bramus> iank_: could do that, its a little bit complex because …<br> <bramus> … can potentially do that if there’s no intruding floats<br> <bramus> … already have comlicated logic in block layout<br> <oriol> q+<br> <bramus> … interactions is really complex<br> <bramus> … if there are intruding floats and their geometry changes then we always add to bottom<br> <bramus> fantasai: changes or if it doesnt extend far enough<br> <bramus> iank_: dont want that logic<br> <bramus> … gets complicated with clearance<br> <bramus> jensimmons: issue 1901 is relevant here<br> <bramus> fantasai: two things we want to resolve here is that it does not establish new BFC and two if inserting space above would cause complications with floats then we insert the space below only<br> <bramus> … and then i would like for us to dig into the complications that might be too complicated<br> <bramus> … and ideally reduce the amount<br> <bramus> … can have the spec a little bit undefined there to allow implementers to give feedback<br> <astearns> ack oriol<br> <fantasai> sthe amount/the types of situations that hit this limitation/<br> <bramus> oriol: reminds me of align-content that non-normal establishes new BFC<br> <bramus> … do we want to be consistent with this?<br> <bramus> … about proposal: am concerned about leaving it open because complicatedness depends on the engine<br> <bramus> … would prefer to keep establishing BFC or something very straightforward as proposed.<br> <bramus> jensimmons: suggestion was not to keep it permanently vague, but to have progress on the spec<br> <astearns> ack fantasai<br> <bramus> fantasai: for the use cases where this prop is likely to be used overlaps a lot with floated content use cases<br> <bramus> … having the property have no effect on things that happen to be impacted by floated content<br> <bramus> … want to reduce the cases where that happens<br> <bramus> … important for this to work, so makes nsens to not establish BFC<br> <bramus> … issue with align-content is that author is explicit about what they want<br> <bramus> … (missed)<br> <bramus> … and dont want to change for align-content to flip BFC on or off depending on placement of content<br> <bramus> … cant make it conditional<br> <bramus> … for align-content needs BFC<br> <bramus> … for consistency<br> <bramus> … for this case here, seems fine to insert space the bottom when there is a complication<br> <bramus> oriol: concerned about leaving "a complication" vague<br> <bramus> … depends ont he engine<br> <bramus> fantasai: yes, will align on that later … lets figure it out in the in-between<br> <bramus> astearns: would you, oriol, be ok with resolving on that?<br> <bramus> oriol: not a fan of open ended things<br> <dbaron> The other factor is that this particular feature (step sizing) is designed in a way that it has to work reliably in order to be useful (having consistent rhythm).<br> <bramus> … i guess I can input/verify that ??? guess its fine to leave for later. not a fan though/<br> <fantasai> it's going to "work" consistency, it's just a question of do we insert the space above or below the item<br> <bramus> PROPOSED RESOLUTION not establish BFC with details on when the extra space gets added to the bottom only to be determined in future conversations<br> <bramus> astearns: are you ok with that ian?<br> <bramus> iank_: seems fine. hard constraint for me is no relayout.<br> <bramus> astearns: other comments/questions/objections?<br> <bramus> RESOLVED Do establish BFC for block-step-size with details on when the extra space gets added to the bottom only to be determined in future conversations<br> <bramus> RESOLVED: Do NOT establish BFC for block-step-size with details on when the extra space gets added to the bottom only to be determined in future conversations<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11325#issuecomment-2593588438 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 January 2025 17:52:51 UTC