Intent to Remove: -webkit-box quirks from -webkit-line-clamp

[Ian Kilpatrick]

(this is more like an Intent to Change, I used the Remove template, so apologies for copy pasting some other fields, let me know if I missed something).

Contact emails ikilp...@chromiuim.org,s...@chromium.org Explainer N/A Design docs/spec Specification: https://drafts.csswg.org/css-overflow-3/#line-clamp N/A TAG review N/A (I believe, as change to existing feature, but more than happy to file one if needed). Summary -webkit-line-clamp is a highly used feature which all modern browsers support. Is is used for truncating multiline text, e.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=7810 Unfortunately this feature, when developed, was built on "display: -webkit-box" feature which preceded "display: flex". Practically speaking there are two separate uses for "display: -webkit-box": 1) Multi-line clamping. 2) Flex fallback. This intent discusses removing the flex features from -webkit-line-clamp.

Motivation

This changes this feature to match what web-developers actually expect.

Internally this is implemented a LayoutDeprecatedFlexibleBox. In M80 we transparently mapped the "flex usecase" of -webkit-box over to LayoutFlexibleBox.
E.g. anything except for:
.line-clamp {
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
}
Is mapped over to flexbox implementation.
We left the "line-clamp usecase" in LayoutDeprecatedFlexibleBox. This has surprising behaviour for web developers.

1) Other -webkit-box properties are supported, e.g:
  -webkit-box-flex
 -webkit-box-ordinal-group
  -webkit-box-align
  -webkit-box-pack
  -webkit-box-direction

Most of these properties result in a broken layout when used with -webkit-line-clamp.

We would stop these properties from having any effect in the "line-clamp usecase". NOTE these would still work for the "flex fallback" usecase. All these properties are below 0.0001% for M81 Beta.

We would ship this removal first, as we believe that all these are extremely low (Google employees I can share internal UMA data) that these are all safe for removal.
I've checked sites where they are using these properties with the "line-clamp usecase" and most have no effect.

2) As the "line-clamp usecase" was handled by a "flex" container, line-clamp was applied separately to all children, e.g.
https://twitter.com/jaffathecake/status/1235869840226881536
https://jsbin.com/yerobes/edit?html,output
In the above case web-developers expect that the line-clamp applies to the formatting context:
https://twitter.com/bfgeek/status/1235982961331191813

We would change this to apply to the "formatting context", e.g. the behaviour that most web-developers expect.

We would ship this after disabling the other -webkit-box properties from effecting this feature.

Interoperability and Compatibility

https://drafts.csswg.org/css-overflow-3/#line-clamp

The spec above doesn't exactly describe the behaviour we would ship here, but an incremental step towards it. The main thing that this intent changes in our implementation is the fact this applies to block-boxes, and not the "webkit-box" box. I.e.
1) The -webkit-line-clamp (for the line-clamp case) establishes a block-box.
2) The other -webkit-box properties don't affect the "block-box".
3) The line-clamp is applied to the block formatting context as a whole, and not individually upon its children.

This intent doesn't ship the fragmentation part of what the spec describes. Shipping this incremental part now will allow an easier road to do this later.

We may find two things:
1) Not supporting the other -webkit-box properties for the "line-clamp usecase" isn't web compatible. We don't believe this is true given the UseCounter data.
2) Not applying the line-clamp to the formatting context as a whole isn't web compatible. We've inspected sites manually and don't believe this is an issue.

On the interop site, no other browser ships this behaviour yet.

Signals

Firefox: No public signals

  - I discussed this rough plan with an individual Firefox engineer.
Edge: No public signals
Safari: No public signals
Web Developers: Positive

  - From web developers I've talked to this is a broadly positive move, and removes a lot of the strange behaviour which web-developers encounter when using -webkit-line-clamp.
  Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests? Yes We'll change some of the existing wpt tests for this feature to not apply line-clamping to individual children, rather the formatting context as a whole: https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned&q=line-clamp Link to entry on the Chrome Platform Status https://www.chromestatus.com/feature/5680142707851264

[PhistucK]

All of this does not mention the standardized way of multiple-line ellipsis, the continue and max-lines properties that are not implemented in Chrome.

Is there a plan to support those or are we going to be stuck with the line-clamp legacy forever as the official and only way of multiple line ellipsis (which is tied with flexbox for some reason)?

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpTVXcFuUcMTwC%3DiL03WeXNDqccZNvkwOd%3DtGJDjWE%3DVBA%40mail.gmail.com.

[Ian Kilpatrick]

On Fri, Mar 6, 2020 at 4:16 PM PhistucK <phis...@gmail.com> wrote:

All of this does not mention the standardized way of multiple-line ellipsis, the continue and max-lines properties that are not implemented in Chrome.

Is there a plan to support those or are we going to be stuck with the line-clamp legacy forever as the official and only way of multiple line ellipsis (which is tied with flexbox for some reason)?

