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

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.

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.

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:

Do we trim if the first line happens to land at the top of the page/column?
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.

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.

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

<Frances> github-bot #335
<Frances> 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.
<Frances> 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?
<Frances> 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.
<bradk> +1 to allowing ink to spill over, similar to box-shadow
<Rossen_> q?
<Frances> 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.
<fantasai> 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/
<Frances> chris h: Bbecause it is more difficult to implement with more complexities, text-box-trim does not apply for printing
<Frances> Rossen: Allows for additive behavior in the future. Need to specify it correctly.
<fantasai> s/Trim at the bottom/Other question is, if the paragraphs fragments in the middle, do we trim at the bottom/
<astearns> -1 to not applying to print. Would there be a way to allow it in print except for at page breaks?
<Frances> 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.
<Frances> Florian: Needs to work for printing. We need to work on this and not call the compat trap.
<Frances> 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.
<Rossen_> ack fantasai
<Frances> chris h: The two together sound fine.
<Frances> 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.
<fantasai> s/paint overflow/ink overflow/
<fantasai> +1
<Frances> rossen: objections?
<Frances> 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
<Frances> fantasai: A question around text-box-trim taking affect. Should be a separate property to control them indepdently.
<Frances> Chris H: Specify in the property, not overflow between columns.
<Rossen_> s/RESOLUTION/RESOLVED/
<dbaron> s/Specify in the property/just operates at the top of the first fragment and the bottom of the last fragment/
<dbaron> fantasai: I'd want it to follow box-decoration-break
<Frances> PROPOSAL: Should text-box-trim apply at fragmentation breaks, depends on the box-decoration-break property
<Frances> Rossen: Objections?
<Frances> RESOLVED: Should text-box-trim apply at fragmentation breaks, depend on the box-decoration-break property
<chrishtr> Thanks all!
<Frances> fantasai: fragmentation case possibly need an independent control. Could be a separate feature.
<Rossen_> Zakim, end meeting

[text-box-trim] Add tests for multi-col

Bug 1898670 [wpt PR 46470] - [text-box-trim] Add tests for multi-col,…

@jensimmons

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

[text-box-trim] Trim at the start/end of columns.

[text-box-trim] Internal test for printing.

Bug 1927054 [wpt PR 48817] - [text-box-trim] Trim at the start/end of…

[css-inline-3] Define how text-box-trim applies to multicol containers.

[css-inline-3] Define text-box-trim at fragmentation breaks. #5335

[css-inline-3] text-box applies to mutlicol containers, too #5335

Bug 1898670 [wpt PR 46470] - [text-box-trim] Add tests for multi-col,…

Bug 1927054 [wpt PR 48817] - [text-box-trim] Trim at the start/end of…

Navigation Menu

Repository navigation

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

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

chrishtr commented on Dec 21, 2023

fantasai commented on Jan 9, 2024

chrishtr commented on Jan 10, 2024

css-meeting-bot commented on Jan 24, 2024

fantasai commented on Aug 20, 2024

9 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions