- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Sep 2021 16:38:32 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `margin-trim vs floats`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: margin-trim vs floats<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3256<br> <fantasai> miriam: Question is should floats be able to do margin-trim<br> <fantasai> miriam: It seemed to us that floats that are at the edge of the box that have a box that would impact the box should be considered the same as any other margin against the edge of the box<br> <fantasai> miriam: there might need to be special definitions to define precisely when floats are impacted<br> <fantasai> miriam: but don't need ability to control separately<br> <fantasai> florian: I think we need some amount of independence<br> <fantasai> florian: Antenna House Formatter has proprietary controls<br> <fantasai> florian: for e.g. controlling the margin between two floats differently from margin between float and edge of the page<br> <fantasai> florian: when being particular about layout of complex documents with floats<br> <fantasai> florian: (not floats as substitute for grid, but actual floats)<br> <fantasai> florian: then you do want that kind of control<br> <fantasai> florian: float to float margins and foat to text margins are often different<br> <fantasai> florian: Some amount of float margin trimming explicitly is needed<br> <fantasai> miriam: I was thinking if we think of the trim as coming from the box edge, we could maintain the exclusion box of the float with the margin so if it's pushing anything else that margin is still there, but it's trimmed as far as the box is concerned<br> <fantasai> miriam: that seems to make sense to me<br> <fantasai> miriam: and that wouldn't need manual control<br> <fantasai> iank_: Should this just apply to in-flow elements?<br> <fantasai> iank_: That seems to be the main use case here<br> <fantasai> iank_: ...<br> <fantasai> florian: What would apply then? If I do want to trim the margins of a float<br> <fantasai> florian: for the purpose of not pushing other floats apart, it would work, but if not, then we'd need another property<br> <fantasai> iank_: It's a bit hard for me to reason when we don't have particularly strong use cases one way or another<br> <fantasai> iank_: use case described seems to be for in-flow children<br> <fantasai> iank_: consider the out of flow position case, not intending to act on that<br> <fantasai> iank_: floats seem in-between to me<br> <florian> q-<br> <fantasai> miriam: If the section that the float is in is wrapping the float<br> <fantasai> miriam: e.g. is a block formatting context root<br> <fantasai> miriam: then I would expect the float the behave as in-flow wrt that box<br> <fantasai> miriam: the margins on the float would be pushing the size of the box which is exactly what we're trying to avoid here<br> <florian> fantasai: it makes sense to apply the trim to the float<br> <florian> fantasai: you want to have precise control over what is the visible edge<br> <florian> fantasai: if you consider a section with some text and a float…<br> <Rossen_> fantasai: I think that it makes sense to apply trim to floats. You want to have a solid control of the vis edge of the new box. Considersing a section with content and float that has margin, done so content doesn't clash. If on top however you want to trim it so that it doesn't get displaced compared to rest of content.<br> <Rossen_> florian: You need to trim all such margins. It makes sense to trim all of margins as well as inline.<br> <fantasai> iank_: for that specific case I don't think trimming the float is warranted<br> <Rossen_> q?<br> <Rossen_> ack fantasai<br> <fantasai> iank_: e.g. suppose you put 5px margin around the float, then want that to stay all around<br> <Rossen_> fantasai: not sure you want that margin necessary. Mostly vis content is what you want to align to. If you want to get the edge of flow and text to align so you can put a margin around you can. That way if float comes later in flow it has it but not at the top.<br> <Rossen_> fantasai: you can also skip using it. Use selectors for these first elements to remove margins etc.<br> <fantasai> jensimmons: I think it could be confusing if margin-trim works sometimes and not other times<br> <fantasai> jensimmons: "it counts if it's an image in a float, but not if ..." It's a lot to keep in your head<br> <emeyer> +1 to @jensimmons point<br> <fantasai> Rossen_: I'm closer to iank_'s opinion here... generally speaking, float layout is not inline layout<br> <fantasai> Rossen_: They take part during inline layout, however in all implementations floats are kept separately based on whether left or right float alignment<br> <fantasai> Rossen_: and float layout is wrt all floats themselves<br> <fantasai> Rossen_: We go to great extent in float algorithm in CSS2 to avoid and minimize the dependency an inline content and floats as much as possible<br> <fantasai> Rossen_: Position of float wrt content ...<br> <fantasai> Rossen_: seems odd<br> <fantasai> Rossen_: because even a float that comes in the beginning of the content, that more or less guarantees part of first line<br> <fantasai> Rossen_: That float can be left or right<br> <fantasai> Rossen_: and really left margin doesn't make sense for right float and vice versa<br> <fantasai> Rossen_: seems very specific to make that an automatic behavior by layout algorithm<br> <florian> q+<br> <iank_> e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645<br> <Rossen_> fantasai: This is about trimming margins on content of all other layouts - block, flex items, grid items. etc.<br> <fantasai> fantasai: Should also trim floats<br> <fantasai> fantasai: Also not sure why concerned about inline layout, this isn't inline layout<br> <fantasai> Rossen_: Floats are out of flow<br> <miriam> q+<br> <fantasai> fantasai: Yes, they're taking out of their original position, but they're in-flow in the sense that they affect the content around them, unlike abspos<br> <fantasai> Rossen_: Floats create geometry for laying out content around it<br> <fantasai> Rossen_: Their placement takes place ahead of inline content around them<br> <Rossen_> q?<br> <fantasai> florian: You talked about inline margins<br> <fantasai> florian: Discussion is about block-start margin of the float being trimmed<br> <Rossen_> ack florian<br> <fantasai> florian: If you want to put a 1em margin around your floats to avoid the text of your float crashing against the surrounding text<br> <fantasai> florian: it doesn't necessarily mean you want your float to be 1em from the start of the block<br> <fantasai> florian: there's nothing to crash into above it<br> <fantasai> florian: it does depend on the document, but there are cases here<br> <fantasai> florian: Elika gave explanations already, did you want scans of books or something?<br> <fantasai> miriam: I would follow up with with what Jen said<br> <fantasai> miriam: There are interesting discussions from impl point of view<br> <fantasai> miriam: But from author point of view, not making sense<br> <fantasai> miriam: If I have a box and I want to trim the margins at the edge of the box<br> <fantasai> miriam: I would expect it to trim all the margins at the edge of the box<br> <fantasai> miriam: I wouldn't expect some difference because one is floated or not or whatever<br> <fantasai> miriam: ...<br> <fantasai> miriam: Also margin-trim is only applied at the box edges. It doesn't affect how content is flowing together<br> <fantasai> miriam: It determines what happens when I have a box and a float inside it or a paragraph or a header inside of it<br> <fantasai> miriam: I trim the margins when they are at the box edge, and those are the only margins I'm trimming<br> <fantasai> florian: I support miriam's position. If you simplify the value space and exclude one of them, you can still have individual control by using selectors<br> <fantasai> iank_: Apply to out of flow elements?<br> <fantasai> miriam: I would expect to things that impact the size of the box<br> <fantasai> florian: wrt abspos, whatever<br> <fantasai> Rossen_: For purposes of computing scrollable area, they do affect layout as an inline margin would<br> <fantasai> Rossen_: behavior that we just described with abspos element that has large margin bottom, would still create a large scroller with visibly nothing below<br> <Rossen_> ack miriam<br> <fantasai> iank_: Other thing I wanted to ask...<br> <fantasai> iank_: Example where using margin-trim is desirable but also margin-trim is desirable<br> <fantasai> iank_: How would I get that back, if it does apply to floats?<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645<br> <fantasai> miriam: I think you would either use padding, or you would not use margin-trim in that case<br> <fantasai> miriam: if you want different impact on different elements, you would do it manually instead of using margin-trim<br> <fantasai> iank_: other question is, now that we have nesting, it's very easy to implement effectively margin-trim now<br> <fantasai> iank_: does the use case for margin-trim become less due to this?<br> <florian> fantasai: margin trim is going to effect all elements very simply, but with selectors you'd need to drill down to descendents<br> <florian> fantasai: margin collapsing makes that complicated<br> <florian> fantasai: that's why we don't do it on table cells with selectors, and why it'd be good here too<br> <fantasai> iank_: If I want margin on the float and not the in-flow, then what do I do?<br> <Rossen_> q?<br> <fantasai> fantasai: Then don't use margin-trim<br> <Rossen_> ack fantasai<br> <florian> fantasai: isn't that the same question as with multiple items at the top row of a grid? at that point you can't use margin trim<br> <fantasai> iank_: It is common to want margin on the float and not the rest of the content<br> <fantasai> fantasai: I think the reason you often see margin on floats and not in-flow content that's supposed to align is because in-flow content isn't visibly flush<br> <fantasai> fantasai: but we're working to make that possible, so you won't need to add margin to the float to make it look like it's visually aligned with the in-flow content<br> <Rossen_> q?<br> <fantasai> iank_: I don't think that's entirely true...<br> <fantasai> iank_: but maybe we should discuss in the issue<br> <fantasai> miriam: I don't entirely understand your example, Ian.<br> <fantasai> iank_: I would expect padding on the content<br> <fantasai> s/iank_/miriam/<br> <fantasai> Rossen_: I think this is a great discussion and I certainly want to see progress made here<br> <fantasai> Rossen_: the use cases that I just understood make sense<br> <iank_> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9646 RHS still seems better?<br> <fantasai> Rossen_: But I also think we need to do some more careful thinking<br> <iank_> s/RHS/LHS<br> <fantasai> Rossen_: Maybe talk through use cases and narrow down what's possible and what's not, and try to figure out expectations<br> <fantasai> Rossen_: so maybe take up again later<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3256#issuecomment-925097339 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 September 2021 16:38:35 UTC