You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, in both cases, we have to content 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.
The text was updated successfully, but these errors were encountered:
line-clamp
, both in its current incarnation that usescontinue: discard
, and in @andreubotella's exploration of the variant based on hiding visibility rather than fragmentaiton (so-calledcontinue: collapse
), is a thing that fundamentally applies to block containers, not to arbitrary types of boxes.However, in both cases, we have to content 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.
continue: discard
variant is too keep the box which hasdisplay: -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.continue: collapse
variant is that if a box hasdisplay: -webkit-box; -webkit-box-orient: vertical
, andline-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, andline-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 thecontinue: collapse
variant makes it work both withline-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
.The text was updated successfully, but these errors were encountered: