Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-overflow-4] compat work-around for line-clamp #10324

Closed
frivoal opened this issue May 13, 2024 · 6 comments
Closed

[css-overflow-4] compat work-around for line-clamp #10324

frivoal opened this issue May 13, 2024 · 6 comments
Assignees

Comments

@frivoal
Copy link
Collaborator

frivoal commented May 13, 2024

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.

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-overflow-4] compat work-around for line-clamp, and agreed to the following:

  • RESOLVED: -webkit-line-clamp with display: -webkit-box or -webkit-vertical-box establishes a BFC as described in the issue. Open new issue on timing of blockification (computed vs used)
  • RESOLVED: The previous resolution also applies to unprefixed line-clamp
  • ACTION Ian to open the above issue
The full IRC log of that discussion <fantasai> florian: same contxt as 10323
<fantasai> florian: We need to make some legacy compat workarounds due to -webkit-line-clamp
<fantasai> florian: it can't quite be exactly the same because -webkit-line-clamp doesn't apply to any block
<fantasai> florian: need to first use -webkit-box and something else
<andreubotella> -webkit-box-orient: vertical
<fantasai> florian: if you don't have these, the prefixed version is supposed to do nothing
<fantasai> florian: changing that is a compat problem
<fantasai> florian: the "how do we preserve that weirdness" question is answered differently in each
<fantasai> florian: the collapsed version assumes a single anonymous flex child and moves effect of line-clamping from flexbox to its child
<fantasai> florian: if it actually has multiple children, it applies to all
<fantasai> florian: Andreu's approach is better
<fantasai> florian: if applying both line-clamp and -webkit-box it becomes a BFC instead of a flexbox
<iank_> q+
<fantasai> florian: which is good for eventually getting rid of -webkit-box
<fantasai> florian: so I propose replacing the spec with Andreu's approach
<fantasai> andreubotella: this is what Blink was already doing
<fantasai> andreubotella: and I think it is also close to what FF is doing
<astearns> ack iank_
<fantasai> iank_: we switched our behavior 3-4 years ago
<fantasai> iank_: previously each of the items would get clamped individually, which is not at all what people want
<fantasai> iank_: so when we switched, we created a BFC and everyone was happy
<emilio> q+
<astearns> ack emilio
<fantasai> emilio: Fwiw, Firefox does the same
<fantasai> emilio: we also switched awhile ago
<fantasai> emilio: because people started relying on Blink's behavior, and it's better anyhow
<emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=1786147 fwiw
<emilio> q+
<fantasai> PROPOSED: -webkit-line-clamp with display: -webkit-box or -webkit-vertical-box establishes a BFC as described in the issue
<fantasai> andreubotella: I want to confirm WebKit is OK with this
<fantasai> andreubotella: since it has some observable effects
<emeyer> fantasai: I'm pretty sure we'd like to get rid of all the weirdness
<fantasai> fantasai: and if FF and Blink are shipping, then we can have some confidence that it's compatible to implement
<fantasai> astearns: proposed to accept the proposal in the issue
<fantasai> emilio: When does this happen?
<fantasai> emilio: difference between FF and Blink
<fantasai> emilio: Blink will [missed]
<fantasai> emilio: and Firefox will [missed other]
<fantasai> florian: Whichever is easier?
<fantasai> emilio: I think it's easier at computed-value time
<fantasai> +1
<fantasai> emilio: difference is whether observable by getComputedStyle()
<florian> s/Firefox will [missed other]/Firefox will do it at computed value time
<fantasai> emilio: same way we blockify
<florian> s/Blink will [missed]/Blink will do it at used value time
<fantasai> fantasai: being consistent with blockification is better
<fantasai> iank_: I'd like to do a tiny bit of research into why we did it that way, so separate issue would be better
<fantasai> RESOLVED: -webkit-line-clamp with display: -webkit-box or -webkit-vertical-box establishes a BFC as described in the issue. Open new issue on timing of blockification (computed vs used)
<fantasai> florian: follow-up question
<emilio> https://searchfox.org/mozilla-central/rev/4582d908c17fbf7924f5699609fe4a12c28ddc4a/servo/components/style/style_adjuster.rs#154-183 is the code fwiw
<fantasai> florian: This blockficiation we just decided to do, do we only do it if you line-clamp through -webkit-line-clamp or only or for both?
<emeyer> fantasai: If someone set line-clamp on display: flex
<fantasai> iank_: no, only -webkit-box
<fantasai> iank_: I think that's fine
<emilio> +1
<fantasai> fantasai: ah ok
<iank_> `display: -webkit-box; -webkit-box-orient: vertical; line-clamp: 2`
<iank_> does above clamp or not
<fantasai> florian: ok, then let's have a supplementary resolution
<fantasai> RESOLVED: The previous resolution also applies to unprefixed line-clamp
<dbaron> ACTION Ian to open the above issue

@dbaron
Copy link
Member

dbaron commented Jun 12, 2024

Ian opened the above issue as #10435.

@andreubotella

This comment was marked as duplicate.

andreubotella added a commit to andreubotella/wpt that referenced this issue Jun 13, 2024
As was recently resolved in w3c/csswg-drafts#10323 and
w3c/csswg-drafts#10324, `(-webkit-)line-clamp` should always create an
independent formatting context whenever it applies. Furthermore, the
`display: -webkit-box` property will not cause the box to become a
flexbox, but it will be an independent block formatting context
instead (even for `line-clamp`, which doesn't require
`display: -webkit-box` to apply).

