[css-inline-3] text-box-trim accumulation

We allow ancestors to affect leading trimming on descendants, so that common cases like

<div class=warning style="borders and padding and leading-trim">
  <p>This is just a paragraph. Maybe this line is <p>, or not, it could be anything.
</div>

will work for authors. But we don't specify what happens if various ancestors have different values for leading-trim.

Maybe we should do something similar to break-before and switch to an auto/no/yes model where auto does whatever the ancestor says and otherwise the innermost value wins?

I was just looking into how to solve text-box-trim on the first/last blocks in a section or article, and having the possibility to set text-box-trim: auto would solve that use case, if I understand you correctly.

<section>
  <h2>A title</h2>
  <p>A paragraph</p>
  <p>Another paragraph</p>
</section>

section {
  text-box-trim: both;
  text-box-edge: auto;
}

h2, p {
  text-box-trim: auto;
}

Would auto result in a used value of start for the h2, and end for the last paragraph?

The CSS Working Group just discussed [css-inline-3] leading-trim accumulation.

The full IRC log of that discussion

<ntim> fantasai: leading-trim can drill through elements, if you set it on the div, it will affect the paragraph in the div
<ntim> fantasai: however, if the both the paragraph and div say leading-trim: trim with different metrics, then we might want to look at the closest metric
<ntim> fantasai: we might something similar to page-break: auto, where we can break or not break
<ntim> fantasai: we could add an auto value to text-box-trim
<fantasai> where auto means, do whatever your parent says
<astearns> q+
<miriam> ack dbaron
<ntim> dbaron: just to restate the question: the choice between the metric from the closest ancestor, or the metric that is determine the most amount of
<ntim> myles: this reminds me of text-decoration where we can never remove them
<miriam> ack astearns
<dbaron> s/is determine the most amount of/takes the largest amount off/
<ntim> astearns: the proposal sounds ok in theory, but I want to see the proposal fleshed out and try some examples myself before fulling signing off
<ntim> astearns: this kind of sounds like trim collapsing
<ntim> ...and you want to avoid it
<ntim> florian: aren't we narrowing down to collapsing from the closest ancestor?
<florian> s/down to collapsing/down to trimming/
<ntim> astearns: Is this discussion enough to come up with a concrete proposal to evaluate?
<hober> scribe: myles
<myles> florian: it seems to me that we have a clear feeling that the largest metric is not what we want. Between the other options, we didn't discuss clearly.
<myles> astearns: dbaron originally asked "do you have a preference"?
<astearns> s/"/so /
<myles> dbaron: I don't have a preference. I don't understand what the issue is. I think it's closely tied to the syntax which I don't have in my head rn
<astearns> s/"?/?/
<fantasai> The three options were: take the closest metric where metric is available, take metric from closest that asks for trimming, take metric with largets amount of trimming
<fantasai> And I guess another one would be "outermost" metric
<astearns> no to the third
<myles> myles: how do we make progress here?
<myles> fantasai: astearns can help with examples, but we'll write a draft and be more specific
<myles> astearns: that sounds good
<myles> fantasai: ok

@johannesodland

@johannesodland Yes. This is actually the currently-specced behavior, but there's no conflict resolution specified if both of them specify a text-box-trim value. :)

I propose that we go with "take metric from closest that asks for trimming" among the three listed from the meeting notes. I don't think we need any new keyword values.

More precise wording: a line is trimmed according to the text-box-trim property of its nearest ancestor that specifies text-box-trim. (Note: if the line is not the one affected--e.g. not the first or last line under that ancestor, depending on the value of text-box-trim--it is unaffected.)

Note: we don't need this spec language for text-box-edge, because it's inherited.

Note: This is different than inheritance, because it only applies to the first line of any descendant of the ancestor, not to all first lines of different paragraphs. The line referred to by text-box-trim is similar to ::first-line (example).

Taking the innermost metric probably is pretty easy to understand. I'm just worried we'll have a problem like we do with collapsed table borders, where the obvious thing was to have the innermost (“most specific“) win, but it actually works out to not do the right thing on most tables. :]

(The example is, btw: same-width solid borders applied to the table, row group, and cells, with the cells being gray and the table/row group being black. Similar to this. You end up with all-gray borders, which isn't want you want: it's actually the outer elements that you want to win here, because the borders that coincide with them are the “most special”.)

Taking the innermost metric probably is pretty easy to understand. I'm just worried we'll have a problem like we do with collapsed table borders, where the obvious thing was to have the innermost (“most specific“) win, but it actually works out to not do the right thing on most tables. :]

My suggestion is to resolve on this behavior in the spec because it's easy enough to understand, prototype it in a browser engine, and then ask developers to try it and gather their feedback. If they find problems we can reconsider the semantics.

