-
Notifications
You must be signed in to change notification settings - Fork 673
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
Labels
Comments
The CSS Working Group just discussed
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 |
Ian opened the above issue as #10435. |
This comment was marked as duplicate.
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.
This comment was marked as outdated.
This comment was marked as outdated.
Done in 3e2b38d |
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
Tested in web-platform-tests/wpt#46734 |
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
Labels
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 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.
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: