Re: [csswg-drafts] [css-inline-3] text-box accumulation unexpected behavior (#11472)

The CSS Working Group just discussed `[css-inline-3] text-box accumulation unexpected behavior`, and agreed to the following:

* `RESOLVED: text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: probably helpful to look at the issue examples<br>
&lt;TabAtkins> fantasai: an author was playing with text-box-trim and was surprised when it cut into a button he'd styled<br>
&lt;TabAtkins> fantasai: reason is because, normally if you have padding/etc we dont' trim thru the padding/border. but the button was an inline block, so it sits on a line, and we ignore the contents of lineboxes when trimming. we just trim to the root inline box no matter what's on the line.<br>
&lt;TabAtkins> fantasai: it seems like this is something that people will trip over as well. there are workarounds, but there are reasons the author might have wanted to use inline-block specifically<br>
&lt;TabAtkins> fantasai: so options are we could make authors work around this<br>
&lt;TabAtkins> fantasai: or we could make a rule that says if you have an inline-block on a line, that pushes out the text edge to the margin edge of that block. (rather, any atomic inline, not just inline-blocks)<br>
&lt;TabAtkins> fantasai: so the rule for text trim would introspect into the linebox content, and if it finds an atomic inline it would push the edge out<br>
&lt;TabAtkins> fantasai: so wanted to check the wg's opinion<br>
&lt;TabAtkins> jensimmons: if we made the second change...<br>
&lt;TabAtkins> jensimmons: i could also see this author applying text-box-trim to the button itself to get the text vertically centered<br>
&lt;TabAtkins> jensimmons: will that get screwy?<br>
&lt;TabAtkins> fantasai: no, because it'll push to the amrgin edge fo the box *after* the box's position ahs been computed<br>
&lt;florian> q+<br>
&lt;TabAtkins> fantasai: if they were using text-box-trim on the button itself that'll change the button's sizing. then if it's on the paragraph too, we don't care about *how* the atomic inline figured out its margin box, we'll just use that<br>
&lt;astearns> ack dbaron<br>
&lt;iank_> are you sure you want margin-box and not border-box? e.g. margins on inline-blocks are typically used to pad the line-box.<br>
&lt;TabAtkins> dbaron: i think from a high level persepctive the result you want makes sense.<br>
&lt;fantasai> iank_, yes I'm sure<br>
&lt;TabAtkins> dbaron: tryign to remember how text-box-edge works, waiting for the spec to load<br>
&lt;fantasai> iank_, I think if the author asked for that extra space, we should give it to them<br>
&lt;astearns> ack florian<br>
&lt;TabAtkins> florian: maybe a silly question<br>
&lt;TabAtkins> florian: would it be an option to go with border edge rather than margin edge? or am i missing something?<br>
&lt;fantasai> iank_, ... although I suppose maybe it's similar to margin collapsing<br>
&lt;fantasai> iank_, hmmm<br>
&lt;kizu> q+<br>
&lt;TabAtkins> dbaron: i think we're reasonably consistent that waht matters for atomic inlines is their margin edge<br>
&lt;TabAtkins> iank_: i ahd the same question. margins are typically used to simulate the same metrics as the text around it. so if margins are used that way it makes sense to trim to the border box, i think<br>
&lt;TabAtkins> iank_: becuase if they're being used to simulate a descent, and you're trying to trim the descent<br>
&lt;astearns> ack kizu<br>
&lt;TabAtkins> kizu: if we want this behavior, we need a way for an element to opt out, if it *wants* to hang from the line you're trimming to<br>
&lt;TabAtkins> kizu: if we use margin box you could use negative margin to bring it back down (unless we do something magic there to not consider negative margin for text-trim)<br>
&lt;TabAtkins> astearns: similar question. first option was make the author fix it. if we change the default behavior, can they fix our choice?<br>
&lt;TabAtkins> fantasai: i think roman's point is correct. if we use the margin edge, author can use negative margin to shift that edge inward<br>
&lt;TabAtkins> fantasai: but if we use the border edge, author has no control<br>
&lt;TabAtkins> fantasai: so proposed reoslution is text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox<br>
&lt;TabAtkins> astearns: and that's sufficient to solve this author's issue?<br>
&lt;TabAtkins> fantasai: i believe so<br>
&lt;TabAtkins> astearns: objections?<br>
&lt;TabAtkins> RESOLVED: text-box-trim does not trim further into the linebox than the outermost margin edge of any atomic inlines in the linebox<br>
&lt;dbaron> (I presume this affects how text-box-trim affects block containers.)<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11472#issuecomment-2769426728 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 1 April 2025 13:48:46 UTC