Re: Intent to implement: -webkit-line-clamp

2020-03-07 Thread 一丝
Chrome began standardizing the line-clamp property.

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/SVD5wSqVwKU/eY28UiNkAwAJ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Intent to implement: -webkit-line-clamp

2019-02-14 Thread Cameron McCormack
Summary:

-webkit-line-clamp is a feature implemented in WebKit, Blink, and Edge that 
allows authors to control the height of a block so that it contains at most the 
specified number of lines, and if there are excess lines, an ellipsis is 
inserted in the last non-excess line.

http://dropshado.ws/post/1015351370/webkit-line-clamp

Lack of support for -webkit-line-clamp is a common cause of Web compatibility 
problems in Gecko, particularly on mobile sites.  Unfortunately, this feature 
is an odd duck in the existing implementations, since:

1. It only has an effect in `display: -webkit-box` and `display: 
-webkit-inline-box` elements.
2. Any excess lines are still displayed, and overflow the box.  Authors must 
(and do) use `overflow: hidden` to hide them.
3. -webkit-line-clamp is implemented as an additional constraint on the 
intrinsic size of the element (like a max-block-size property), and so usually 
only has an effect if `-webkit-box-orient: vertical` is also specified.

The CSS Working Group is attempting to define a standards-based solution that 
is sufficiently compatible with existing content.  As currently written, I 
think the standard line-clamp property (if we also support it with the -webkit 
prefix) should be compatible with the content we know we are currently broken 
on, although there is some risk of breakage due to the property applying to 
more elements.  This solution would need a more complex solution than 
WebKit/Blink currently have, however.  (Rather than just adjusting an input to 
the intrinsic sizing of the element, it would require fragmenting the excess 
lines away and suppressing them, something we don't have the concept for 
internally at the moment.)  The current spec does capture the use case of just 
limiting the number of lines in an element more sensibly than the existing 
implementations, though.

My current plan is to implement something closer to the existing 
implementations since (a) it is simpler, and (b) there is less risk of 
compatibility problems introduced by -webkit-line-clamp applying to more 
elements than in WebKit/Blink.  I will then provide feedback on the spec to 
support this behavior, or if that's not possible, get something added to the 
Compat spec.  Implementing the full fragmentation based line-clamp solution can 
be a followup task at some point.

Note that there seems to be some desire in Blink to replace 
-webkit-line-clamp's behavior with something that lives in a spec 
(https://bugs.chromium.org/p/chromium/issues/detail?id=305376) but I am 
doubtful that support for it can be removed entirely.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=866102

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

Platform coverage: everywhere

Estimated or target release: Firefox 68

Preference behind which this will be implemented: 
layout.css.webkit-line-clamp.enabled

Is this feature enabled by default in sandboxed iframes? yes

DevTools bug: as this is being implemented only for compatibility I don't think 
it's appropriate to build a DevTools feature for it
Do other browser engines implement this? yes (WebKit, Blink, and Edge)

web-platform-tests: none exist (and I don't plan to write WPTs until I manage 
to get the spec changes made)

Is this feature restricted to secure contexts? no (other engines don't restrict 
it)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform