[css-box-4] Use cases for margin-trim on floats · Issue #8547 · w3c/csswg-drafts (original) (raw)

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