This patch adds some tests for it, and makes some other tests no
longer tentative.
@frivoal

This comment was marked as outdated.

@frivoal
Copy link
Collaborator Author

frivoal commented Jun 14, 2024

Done in 3e2b38d

@frivoal frivoal closed this as completed Jun 14, 2024
frivoal added a commit to web-platform-tests/wpt that referenced this issue Sep 2, 2024
As was recently resolved in w3c/csswg-drafts#10323 and
w3c/csswg-drafts#10324, `(-webkit-)line-clamp` should always create an
independent formatting context whenever it applies. Furthermore, the
`display: -webkit-box` property will not cause the box to become a
flexbox, but it will be an independent block formatting context
instead (even for `line-clamp`, which doesn't require
`display: -webkit-box` to apply).

This patch adds some tests for it, and makes some other tests no
longer tentative.

Co-authored-by: Florian Rivoal <[email protected]>
Mossop pushed a commit to Mossop/gecko-unified that referenced this issue Sep 3, 2024
…, a=testonly

Automatic update from web-platform-tests
Add BFC tests for `(-webkit-)line-clamp` (#46734)

As was recently resolved in w3c/csswg-drafts#10323 and
w3c/csswg-drafts#10324, `(-webkit-)line-clamp` should always create an
independent formatting context whenever it applies. Furthermore, the
`display: -webkit-box` property will not cause the box to become a
flexbox, but it will be an independent block formatting context
instead (even for `line-clamp`, which doesn't require
`display: -webkit-box` to apply).

This patch adds some tests for it, and makes some other tests no
longer tentative.

Co-authored-by: Florian Rivoal <[email protected]>
--

wpt-commits: 839f93860707392c70f55d99b895f7277b115622
wpt-pr: 46734
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this issue Sep 3, 2024
…, a=testonly

Automatic update from web-platform-tests
Add BFC tests for `(-webkit-)line-clamp` (#46734)

As was recently resolved in w3c/csswg-drafts#10323 and
w3c/csswg-drafts#10324, `(-webkit-)line-clamp` should always create an
independent formatting context whenever it applies. Furthermore, the
`display: -webkit-box` property will not cause the box to become a
flexbox, but it will be an independent block formatting context
instead (even for `line-clamp`, which doesn't require
`display: -webkit-box` to apply).

This patch adds some tests for it, and makes some other tests no
longer tentative.

Co-authored-by: Florian Rivoal <[email protected]>
--

wpt-commits: 839f93860707392c70f55d99b895f7277b115622
wpt-pr: 46734
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Sep 6, 2024
…, a=testonly

Automatic update from web-platform-tests
Add BFC tests for `(-webkit-)line-clamp` (#46734)

As was recently resolved in w3c/csswg-drafts#10323 and
w3c/csswg-drafts#10324, `(-webkit-)line-clamp` should always create an
independent formatting context whenever it applies. Furthermore, the
`display: -webkit-box` property will not cause the box to become a
flexbox, but it will be an independent block formatting context
instead (even for `line-clamp`, which doesn't require
`display: -webkit-box` to apply).

This patch adds some tests for it, and makes some other tests no
longer tentative.

Co-authored-by: Florian Rivoal <gitflorian.rivoal.net>
--

wpt-commits: 839f93860707392c70f55d99b895f7277b115622
wpt-pr: 46734

UltraBlame original commit: 4ae391e291d3e9aab8671a8e8b714a57830125e0
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Sep 6, 2024
…, a=testonly

Automatic update from web-platform-tests
Add BFC tests for `(-webkit-)line-clamp` (#46734)

As was recently resolved in w3c/csswg-drafts#10323 and
w3c/csswg-drafts#10324, `(-webkit-)line-clamp` should always create an
independent formatting context whenever it applies. Furthermore, the
`display: -webkit-box` property will not cause the box to become a
flexbox, but it will be an independent block formatting context
instead (even for `line-clamp`, which doesn't require
`display: -webkit-box` to apply).

This patch adds some tests for it, and makes some other tests no
longer tentative.

Co-authored-by: Florian Rivoal <gitflorian.rivoal.net>
--

wpt-commits: 839f93860707392c70f55d99b895f7277b115622
wpt-pr: 46734

UltraBlame original commit: 4ae391e291d3e9aab8671a8e8b714a57830125e0
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Sep 9, 2024
…, a=testonly

Automatic update from web-platform-tests
Add BFC tests for `(-webkit-)line-clamp` (#46734)

As was recently resolved in w3c/csswg-drafts#10323 and
w3c/csswg-drafts#10324, `(-webkit-)line-clamp` should always create an
independent formatting context whenever it applies. Furthermore, the
`display: -webkit-box` property will not cause the box to become a
flexbox, but it will be an independent block formatting context
instead (even for `line-clamp`, which doesn't require
`display: -webkit-box` to apply).

This patch adds some tests for it, and makes some other tests no
longer tentative.

Co-authored-by: Florian Rivoal <[email protected]>
--

wpt-commits: 839f93860707392c70f55d99b895f7277b115622
wpt-pr: 46734
@andreubotella
Copy link
Member

Tested in web-platform-tests/wpt#46734

@andreubotella andreubotella added Tested Memory aid - issue has WPT tests and removed Needs Testcase (WPT) labels Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Wednesday afternoon
Development

No branches or pull requests

4 participants