[css-overflow-4] compat work-around for line-clamp · Issue #10324 · w3c/csswg-drafts (original) (raw)

line-clamp, both in its current incarnation that uses continue: discard, and in @andreubotella's exploration of the variant based on hiding visibility rather than fragmentaiton (so-called continue: collapse), is a thing that fundamentally applies to block containers, not to arbitrary types of boxes.

However, in both cases, we have to contend with existing content using -webkit-line-clamp, which invokes a -webkit-box flexbox as part of the magic soup of properties needed to activate the behavior.

Currently, they take different approaches, but both could work with either, so we should unify and pick one.

• The approach explored alongside the continue: discard variant is too keep the box which has display: -webkit-box; -webkit-box-orient: vertical as a special flexbox (as those properties call for), and to instead make the effects of line-clamp (and longhands) apply to the children of the box (including anonymous ones), at used value time.
• The approach explored alongside the continue: collapse variant is that if a box has display: -webkit-box; -webkit-box-orient: vertical, and line-clamp is used on it, then the box is made into a block container box (which is also an Independent Formatting Context, see [css-overflow-4] Line-clamp and IFC #10323), not a flexbox, and line-clamp directly applies.

I think the later approach, proposed by @andreubotella is simpler, and equally applicable to both approaches, so I suggest switching to that.

The main difference in behavior would be if the box that gets line-clamp is a -webkit-box with multiple direct children, the first approach would clamp each child independently, while @andreubotella clamps them as one set. Clamping them as one set is what current implementations of -webkit-line-clamp (in FF, Safari, and Chrome) do, so that's more compatible.

Moreover, If I understand @andreubotella correctly, turning the -webkit-box box into a block box rather than a flex box is what Chrome's existing implementation of -webkit-line-clamp does already, so that further strengthens the compat advantages of that approach.

So, @andreubotella 's approach is simpler and more compatible with legacy content.

I propose we adopt that regardless of which approach we take to get to line-clamp.

Another difference is that the approach explored alongside the continue: discard variant makes the work-around work only when accessed through the -webkit-line-clamp syntax, while, the approach explored alongside the continue: collapse variant makes it work both with line-clamp and -webkit-line-clamp.

That seems simpler too, and more forward compatible, so I propose we adopt this aspect as well regardless of which approach we take to get to line-clamp.