css-meeting-bot
commented
5 months ago The CSS Working Group just discussed [css-inline-3] Negative margins on inline boxes, and agreed to the following:
RESOLVED: we have fantasai start speccing accumulating neg margins for inline boxes
The full IRC log of that discussion
<bramus> fantasai: we have been exploring have a more understandable and powerful inline layout model<bramus> … in the block axis where there is a lot of dissatisfaction right now
<bramus> … one of the things is to swith to using line-height to decided ??? to using its margin-top and bottom
<bramus> … adv is that its a familiar model
<bramus> … another one is that you have pretty good control
<bramus> … you can use margin-top 1em and some padding and … so idea is that you take inline box and add margin and the margin doesnt inherit
<bramus> … that margin set ensures that it fits inside, and if it leaks outside then they cause the line box to grow
<bramus> … problem with neg margins
<bramus> … those should reduce how much you are contributing to line box
<iank_> q+
<bramus> … but if contents dont have same neg margin, as soon as you ahve any content with a separate box, then you are no longer slightly shorter
<bramus> … because content is back at same height
<bramus> … i thikn we need to fix this
<bramus> … only thing I can think of is to propage the neg margins to inline descendants
<bramus> … if you go deeper into the tree you accumulate more neg margin
<bramus> … (drawing)
<bramus> … (drawing of box with text and button with margin vs big text inside with margin)
<florian> q+
<bramus> … (drawing with problem of nested span that is too big … the neg margin should accumulate to the pos margin of that span)
<bramus> iank_: you would keep that margin if font size changes?
<bramus> fantasai: content box height is based on ?? of the font. margins modify that box
<bramus> iank_: thats fine
<astearns> ack iank_
<bramus> iank_: orthogonal q: margin collapsing interacts with inline … have you considered that today?
<bramus> fantasai: only interaction of margin collapsing and inline is only wether ?? is ?? or not
<bramus> iank_: yes, but (missed)
<dbaron> s/(missed)/only a small set of things that make it non-empty style wise/
<bramus> fantasai: having inline boxes margins taken into account for line box height is opt in
<bramus> … reqs could be more or less what they are
<bramus> iank_: ok
<astearns> ack florian
<bramus> florian: so either we acc neg margins or we give up? i am thinking about 2nd
<bramus> … use case is about a whole bunch of whitespace in glyph
<bramus> … isnt there stuff where you can ? with text box edge
<dbaron> s/edge/edge or text-box-trim/
<astearns> ack dbaron
<bramus> fantasai: you can use that to trim to specific metrics of a glyph which is better than magic number but you want to add adjustments on top of that
<bramus> dbaron: is your proposal that you estabilish a size around each ?? that adds up to all its inline ancestors umntil that is not an ancestor?
<bramus> fantasai: only for neg margins
<bramus> dbaron: why only neg?
<bramus> fantasai: in general you dont want to accumulate the margins. they dont stack on oinline boxes, just like padding in content area
<bramus> … elements being siblings or parent-child doesnt change how they are laid out
<bramus> florian: but you dont want to th esubm but bigger of the two
<bramus> dbaron: still not clear why only for neg ones
<bramus> fantasai: because for pos ones you get the effect that for inline box with ?? and you put some margins on it, all of them will at least be that tall
<bramus> dbaron: depends on the effect you want.
<bramus> … you say that for neg margins you do want the effect but for pos you don’t
<bramus> fantasai: yes, when typesetting you have some things that are bigger and will leak into extra space. but when tighter a neg margin wont have any effect if you put span around contents
<bramus> dbaron: so this would lead to more consistent line spacing?
<dbaron> s/this/this difference/
<bramus> florian: this helps preserve that adding an unstyled span to descendant shouldnt change anything. you dont need to acc pos margins for this to be true but to need that for neg ones.
<bramus> dbaron: i guess i am ok with it now
<bramus> fantasai: dont love the asymmetry but cant come up with a better solution
<bramus> … open to suggestions
<bramus> astearns: so outcome is to start working on this?
<bramus> fantasai: yes, should I spec that out?
<bramus> iank_: you will also need to change the text for what is an empty line
<bramus> … that will change how margin collapsing works
<bramus> fantasai: if we dont accumulate that outer one will prevent collapsings
<bramus> dbaron: i thought emtpy line test was only for inline margins
<bramus> iank_: non-zero doesnt apply in the block direction
<bramus> fantasai: (missed)
<bramus> florian: +1 to you trying to spec this out
<bramus> fantasai: this was the best i could think of
<bramus> astearns: concerns?
<florian> s/to spec this out/to spec this out, I don't see any other approach unless we give up on negative margins working here at all
<bramus> astearns: proposed resolution: we have fantasai start speccing accumulating neg margins for inline boxes
<bramus> astearns: objections?
<bramus> RESOLVED: we have fantasai start speccing accumulating neg margins for inline boxes
Was just thinking about the question of margins on inline boxes, particularly negative margins, and there's a bit of a problem with how it's defined to work atm:
Consider an inline element with a negative margin:
If we introduce another element, this prevents the margin from acting as expected:
Generally we try to make sure adding unstyled inline elements has no effect on layout, so we need to do something to fix this, maybe propagating the negative margin to descendants somehow?