- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jan 2025 17:18:59 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-inline-3] inline boxes and line-fit-edge vs text-box-trim/edge`, and agreed to the following: * `RESOLVED: text-box-trim does not change height contribution of inline` * `ACTION: fantasai to make testcase and report back on WebKit/Chrome implementation status` * `RESOLVED: if text-box-trim reduces the effective height of the inline box compared to line-fit-edge, that amount is propagated as a negative margin (the same way as a specified negative margin is propagated) to inline descendants` <details><summary>The full IRC log of that discussion</summary> <fantasai> https://github.com/w3c/csswg-drafts/issues/10834#issuecomment-2540644321<br> <kbabbitt> fantasai: problem statement is at (link in chat)<br> <kbabbitt> ... we have a transparency principle that an unstyled inline should have no effect on layout<br> <kbabbitt> ... if I have some text in an <em> and insert a <span> that should not affect formatting<br> <fantasai> <em>Some text</em> vs <em><span>Some text</span></em> must be identical<br> <kbabbitt> ... that means properties need to be inherited if they affect inline layout<br> <kbabbitt> ... q is what does text-box-trim do on inlines<br> <kbabbitt> ... backgrounds and bortders on inlins traditionally do not affect layout and that's fine<br> <kbabbitt> ... we also talked about text-box-trim impacting height of line on an inline<br> <joshtumath> s/bortders/borders/<br> <kbabbitt> ... my conclusion is I don't think we should do that<br> <kbabbitt> ... because if we set text-box-trim on an inline, e.g. on a span, that will affect the line height because the inner element now has a taller height<br> <kbabbitt> ... I think we have to specify that when we are in default line height mode, text-box-trim can change how backgrounds and borders are drawn<br> <kbabbitt> ... but it does not change the height contribution of the inline<br> <kbabbitt> ... which remains based on line-height property<br> <kbabbitt> astearns: dbaron commented on different effects on blocks and inlines<br> <kbabbitt> fantasai: we have a distinction, it's called line-fit-edge<br> <kbabbitt> ... that's a separate property which allows it to trim<br> <kbabbitt> ... Proposal Part A: text-box-trim does not change height contribution of inline<br> <dbaron> Part A sounds good to me<br> <kbabbitt> Proposed: text-box-trim does not change height contribution of inline<br> <kbabbitt> RESOLVED: text-box-trim does not change height contribution of inline<br> <kbabbitt> fantasai: next part: we have a line-fit-edge property; it changes to a new inline layout model<br> <kbabbitt> ... where instead of using line-height as height contribution, we use margin box edge<br> <kbabbitt> ... in addition, it also lets you control which edge you use, effectively setting default edge to be used<br> <kbabbitt> ... and that inherits<br> <kbabbitt> ... what we could do is have a negative margin<br> <kbabbitt> ... negative margin ran into this transparency issue<br> <kbabbitt> ... to solve it, we said negative margin is propagated to descendant of inline box<br> <kbabbitt> ... if we say text-box-trim is applied to this box and changes where borders and padding are drawn, then it should correspondingly affect height contribution<br> <kbabbitt> ... but since it doesn't inherit, we somehow need to propagaste<br> <kbabbitt> ... in the same way as a negative margin would be<br> <kbabbitt> ... Proposal is that, in this mode, the amount by which text-box-trim reduces margin box is propagated as a negative margin<br> <kbabbitt> astearns: is this propagation of negative margins a new thing?<br> <fantasai> PROPOSAL: if text-box-trim reduces the effective height of the inline box compared to line-fit-edge, that amount is propagated as a negative margin (the same way as a specified negative margin is propagated) to inline descendants<br> <kbabbitt> fantasai: the line-fit-edge negative margin is a new thing, yes<br> <kbabbitt> astearns: concerned this new thing may have side effects<br> <kbabbitt> dbaron: Right now we already have these rules for special proagation of negative margins when you have line-fit-edge in non-default value<br> <kbabbitt> ... proposal is that, when you use text-box-trim, in this case where line-fit-edge has non-default value, then negative margin gets propagated to descendants? in addition to other negative margin?<br> <kbabbitt> fantasai: yes<br> <kbabbitt> dbaron: I think this makes sense, but we need to think about the line-fit-edge model some more and test it some more<br> <kbabbitt> ... but this proposal does seem to make sense to me<br> <kbabbitt> fantasai: agree 100%<br> <kbabbitt> astearns: Restating: the effect of text-box-trim contributes to the negative margin that is assessed when line-fit-edge is non-default and propagates to descendants<br> <kbabbitt> fantasai: correct<br> <kbabbitt> astearns: Not sure I understand repercussions, need to take a deep look at this, but I'm fine with resolving on this<br> <kbabbitt> chrishtr: re: first resolution: is normal the default?<br> <kbabbitt> fantasai: yes<br> <kbabbitt> chrishtr: does that have an effect on chromium/webkit implementation of [missed]<br> <dbaron> s/[missed]/text-box-trim/<br> <kbabbitt> fantasai: I haven't tested that, not sure what implementations are doing<br> <kbabbitt> ... but it's only on inline boxes<br> <kbabbitt> chrishtr: could you take an action item to take on that?<br> <fantasai> ACTION: fantasai to make testcase and report back on WebKit/Chrome implementation status<br> <kbabbitt> chrishtr: bonus points for a WPT<br> <kbabbitt> Proposed: interaction between line-fit-edge and text-box-trim contributes to a negative margin that is propagated to inline descendants<br> <fantasai> RESOLVED: if text-box-trim reduces the effective height of the inline box compared to line-fit-edge, that amount is propagated as a negative margin (the same way as a specified negative margin is propagated) to inline descendants<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10834#issuecomment-2578210039 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 January 2025 17:19:00 UTC