[css-inline-3] text-box-trim vs fragmentation

[fantasai]

From #3240 (comment)

Fragmentation is an interesting case. It's quite reasonable to want the text-trim to take effect at fragmentation breaks in multicol. But for pages, we'd end up trimming any ink that leaks over. We'll either need to adjust css-page-3 to not trim [ink] overflow at fragmentation boundaries or add a page-padding property similar to scroll-padding or something. This is actually necessary for ruby to work properly in Japanese, and many other effects that require the top of the text to line up across fragmentainers but allows some lines to contain content that overflows that visual line.

[chrishtr]

I propose that we apply text-box-trim to multi-column fragmentation, but not to paged media for printing. The rationale is:

• We know of good use cases to trim leading for text in the presence of multi-column (e.g. two columns next to an image that both want vertical centering), but I don't know of any for printing.
• Implementing ink overflow into the padding area of paged media is not so easy to implement in Blink as compared to multi-column (and I assume in other browser engines as well).

The spec would say: if the contents of an element with text-box-trim are fragmented by it or a descendant, then the first or last line (as appropriate to the value specified for text-box-trim) of all such fragments are trimmed. Trimming is done after fragmentation. This behavior does not apply to paged media.

Note: in other words, text-box-trim on an element applies to each of the fragments below it individually, but only if text-box-trim is on a multi-column container or its ancestor.

Note: the second sentence is to avoid a circularity. In terms of implementation, this will require a mechanism to lay out "without trimming" and then adjust layout to take into account trimming, but I think that will be needed anyway in order to detect the "last line to trim" in cases where it isn't clear from markup.

[fantasai]

I can see why trimming at the top of a page might be something to avoid in cases where the browser doesn't know how to draw into the page margin/padding area, so it makes sense to allow it. But I doubt it's ideal, because it doesn't allow authors to control things lining up in such cases. We probably want to (eventually) get trimming to work equally on pages and columns.

Also, there's really two questions here:

1. Do we trim if the first line happens to land at the top of the page/column?
2. Do we trim the line box in the middle of a paragraph if it lands at the top of the page/column?

Either way, we probably need to enable ink overflow of line boxes to spill out of the page content area.

[chrishtr]

• Do we trim if the first line happens to land at the top of the page/column?

I suggest yes, for the column case.

• Do we trim the line box in the middle of a paragraph if it lands at the top of the page/column?

I suggest no.

[css-meeting-bot]

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

• RESOLUTION: ink-overflow spills out of the page content area into padding and margins, user agents that can't draw paint overflow may shift content down to avoid clipping
• RESOLVED: Should text-box-trim apply at fragmentation breaks, depend on the box-decoration-break property

The full IRC log of that discussion

github-bot #335
fantasai: One consideration is when requesting text-box:trim, if it lands at the top of the page, we have ink spilling out of the page. Currently gets clipped out. If specifying cap height and land at the top of the page, accent marks will get clipped.
fantasai: Do we want to specify that ink-overflow can spill onto the padding area and if so do we want to allow implementations to pull content. How to approach the problem of clipping?
fantasai: Trim at the bottom of the page or at the next page? We need some way to control it and make it happen, with a consistent top edge.
+1 to allowing ink to spill over, similar to box-shadow
q?
fantasai: Need a way to handle text-box-trim for the correct padding and border of content. Two issues: clipping and separate control for fragmentation breaks.
s/Need a way to handle text-box-trim for the correct padding and border of content./If using text-box-trim for correct spacing between content and border, don't necessarily want to trim at fragmentation breaks/
chris h: Bbecause it is more difficult to implement with more complexities, text-box-trim does not apply for printing
Rossen: Allows for additive behavior in the future. Need to specify it correctly.
s/Trim at the bottom/Other question is, if the paragraphs fragments in the middle, do we trim at the bottom/
-1 to not applying to print. Would there be a way to allow it in print except for at page breaks?
Florian: Need to define cleanly the boundary. In typography such as using css to make printed material or like printing. About fragmentation, should not say print, possibly relevant.
Florian: Needs to work for printing. We need to work on this and not call the compat trap.
fantasai: Shouldn't disable trim for printing, need to spec the ideal behavior to the extent that it can be printed. Might allow user agents that can't do that, shift it down the page to use the text glyphs.
ack fantasai
chris h: The two together sound fine.
PROPOSAL: ink-overflow spills out of the page content area into padding and margins, user agents that can't draw paint overflow may shift content down to avoid clipping.
s/paint overflow/ink overflow/
+1
rossen: objections?
RESOLUTION: ink-overflow spills out of the page content area into padding and margins, user agents that can't draw paint overflow may shift content down to avoid clipping
fantasai: A question around text-box-trim taking affect. Should be a separate property to control them indepdently.
Chris H: Specify in the property, not overflow between columns.
s/RESOLUTION/RESOLVED/
s/Specify in the property/just operates at the top of the first fragment and the bottom of the last fragment/
fantasai: I'd want it to follow box-decoration-break
PROPOSAL: Should text-box-trim apply at fragmentation breaks, depends on the box-decoration-break property
Rossen: Objections?
RESOLVED: Should text-box-trim apply at fragmentation breaks, depend on the box-decoration-break property
Thanks all!
fantasai: fragmentation case possibly need an independent control. Could be a separate feature.
Zakim, end meeting