I think that while tentatively implementing "the right thing" even if we're not sure if it's going to be web-compatible and reverting if it isn't can often be a good idea, shipping a thing which may not be the best approach and changing later it if people don't like it is a lot dicier, as we may be trapped by compat by then, even if we do conclude that the alternative behavior would have been better.

Now, if it's about implementing without shipping in order to let people experiment with prototypes, sure. But then I don't think it needs to be in the spec.

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

RESOLVED: Choosing the innermost for textbox:trim for most requested trim metric.

The full IRC log of that discussion

<Frances> fantasai: consider an example with a div where inside there is a p, both asking for text-box:trim. Shared by two elements nested inside each other, which trimming should we perform? Such as different metrics?
<Rossen_> q
<Rossen_> ack florian
<Frances> fantasai: Can choose outer most or inner most or most constrictive one. Inner most is most specific, the alternative would be outermost to match up with something outside.
<Frances> fantasai: Which one would be the most appropriate metric?
<Frances> florian: If a sense of which one is right we can choose it, or we can implement the use case driven one.
<Frances> rossen: if strong use cases come, would be much easier to select.
<dbaron> innermost seems reasonable, at least
<Frances> PROPOSAL: Choosing the innermost for textbox:trim for most requested trim metric.
<Frances> RESOLVED: Choosing the innermost for textbox:trim for most requested trim metric.

[text-box-trim] Test accumulations

I am not sure if I understood the discussion result correctly.

When nesting different elements with different line-heights, the height of the largest line-height is used for the entire group.

For me as developer it would be most intuitive if text-box-trim would behave in a similar way.

Here are two examples and in both examples the largest font-size should be used for the trim calculation:

<h1><span style="font-size:120%"> (trimmed to the span)

<h1><span style="font-size:80%"> (trimmed to the h1)

For the same font size couldn't we do just trim the minimum?

for example ex requires less trimming than text - so we trim only text
the idea behind that would be that the developer defines that it is save to trim to text for h1 so we don't trim more than that:

@jantimon

Thank you @jantimon for the great feedback. Let me explain my understanding of the resolution.

The #8829 resolved to split the line-box-affecting aspects of text-box-edge to a new property (name TBD, tentatively called text-line-edge). So, this issue is about multiple block ancestors having different text-box-edge properties, as in the examples of the first two comments of this issue. Here's another more artificial example to explain the resolution:

<div style="text-box-trim: both; text-box-edge: text">
  <div style="text-box-edge: leading">
    <div style="text-box-edge: cap text">FIRST</div>
    <div>MIDDLE</div>
    <div style="text-box-edge: text alphabetic">LAST</div>
  </div>
</div>

Since the resolution is "innermost", the top of the "FIRST" should be trimmed at the cap edge, and the bottom of the "LAST" should be trimmed at the alphabetic edge.

The split in #8829 made applying text-box-trim and text-box-edge to <span> in your examples to have no effects, so your examples will not be impacted by the resolution of this issue.

When we start discussing text-line-edge, I think your feedback is one of the most important points to discuss about.

@fantasai Please correct me if any.

@kojiishi

thanks @kojiishi for your quick response - so it is not inline but about block siblings / children?

in that case "innermost" makes perfect sense for many different scenarios e.g. optical vertical text centering:

Bug 1897393 [wpt PR 46340] - [text-box-trim] Test accumulations, a=te…

[css-inline-3] Use innermost trim when multiple apply #5426

Hi,

I'm not sure if this is related to this issue, but I'm facing a strange output and I'm not able to understand if this is expected or not (and if it is, this is extremely unintuitive): https://codepen.io/bakura10/pen/GgKMvqR

I'm applying the text-box on the parent, so the container now no longer wrap the content. I've tried to set the text-box on the button, but this does not seem to work.

Ideally, this is the end result I would like:

I can of course use trim-start instead of trim-both, but I don't control the content, so the last element might be something different than a button.

@bakura10

@bakura10 IIUC it's the expected behavior as per the current spec, works the same in Blink and WebKit. As you pointed out, you'll need to use trim-start.

But it's also true that the WG may have missed some use cases. I think filing a new issue is helpful to get attentions.

Bug 1897393 [wpt PR 46340] - [text-box-trim] Test accumulations, a=te…

Navigation Menu

Repository navigation

[css-inline-3] text-box-trim accumulation #5426

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-inline-3] text-box-trim accumulation #5426

Description

Activity

johannesodland commented on Aug 3, 2023

css-meeting-bot commented on Sep 15, 2023

fantasai commented on Sep 15, 2023

chrishtr commented on Dec 21, 2023

fantasai commented on Jan 9, 2024

chrishtr commented on Jan 10, 2024

frivoal commented on Jan 12, 2024

css-meeting-bot commented on Jan 24, 2024

5 remaining items

jantimon commented on May 21, 2024

kojiishi commented on May 21, 2024

jantimon commented on May 21, 2024

bakura10 commented on Dec 31, 2024

kojiishi commented on Jan 7, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions