Intent to Deprecate and Remove: -webkit-line-box-contain

[Walter Korman]

Primary eng (and PM) emails

wko...@chromium.org

Summary

Remove support for -webkit-line-box-contain from Blink.

Motivation

Adds complexity to Blink Layout code. Feature is not part of formal spec and will be subsumed by upcoming css-line-grid spec. Utilization is low. See add'l history in OWP bug linked below for more.

Compatibility Risk

Feature has been in Chrome since ~2011. It has likely never worked for vertical text. Utilization is low per https://www.chromestatus.com/metrics/css/popularity#webkit-line-box-contain

Latest plan is to incorporate similar functionality into the css-line-grid spec, which is not yet complete, draft at http://www.w3.org/TR/css-line-grid-1/

In other browsers, testing via http://jsfiddle.net/6u7Qa/1/:

- FireFox: not supported

- IE: not supported

- Safari: supported with -webkit prefix

Alternative implementation suggestion for web developers

No specific replacement currently. Depending on desired layout existing CSS features can be used to accomplish similar, see for example discussion around ::first-line for one use case in this thread:

https://lists.w3.org/Archives/Public/www-style/2011Mar/0446.html

Usage information from UseCounter

https://www.chromestatus.com/metrics/css/popularity#webkit-line-box-contain shows 0.0161% usage

OWP launch tracking bug

http://crbug.com/522215

Entry on the feature dashboard

This seems a small change given level of usage and absence from spec, so not planning to create a Chrome Status entry unless requested. It is mainly an internal code cleanup/maintenance motivated change.

Requesting approval to remove too?

Yes

[Levi Weintraub]

Usage is super low and it'll be nice from a code-cleanup standpoint. Non-api-owner LGTM.

[Dimitri Glazkov]

LGTM.

On Wed, Aug 19, 2015 at 3:35 PM, Walter Korman <wko...@chromium.org> wrote:

[Philip Rogers]

LGTM

[Christian Biesinger]

What does that property do?

Also I think it would be better to create a dashboard entry so that developers can easily see that this is happening.

-christian

[Walter Korman]

As I understand it, it is intended to allow the web developer to specify how the line height of a box should be determined, see:

http://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain

However note that the spec above is very dated, and the current implementation includes support for "glyphs" as a value, which while I've not found a spec around it, is mentioned by hyatt@ in some w3.org posts ex.: https://lists.w3.org/Archives/Public/www-style/2014Sep/0089.html

In particular it looks like it was aimed at allowing better support for styling opening paragraphs in for example books where the first letter or the whole first line may be a different font size from the rest of the paragraph. See the jsfiddle sample in my email above for an example.

Noted re: dashboard entry, created https://www.chromestatus.com/features/4521139636273152

[L. David Baron]

On Thursday 2015-08-20 00:02 +0000, 'Walter Korman' via blink-dev wrote:
> As I understand it, it is intended to allow the web developer to specify
> how the line height of a box should be determined, see:
>
> http://www.w3.org/TR/2001/WD-css3-box-20010726/#the-line-box-contain
>
> However note that the spec above is very dated, and the current
> implementation includes support for "glyphs" as a value, which while I've
> not found a spec around it, is mentioned by hyatt@ in some w3.org posts
> ex.: https://lists.w3.org/Archives/Public/www-style/2014Sep/0089.html
>
> In particular it looks like it was aimed at allowing better support for
> styling opening paragraphs in for example books where the first letter or
> the whole first line may be a different font size from the rest of the
> paragraph. See the jsfiddle sample in my email above for an example.
>
> Noted re: dashboard entry, created
> https://www.chromestatus.com/features/4521139636273152

It was in editors drafts of css3-linebox / css-inline for about a
decade (following WG agreement to add it), but those editors drafts
never got published as a working draft (mainly because I never found
the time to fix up other parts of the spec into what I thought was a
publishable state).

The new editors of https://drafts.csswg.org/css-inline/ took it out,
although I'm not sure that that removal was intended to be
permanent, or just temporary during refactoring of the spec. (I
seem to recall it was the latter, although I'm not sure.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Philip Jägenstedt]

LGTM3. If it ends up standardized and is useful, a new unprefixed
implementation would make sense.

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

[Rick Byers]

I was a little concerned by the usage graph (as high as 0.1% a year ago, and not strictly decreasing over time), so I did an httparchive search.  As of Aug 2014, 21 of the top 300k websites appear to have used this property, and of those most of the uses are in a file "cssparser.js" which appears to just have a database of all known CSS properties (no evidence it's actually used by the site).

So, although it's unnecessary, LGTM4