Open fantasai opened 5 years ago
I think there are use cases for having different float-to-float margins than float-to-inflow, and this probably covers quite a few of them. @murakamishinyu, I know you are quite familiar with this topic thanks you your work on antenna house. Can you share a bit more about the use cases for something like https://www.antennahouse.com/product/ahf60/docs/ahf-float.html#axf.float-float-margin-y, and whether having what @fantasai is proposing would solve that need as well?
agenda+ to resolve that floats and inflow content do not need distinct values. We can work out the details of how margin-trim impacts floats separately.
The CSS Working Group just discussed margin-trim vs floats
.
I understand that there are use-cases where an author might want to exclude some elements/margins from the impact of margin-trim
. I do not think it's true that those use-cases align cleanly with a distinction between flow-types (in-flow, float, or abspos). In all cases, I would expect the default of margin-trim to trim all box-edge margins. From there, it seems to me like the more important question is: do we need a way for some elements to override that container-imposed trimming.
On the call, @bfgeek linked this example:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9645
This "image-with-whitespace next to text" is a common pattern, although neither box in the demo reflects a clearly desirable outcome.
leading-trim
). That could be roughly achieved with margin-trim
on both axis, and padding
on the container.In both cases, this same basic pattern is now achieved with a variety layout methods -- float, flexbox, and grid -- depending on subtle details of sizing and alignment and content. From an author perspective, there is not a consistent relationship between which layout technique is used, and how the author would want box-edge margins handled.
In the case where one child element does need to keep margins intact, there are several options:
padding
rather than margin
margin
on individual elements, rather than using margin-trim
on the containermargin-trim
(something similar to the margin-break
property, which handles per-element margin-truncating rules in fragmentation contexts).That last option would make sense to me. But attempting to auto-opt-out an entire category of elements (based on their relationship to flow) feels like an unreliable heuristic, and doesn't match any consistent author patterns that I've seen.
There are a few more complexities here for this feature:
Determining the "end" of content is complicated for floats, and atomic-inlines (anything on a line) and makes this difficult to implement. E.g. consider: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9695
Floats can end up in quasi states where their margin might be trimmed, however they aren't at the "end" of the content. E.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9693 getting this case correct for block layout falls into the "very difficult" category, as you may have to walk arbitrarily back in the content.
Its also quite common for atomic-inlines to have margin to adjust their position on a line, e.g. <img style="margin-bottom: 1em";>
to position something as a sup of similar (this is also super common on first-letter pseudo).
This feature works well for inflow-content. Grid/flex have very simple models here and is relatively straight forward. Block-flow is a very complicated model due to how margin-collapsing, floats all interact. Block-flow layout is really 3 different layout modes combined into one.
Block-flow layout is the only thing here where we are going more than one level deep. The way that margins work for inflow-block-level content would make it very straight forward to implement for inflow block-level content. This is similar to how the prefixed -webkit-margin-collapse
class of properties worked. Atomic-inlines and in particular floats make this very difficult to reason about and implement.
But attempting to auto-opt-out an entire category of elements (based on their relationship to flow) feels like an unreliable heuristic, and doesn't match any consistent author patterns that I've seen.
We've already done this for the other category of out-of-flow elements?
Could this help remove a margin on the float? I have a figure with float: right; margin-left: 10px;
so that it has some space to the text on the left. But if the figure is too wide (or window too narrow) then only the figure is shown, and I would love that left margin is then trimmed.
Retargetting for Level 5; note that the effect on floats has been completely removed, and would need to be re-introduced: see https://github.com/w3c/csswg-drafts/issues/8547.
Currently the
margin-trim
property allows trimming only in-flow block-axis margins, or that plus float margins (in either axis) that touch the container’s content edges. Should it be possible to trim the float margins while not trimming the in-flow block-axis margins? Do we have any use cases for such?