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.

@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.

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:

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.

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: