[css-box-4] Use cases for margin-trim on floats

[sammygill]

https://w3c.github.io/csswg-drafts/css-box-4/#margin-trim-block

Currently the spec defines trimming for both the block and inline margins on floats. What are some of the intended use cases that would encourage the use of this property? Could we get some potential examples that would highlight the different types of trimming on floats?

[litherum]

cc @fantasai (the editor of this spec)

We are bringing this up because implementation is difficult and we're not sure it's warranted. Depending on the use cases, we may propose changes to the property's interaction with floats.

[bfgeek]

I've done an analysis for Blink for this feature and agree that margin-trim on floats has significant implementation difficulty (additionally this isn't a "shared heritage" thing, this is with our new engine).

cc/ @tabatkins

I know previously there was talk of opting-in/out float margin trimming. A forwards compat option might be to (initially) keep margins on floats (only apply to "inflow" content), with a future option to allow trimming on floats.

Ian

[dholbert]

Based on my recollection from the last time I looked at float/margin interactions in Gecko, I agree this seems like it'd be non-trivial to implement. Lacking a use-case, I'm in favor of simplifying or nerfing the effects of this property on floated content.

[css-meeting-bot]

The CSS Working Group just discussed [css-box-4] Use cases for margin-trim on floats, and agreed to the following:

• RESOLUTION: margin-trim doesn't apply to floats (by default), and we'll explore the interaction in the future

The full IRC log of that discussion

<bramus> Sammy_Gill: this is an open ended discussion. whjile doing some prelim work on floats we found that there ar esome complexities
<bramus> … we want to come back to the wg and see if there has been high demand or if there are signifcatn benefits to authors
<bramus> fantasai: (draws on whiteboard)
<bramus> fantasai: i can see wanting to ???
<iank_> q+
<bramus> … i have a page with some text at the top and an image here
<bramus> … you generally want float and text to be flush
<florian> q+
<bramus> … if we trim all margins on the inline stuff but not the float you are gonna have a margin at the top that was not there
<bramus> … why the margin? maybe you have two floats. I can see having two different for floats vs other thing.
<bramus> … it is possible that if you float sth it is not furthest to the side
<bramus> … so you might not be able to select the float that is flush with the side
<bramus> … that is the use case
<astearns> ack iank_
<bramus> iank_: i think when yeah it is sort of a judgement call. some folks want it, some dont
<bramus> … the implementation complexity is significant
<fantasai> s/two different/separate controls/
<fantasai> s/other thing/in-flow content/
<bramus> … for example, if you trim then that float might get replaced somewhere else
<bramus> … another one is that you may have to restyle layout from the root like bfc to get the layout to be correct.
<bramus> … you might need to backtrack the whole entire way
<bramus> … very complex
<astearns> ack florian
<bramus> florian: for floats that are meant to be floats, looking at print is a good source of use cases
<astearns> antenna house
<bramus> … if you look at antenna house formatter (css to pdf tool) they do this slightly differently. instead of margin trimming they let you set multiple types of margin which you can set separately, but that might not remove complexities
<bramus> … where you try to do a book-ish layout, you might need it
<fantasai> s/types of margin/types of margin, e.g. float-to-float margin, float-to-text margin, float-to-container margin,/
<bramus> iank_: a simple formatter might get away with this, but here its more complex
<bramus> astearns: that said, existence of thse controls in print formatters is evidence that some ppl do want to have control over these things
<bramus> iank_: yeah. from what i have seen, some ppl do want to control this
<bramus> … but compared to the general feature it is less
<bramus> … the demand is not as large from what i have seen
<bramus> fantasai: one q: are complexities from both axis or just from inline?
<bramus> iank_: the block start margin is likely fine modulo the placement thing
<bramus> … that might be acceptable
<bramus> … inline dimension there is complexities like block end
<bramus> … complexities on all sides. least troublesome is block start. most is block end
<dbaron> (inline dimensions in the middle for how troublesome)
<bramus> fantasai: block end margin is a complicated? Does it only apply to bfc root?
<bramus> Sammy_Gill: the trimming for block end margin extends through entire bfc and not just the block
<bramus> fantasai: for the bem because the float does not cause the non bfc root to grow/shrink
<bramus> iank_: ?? clears
<dbaron> iank: ...except when you have clearance
<astearns> iank_: except when you have clearance
<bramus> fantasai: if we had margin trim on block end side apply only to bfc root would probabyl satisfy the use cases
<bramus> iank_: it still is complex. that float might before the content. if it has end margin ??? it might get replaced ??? so you might need to backtrack
<bramus> fantasai: but you dont remove bem?
<bramus> iank_: that still is ???
<bramus> fantasai: it probably should not
<bramus> … it should not cause the float to ???
<dbaron> s/???/be placed again/ (?)
<bramus> … the margin trim should not on the bottom not cause it to move. it should allow the bottom marign of the bfc to shift upwards until it is flush with
<bramus> … the bottomless border edge of the floats
<bramus> … i think what wont cause problems
<dbaron> s/bottomless/bottom-most/
<bramus> … I thin kuse cases for block layout in general is block axies margin. cant think of example for inline axis trimming except for floats
<bramus> iank_: there is still issues with blocks and margins
<bramus> astearns: it may be around float stacking wehre bottom edge of one float can affect ??
<bramus> iank_: yeah, also fun stuff about ??? that clear stuff
<astearns> s/??/a subsequent float
<bramus> … brs get complicated
<florian> q+
<bramus> … brs are magical
<astearns> ack florian
<bramus> florian: so my takeaway that there are usecases and it is hard
<bramus> … suggestion to take it back to github
<myles> q?
<bramus> fantasai: suggestion not apply margin trim by derafult to floats, try and find a syntax that would allow margin trim to apply to only floats or floats and all other content, and then work through some of the block axis issues at least
<bramus> myles: one side is about implementation discussion, then making this an authoer opt in does not help
<fantasai> fantasai: but then you can implement it in stages
<florian> q?
<florian> q+
<bramus> iank_: if we make default not apply to floats, then webkit can make ??? then we can add an extension to floats which we can decide upon later
<astearns> s/make ???/implement without affecting floats
<dbaron> ScribeNick: dbaron
<florian> florian: opt-in to be defined later also allows for introducing partial solutions as opt ins, if we can find some that are reasonably easy to implement and do solve meaningful subsets of use cases
<myles> q+
<florian> q-
<astearns> ack fantasai
<astearns> ack florian
<astearns> ack myles
<dbaron> myles: Main concern is about implementation cost of final thing eventually in the future.
<dbaron> myles: staging it out over years doesn't satify that.
<dbaron> myles: If we end up with multiple different opt-ins, problem is worse in the end.
<dbaron> fantasai: It seems that an author might reasonably set it independentyl for inline flow and floats.
<dbaron> fantasai: otherwise I wouldn't want this
<dbaron> myles: I'm not making a judgment about one side of the issue or the other ,just trying to clarify about implementation complexity.
<dbaron> fantasai: I want to talk more with Ian to understand where the complextiy is coming from.
<dbaron> fantasai: I wonder if the complexity is actually intended.
<dbaron> fantasai: some of the complexity may not me desirable
<dbaron> iank_: Sammy_Gill may have more of it loaded in his head right now.
<dbaron> iank_: Discussion I had with Alan at WebKit a while ago.
<dbaron> astearns: not as much about margin-trim itself, but how it affects all of float positioning which is complicated
<dbaron> Sammy_Gill: example here is reasonable, but when you make it apply to all floats then it gets hairy
<astearns> and floats with shape-outside!
<dbaron> iank_: if we resolve not to apply to floats in the moment... web developers are great at telling us when they think something is broken, so we can get a sense of demand later on
<dbaron> myles: sounds like a great compromise
<dbaron> florian: in terms of usage, ... usableness of floats increases significantly with well functioning fragmentation and page layouts. So we don't see this much on the web. If we increase our fragmentation capability, we might also increase our need for fancy floats, which will remain complicated.
<dbaron> florian: original use case for floats not used all that often on the web, but used plenty on paged media
<dbaron> myles: comment about usage of floats or about margin-tripm
<dbaron> florian: floats in general... but once floats are used more, people will want more fancy floats features
<dbaron> hober: aren't floats used all the time, to a first approxmitaion?
<dbaron> fantasai: way they're used on the web and the way they're used in paged media are quite different
<dbaron> fantasai: many ways they're used on the web are correctly being replaced by grid and flexbox
<dbaron> fantasai: if we hade developers trying to do what floats were intended for on the web, demand for these features would increase
<dbaron> myles: I think we should tentatively resolve that they don't apply to floats, and then try to understand use cases and slice/dice issues.
<dbaron> astearns: proposed resolution: margin-trim doesn't apply to floats (by default), and we'll explore the interaction in the future
<dbaron> RESOLUTION: margin-trim doesn't apply to floats (by default), and we'll explore the interaction in the future