[csswg-drafts] [css-overflow-4] compat work-around for line-clamp (#10324)

frivoal has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-overflow-4] compat work-around for line-clamp ==
`line-clamp`, both in its [current incarnation](https://drafts.csswg.org/css-overflow-4/#line-clamp) that uses [`continue: discard`](https://drafts.csswg.org/css-overflow-4/#valdef-continue-discard), and in @andreubotella's [exploration of the variant based on hiding visibility rather than fragmentaiton](https://github.com/w3c/csswg-drafts/issues/10322) (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 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 https://github.com/w3c/csswg-drafts/issues/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`.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10324 using your GitHub account


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

Received on Monday, 13 May 2024 11:01:19 UTC