Correct.  We don't yet have the capability to perform line-clamping using fragmentation yet. We'd like to, but it is a ways out yet. This intent allows us (in the future) to move -webkit-line-clamp to a fragmentation based version (using a fragmentation based version would mean web developers wouldn't have to put overflow:hidden on the element for example).

[Florian Rivoal]

I support this. As you mentioned, this is only one step towards where we eventually want to be, but we have to start somewhere, and even if this doesn't match the spec yet, it gets us closer to be able to do so with further iterations.

—Florian

[Daniel Bratell]

LGTM1

The Chrome Status entry will form the basis for the beta blog post and I think it will be hard to understand for the intended audience since it talks about internal implementation with not so much about the expected effect for web developers.

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9979E368-BE6C-45D9-BE2F-054DDB0FE70F%40rivoal.net.

[Manuel Rego Casasnovas]

On 06/03/2020 19:57, Ian Kilpatrick wrote:
> On the interop site, no other browser ships this behaviour yet.

I'm not sure if I got it right (and I haven't tested it) but how is
"-webkit-line-clamp" working in the rest of browsers? Only when you use
"display: -webkit-box"?

If I understand correctly, now we want to make it work for any block.

> *Signals*

> Firefox: No public signals
>   - I discussed this rough plan with an individual Firefox engineer.
> Edge: No public signals
> Safari: No public signals

If you haven't done it yet filling bug reports for Firefox and Safari
would be welcomed.

> Is this feature fully tested by web-platform-tests

> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?Yes

> We'll change some of the existing wpt tests for this feature to not
> apply line-clamping to individual children, rather the formatting
> context as a whole:
> https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned&q=line-clamp

> <https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned=&q=line-clamp>

Mmmm, if we're not going to follow the spec yet, are we going to put
tests in WPT anyway? Would those tests be aligned with the spec text? Or
are you thinking in using "tentative" for them?

> Link to entry on the Chrome Platform
> Statushttps://www.chromestatus.com/feature/5680142707851264

I agree with Daniel Bratell that the chromestatus entry is complicated
to read/understand from an outsider point of view.

Could we maybe provide an explainer/design-doc with the plan regarding
this and the specific behavior that will be implemented now? That way it
could be linked as documentation (as it seems this won't follow the spec
completely yet, linking only to the spec might cause some
misunderstandings).

My 2 cents,
Rego

[Ian Kilpatrick]

On Mon, Mar 9, 2020 at 8:26 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 06/03/2020 19:57, Ian Kilpatrick wrote:
> On the interop site, no other browser ships this behaviour yet.

I'm not sure if I got it right (and I haven't tested it) but how is
"-webkit-line-clamp" working in the rest of browsers? Only when you use
"display: -webkit-box"?

Only when you use "display: -webkit-box; -webkit-box-orient: vertical;". No browser supports line-clamping with just "-webkit-line-clamp: 2;".

 

If I understand correctly, now we want to make it work for any block.

No we'll still require "display: -webkit-box; -webkit-box-orient: vertical;". We still need to investigate if it is web compatible work on any block box (e.g. "display: block;").

I think it'll be easier to only allow it without restrictions once we have the fragmentation base implementation available. But after we do these changes it'll be easier to determine if this would be web compatible, which we can investigate as a followup.

> *Signals*
> Firefox: No public signals
>   - I discussed this rough plan with an individual Firefox engineer.
> Edge: No public signals
> Safari: No public signals

If you haven't done it yet filling bug reports for Firefox and Safari
would be welcomed.

 

Will do! - Was planning on it after this intent. 

 

> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?Yes
> We'll change some of the existing wpt tests for this feature to not
> apply line-clamping to individual children, rather the formatting
> context as a whole:
> https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned&q=line-clamp
> <https://wpt.fyi/results/css/css-overflow?label=master&label=experimental&aligned=&q=line-clamp>

Mmmm, if we're not going to follow the spec yet, are we going to put
tests in WPT anyway? Would those tests be aligned with the spec text? Or
are you thinking in using "tentative" for them?

Firefox when implementing this feature bolted this onto their flexbox implementation for maximum web compatibility.

Most (all?) of these tests were contributed by Firefox when doing this web compatibility work - which I believe was the right thing to do.

Most of these tests would pass with a standards (fragmentation) based implementation of the spec. We plan on changing the few that violate the spec, e.g.

external/wpt/css/css-overflow/webkit-line-clamp-008.html

tests that line-clamping is applied to each child individually which violates the spec, we'll update this test so that a our implementation, and a standards based implementation would pass this test.

We aren't planning on changing ones like:

external/wpt/css/css-overflow/webkit-line-clamp-002.html

which test that "-webkit-box-orient: vertical;" must be set for "-webkit-line-clamp: 2" to work.

 

> Link to entry on the Chrome Platform
> Statushttps://www.chromestatus.com/feature/5680142707851264

I agree with Daniel Bratell that the chromestatus entry is complicated
to read/understand from an outsider point of view.

Could we maybe provide an explainer/design-doc with the plan regarding
this and the specific behavior that will be implemented now? That way it
could be linked as documentation (as it seems this won't follow the spec
completely yet, linking only to the spec might cause some
misunderstandings).

I wrote up:

https://gist.github.com/bfgeek/b1dc3cb741681523ae043045411eb526

which I'll replace most of the chromestatus entry with.

But I'll also work with our dev-rel, technical writers, to make the changes clear.

 

My 2 cents,
  Rego

[Manuel Rego Casasnovas]

Ok, makes sense.

> > Link to entry on the Chrome Platform
> > Statushttps://www.chromestatus.com/feature/5680142707851264

> <http://www.chromestatus.com/feature/5680142707851264>

>
> I agree with Daniel Bratell that the chromestatus entry is complicated
> to read/understand from an outsider point of view.
>
> Could we maybe provide an explainer/design-doc with the plan regarding
> this and the specific behavior that will be implemented now? That way it
> could be linked as documentation (as it seems this won't follow the spec
> completely yet, linking only to the spec might cause some
> misunderstandings).
>
>
> I wrote up:
> https://gist.github.com/bfgeek/b1dc3cb741681523ae043045411eb526
> which I'll replace most of the chromestatus entry with.
>
> But I'll also work with our dev-rel, technical writers, to make the
> changes clear.

This is great, much easier to follow. Thanks for doing it.

Bye,
Rego

[sligh...@chromium.org]

Hey all,

Generally supportive of this change, but have questions before I can vote:

• What are the current usage numbers?
• Can you perhaps link to the usecounters alluded to above?
• Have spot-checks been done on potentially affected content?
• If this goes badly, is there recourse (via Finch or otherwise) to roll it back?

Regards

[Ian Kilpatrick]

Hi Alex,

On Thu, Mar 12, 2020 at 12:34 PM <sligh...@chromium.org> wrote:

Hey all,

Generally supportive of this change, but have questions before I can vote:

• What are the current usage numbers?
• Can you perhaps link to the usecounters alluded to above?

So all these usecounters changed their meaning when we moved the "flexbox usecase" to the standards based flexbox implementation.

These look high, but they are dropping off quickly due to this shift (see Jan 2020 numbers, compared to Dec 2019 numbers).

 

https://www.chromestatus.com/metrics/feature/timeline/popularity/2130 (-webkit-box-flex for lineclamp usecase) 

https://www.chromestatus.com/metrics/feature/timeline/popularity/2132 (-webkit-box-ordinal-group)

https://www.chromestatus.com/metrics/feature/timeline/popularity/2126 (-webkit-box-align)

https://www.chromestatus.com/metrics/feature/timeline/popularity/2129 (-webkit-box-pack)

https://www.chromestatus.com/metrics/feature/timeline/popularity/2133 (-webkti-box-direction + -webkit-box-ordinal-group)

You can get the true numbers by querying UMA for these, and limiting by M81 Beta. (M80 had a small bug which overcounts unfortunately).

See: go/webkit-box-uma

• Have spot-checks been done on potentially affected content?

The content most at risk here is:

https://www.chromestatus.com/metrics/feature/timeline/popularity/2143 (0.8% of pageloads multiple children with line-clamping occuring).

(as opposed to https://www.chromestatus.com/metrics/feature/timeline/popularity/2141 ~18% of pageloads which shouldn't be affected).

When we spot checked 2143 last most of the additional children were ::before elements, etc which aren't affected. We plan on doing a more thorough check of ~100 sites on that list just to make sure.

We'll try and switch this on early in the M83 cycle so that we capture any web compat breakages early. 

• If this goes badly, is there recourse (via Finch or otherwise) to roll it back?

Yes - we've implemented the scary change (-webkit-box establishes a block-box) behind a blink flag (BlockFlowHandlesWebkitLineClamp) which we plan on enabling by default, then reverting if we find any issues. Historically this has worked well for rendering changes as it allows us to easily bisect any issues found to this change, then revert for a release if required.

[Mike West]

LGTM2, on the condition that the change is wired up to Finch so we can disable it without waiting for a code change + merge + respin. At the moment, our posture needs to be more risk averse than usual, and respins are hard.

-mike

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJL3UpQhuK57LgieevYk%3DHwFVbBqLWRKCzPehATLTqg%2B5NDz3g%40mail.gmail.com.

[sligh...@chromium.org]

LGTM3 w/ the same conditions.

Additionally, want to thank Ian for all the data and background info. Very helpful in judging the risk here.

Regards

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[一丝]

Is there any progress?

在 2020年3月7日星期六 UTC+8上午2:58:01，Ian Kilpatrick写道：

[Ian Kilpatrick]

Hi yiorsi,

I've enabled this feature for the M85 release (wired up to our Finch system).

(we delayed due to stability of releases).

Chrome Canary should have this behaviour.

The tests which will need to be updated due to the changed behaviour is:

external/wpt/css/css-overflow/webkit-line-clamp-008.html
external/wpt/css/css-overflow/webkit-line-clamp-029.html

Thanks,

Ian

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/05c03c9e-a74d-4634-b20b-fe71004c90dc%40chromium.org.