[fantasai]

@jensimmons and I discussed the related (but now a bit different) question of what text-box-trim should do when it's applied to a multi-column container, and as we propose for margin-trim we think it should apply at the top/bottom of each column box. Agenda+ to discuss.

[css-meeting-bot]

The CSS Working Group just discussed [css-inline-3] text-box-trim vs fragmentation .

The full IRC log of that discussion

q+
fantasai: I was chatting with Jen Simmons about how text-box-trim interacts with fragmentation. We have a discussion about setting text-box-trim in a box in the flow that gets fragment, but not on the multicol element. There's a lot of column boxes inside it, should it apply to any of them?
Probably makes sense to apply to the first and last line box in each column
assuming there's no intervening padding or borders
+1
+1
frivoal: makes sense to me
astearns: I know of a use case where we'd want to trim all of the top and bottom (?) of a column except for the very first and last. But we can handle that with the :column element
frivoal: I'm aware of that for trimming margins, but this issue is about trimming the top and bottom of lines. Is that correct as well?
astearns: You might be right that it might apply only to margins. There might also be a usefulness for lines. But yes, it should apply only to the top and bottom if it applies to multicolumn
bfgeek: My concern is that if applied to the end, it might shorten the column box, which might change the fragmentation point
fantasai: When fragmenting, you'd have to be aware of whether the line box to add to a page is trimmed or not
ack astearns
bfgeek: It's more complex, because of interactions with collapsing margins at the end
I dont' know if this is implementable for end trimming
frivoal: In this issue we're talking about trimming leading in lines, does that also affect?
q+
astearns: We might need some make-forward-progress algorithm where you decide where the fragmentation break is, then apply the trimming, and not reconsider the break
fantasai: It's similar to when trying to see if something fits, you truncate the margins. If there are borders or padding, you already cannot trim. It's different between line boxes and at the end of the element, so when you evaluate whether you fit, you trim the line box
if additional content fits, then you move forwards
frivoal: it's clear it's desirable, but not clear how doable. Can we edit it later if it's too hard?
fantasai: I think that's reasonable. Because margins are invisible, it doesn't matter whether you consider the box trim or not. It's only when placing the content and checking wherther it fits before the end of the page is when you need to consider trimming
bfgeek: What is the behavior with empty elements that are after this?
If there's a subsequent empty element. That's not considered (?) if there's an empty element afterwards
That's complex because we don't want to arbitrarily look forwards to see if this is the last
fantasai: If the bottom edge of my box is 1em from the bottom of the page, but it has a bottom-margin of 2em
we truncate the margin to the extent necessary to make it fit
ack dholbert
dholbert: when fantasai was talking about how it works in practice, discounting the text-box-trim for the purposes of seeing if the element fits, should it also make the element draw a smaller border box if it happens to fit when this is taken into account?
should the border box extend to the bottom of the column?
s/border box/background/
fantasai: do you mean a block background or an inline background?
dholbert: if the line of text has a background, i'm thinking of a span that has a background
...
fantasai: as an author, you don't want to combine text-box-trim with a block background
in the long term, we might want to have a control for this, similar to margin-trim for margins, but this would be the default
s/margin-trim/margin-break/
astearns: should we specify the behavior as florian suggested, and reopen the issue if there are implementability concerns? or do we take it back to the issue for now?
fantasai: I think this is what people would want if they set text-box-trim on multicolumn. The alternative is it doesn't apply at all
frivoal: If it applies only to the first column, it's worse because you have unbalanced columns
astearns: any objections, dholbert and bfgeek?
bfgeek; there's some complexity because, the way it works we'd need to backtrack. For example, you place a line box, there's 10px of space remaining. You need to lay out the next line box, because it might only be 8px
But if it's 12px high, you need to backtrack and go to the previous line box, and then trim it, which is a bit scary
you don't know if it's the last line box until you lay out the next line
frivoal: Having it only apply to the first column and not the others will be ugly. In general, for the problem, if we only trim at the first column it's bad
same for printing and pagination, if you have a multi-page document, you want the top and bottom to match
bfgeek: At the minimum we'd want trim-top. I'll talk to Morten to see how feasible is trimming the bottom if we have to backtrack
fantasai: Once you've decided that the line box fits, you can forget about whether you trimmed it. It only matters if you drew a background, and if you do, you have the question of where it ends
You have to make sure the background doesn't go beyond the fragmentainer edge
bfgeek: It affects more things than that
astearns: We should table the discussion of how it should work for now. bfgeek, are you okay having the conversation with Morten before resolving?
bfgeek: yeah
frivoal: Can we resolve to do it on the start side and leave the end side open?
astearns: We'll discuss that next time
fwiw the "in what ways is the column-end-trimming observable [and how do we need to tidy up after ourselves after placing that line]"is the bit that I'm wondering about too

[css-meeting-bot]

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

• RESOLVED: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last

The full IRC log of that discussion

fantasai: this issue is the same, but now for text-box-trim
fantasai: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last
q?
PROPOSED RESOLUTION: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last
RESOLVED: if you apply text-box-trim to a multicol container, it applies to the first formatted line of each column, and analogous for the last