Re: [csswg-drafts] [css-inline-3] text-box-trim vs fragmentation (#5335)

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.

-- 
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5335#issuecomment-1866815778 using your GitHub account


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

Received on Thursday, 21 December 2023 19:20:27 UTC