-
Notifications
You must be signed in to change notification settings - Fork 756
Description
What should happen to the bottom decorations (margin, border, padding) of boxes interrupted by line-clamp? I'm specifically talking about descendants of the clamping container, not the clamping container itself.
This example applies line-clamp: 4 (using the legacy syntax) to the following content.
Safari's legacy implementation:
Firefox and Chrome's legacy implementations:
@andreubotella's experimental implementation based on the spec:
First, because legacy implementations differ, we are likely not constrained by compatibility. Then, Andreu's implementation, being based on clamp points rather than on overflow: hidden, is cleaner than the Firefox/Chrome implementation, which if you look closely have content bleeding over the retained padding/border.
But the more interesting difference is between @andreubotella's implementation and Safari. I'd argue that the Safari rendering (although achieved through a different underlying logic than the spec) is actually more desirable.
- Since the content is interrupted, having the bottom border/padding be interrupted too is a clear visual indication, in addition to the ellipse, that the content continues but is just hidden.
- We could leave this as a choice to authors, reusing the
box-decoration-breakproperty as the switch. Slice-by-default, opt-in to clone would be consistent with the design of that property. - If we do end-up pursuing
continue: discard(or evencontinue: fragment) some day, it would be good to limit the divergences.
Based on this, my proposal would be that box-decoration-break takes effect on boxes that are descendants of clamping contexts (in addition to its current effects), and that when the value is slice, which is the default, If a block container contains a clamp point, within itself or in any of its descendants, the used value of its block-end margin, border and padding are 0.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status



