[css-box-4] Applying margin-trim to inlines #6922
Comments
|
If |
I think that trimming inline-level contents in the block axis can make sense if they are inline-blocks. |
|
Hi, I tried to use margin-trim, but it seems it only trim margins of block children. This caught me a bit by surprise and reduce a lot the use cases of this feature. For instance here we have a label set in inline-block with a margin-block-start, I would have assumed margin-trim to cut the margin... but it's not happening unless the label is block (but this cause other issues as it would expand to the whole container): 
What is the rationale for not removing margin in this situation? |
|
@bakura10 Not sure exactly what you're trying to do, but maybe a combination of |
|
Proposed to close "effect on descendant inlines' as wontfix due to Oriol's observation that applying to inlines won't work as expected given descendant (potentially anonymous) blocks (since it won't inherit into those blocks). The use case is adequately handled by |
|
Since this was your proposal and an example does not need a working group resolution, I think you should feel empowered to close this issue without adding it to the agenda. |
|
@astearns Adding an example doesn't, but I do want to confirm that we're ok to spec
And also, upon review, there's still the original open question of, do we want this to have an effect when specified on inline boxes. |
|
@fantasai the display: block; width: fit-content would not work here. The idea is to be able to control the text positioning at the parent level, using a text-align: center. But I can understand this is causing too much complexities, so if this is works as per the spec then we can close it :) |
|
The CSS Working Group just discussed
The full IRC log of that discussion<jarhar> fantasai: the question was kind of what effect this should have on inline boxes and what effect should htis have on the inline axis of boxes<jarhar> fantasai: those are the two questions i wanted to ask to the working group. applying it to inline level boxes is complicated so we probably dont want to do that <jarhar> fantasai: if you set margin trim block inline then that would always affect the block i guess? <jarhar> fantasai: but im not sure why you would want to do that <una> q+ <miriam> ack una <jarhar> una: i can see why yodu possibly want to do this on an inline element, if it was creating more height than youd want then you could trim it, but im not sure about straight inline <jarhar> fantasai: oriol pointed out one of the complications of inlines is that we generate anonymous block classes, so if its margin trim doesnt inherit then if somethings the first - is on the top line then its not necessarily that its adjoining the top edge of the box so we would have to i guess drill through the block edges that dont have padding and <jarhar> margin and border just like margin col.apse <jarhar> fantasai: which we can do <jarhar> iank_: keep in mind that margin collapsing pieces through inlines block side of an inline of that inner block affects the position <astearns> s/pieces/pierces/ <jarhar> iank_: it makes me sad too <una> s/inline element/inline-block element <jarhar> dbaron: so my intuition about this is sort of that this proeprty makes sense in the direction in which a block lays out - in the direction in which a blocks children advance. but it doesnt make sas miuch sense in the other direction because of the other thing that you mentioned about inheritance because it becomes hard to follwo the principle that <jarhar> addaing an empty div aroudn sometjhing doesnt change it. it does apply to block but not grid etc <jarhar> dbaron: so i kind of feel like for block we probalby dont want this to apply on the inline sides <astearns> s/addaing an empty div aroudn sometjhing/dbaron: adding an empty div around something/ <jarhar> dbaron: mainly i think because of the idea that it does really weird things for thing sthat are diredcdt children of the blcok and we dont want that distinction to be exposed that heavily <jarhar> fantasai: yeah you have to have a recursive effect to make it do that <jarhar> fantasai: but then i can see it bein gusefulf or inlines if you have an inline block for example and its on the edge of the paragraph you might not want it to have a margin on that edge. but that could be something we do with a spearate property that applies to the inline rather than this property <miriam> s/bein gusefulf/being useful/ <jarhar> dbaron: and i guess one response to something una said earlier, maybe somebody said this already in the meantime but the property applies to block containers flex container grid containers which means it does apply to inline block because block container means that the dipslay type on the inside <jarhar> dbaron: so that means blcok and inline block <jarhar> dbaron: vs the other term for the thing on the outside <jarhar> fantasai: inline ??? <jarhar> fantasai: ok so current state is that we are going to spec margin trim on the block container and no affect on inline container, only affects its block level content, basically ignores the inline values of margin trim <jarhar> miriam: is that a propsoed resolution? <jarhar> fantasai: yeah <astearns> s/???/block versus atomic inline/ <jarhar> miriam: any objections to that resolution? <una> SGTM <dbaron> (block level) <fantasai> RESOLVED: margin-trim has no effect on the inline axis of a block container <fantasai> RESOLVED: margin-trim on a containing block does not affect inline-level content |
We've defined 'margin-trim' to accept a list of sides to trim, with options for all four sides. For block containers (which previously only trimmed the block-start and block-end sides) there are a few interesting open questions:
My proposed answer to this, btw, is that margin-trim applies to inlines in the inline axis, and to blocks in the block axis, and not to inlines in the block axis or to blocks in the inline axis. Reason being, these are the two things that seem useful.
Trimming blocks in the inline axis isn't very useful (they're always adjoining both sides, so just set your margins to zero) and trimming inlines in the block axis seems better served by leading-trim and other specialized text-sensitive things. Proposed definition means we can turn on the useful behaviors (inline-axis trimming of inlines, block-axis trimming of block) without simultaneously turning on unwanted behaviors (block-axis trimming of inlines, inline-axis trimming of blocks).
The text was updated successfully, but these errors were encountered: