[css-overflow] convert -webkit-line-clamp alias requirement into a spec issue

[heycam]

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

The spec currently requires that a -webkit-line-clamp alias for line-clamp be supported. It's not yet clear that a simple alias is a net win for Web compatibility, since Blink and WebKit's -webkit-line-clamp implementation requires display: -webkit-box; -webkit-box-orientation: vertical; for the line clamping behavior to kick in. We're concered that there may be content that sets -webkit-line-clamp on elements that aren't display: -webkit-box; -webkit-box-orientation: vertical; and end up truncating their content in browsers other than Blink and WebKit.

I suggest that this be turned into a spec issue until we determine what is the best approach for handling -webkit-line-clamp.

[frivoal]

Good point. I hope that a simple alias will work, but it is far form sure that it will, for the reasons you said. Marked this as an issue in the spec, linking back to this github issue.

[MatsPalmgren]

I briefly tested -webkit-line-clamp in Chrome and I'm rather confused about the results.
Here's an example. In Chrome 68, an ellipses is inserted after "4" in the first two boxes and there's no ellipses in the third box.
@frivoal is that the expected result according to the spec?

[heycam]

I think it depends what display: -webkit-box; really means.

Per spec, without it, I would expect all three sub-tests to render the same, with an ellipsis after the "3" and all subsequent lines fragmented away. This is because the max-lines applies to the parent div, and the child div's lines are in the same block formatting context as the parent's.

But if you interpret display: -webkit-box; as being like creating a flex item, then that does establish an independent formatting context. In that case I would expect the first two sub-tests to be the same as before (ellipsis after "3"), but the third sub-test would look like it does in Chrome now, i.e. no ellipsis and no lines fragmented away, since the container div only generates two line boxes in its block formatting context (the "1" and the "7").

[css-meeting-bot]

The CSS Working Group just discussed -webkit-line-clamp compatibility issues.

The full IRC log of that discussion

<xfq> Topic: -webkit-line-clamp compatibility issues
<xfq> github: https://github.com//issues/2847
<dbaron> heycam: Talked about webkit-line-clamp, wanted to give an update, last couple weeks looking at implmeenting, and looking at what the actual behaviour inside blink/webkit
<iank_> heycam: At high level, in the spec we talk about it as a fragmentation, once you reach Nth line, subsequent lines fragment, and lines disappear.
<iank_> heycam: In blink/WK the effect is only as incluencing its size. like a max-block-size constraint, element is reflowed, where is pos of last line? this affects intrinsic block-size
<iank_> heycam: As in blink/WK you'll end up with an element w/ this size, however the remaining lines will appear as overflow.
<iank_> these differences aren't insignificant, i've written patch for what blink/WK have done. Wanted to do this in a reasonable time.
<iank_> TabAtkins: The existing WLC impls are bad and horrible.
<iank_> heycam: Apart from the difference with fragmenting or not, elements on subsequent lines will actually show, however this probably isn't a webcompat constraint.
<fantasai> The differences are largely intentional https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5
<iank_> heycam: WLC only work on -webkit-box, orientation: vertical. Some risk that if we don't respect that it may appear on elements that wasn't expected to have that treated.
<fantasai> Main concern is really interaction with -webkit-box
<iank_> TabAtkins: iank_ did some looking.
<florian> q+
<iank_> iank_: I did some analysis by adding a bunch of usecounters in our webkit-box implementation to answer questions like how many w/ single block-flow child, vs. multiple.
<iank_> iank_: This allowed us to kill percentage WLC
<iank_> heycam: yaya
<iank_> heycam: One other difference between spec and impl, any indepented formatting context child gets skipped over, that means a BFC, overflow: scroll, display: flex etc, I think that makes sense, is nice simple model, however it is a difference.
<astearns> https://www.chromestatus.com/metrics/feature/timeline/popularity/2139
<iank_> heycam: Where this difference has more of an effect, as it only works on a "box-item" that establibishs a independent formatting context.
<iank_> heycam: If repsected that rule, we'd never be able to apply that line-clamp. Needs to be an exception around this.
<Rossen> q?
<iank_> fantasai: A couple of options, and excpetion for WLC stuff, e.g. inherit the line clamp behaviour into the flex-item, or automatically apply.
<iank_> heycam: I think that's a sensible thing to do.
<xfq> ack florian
<Rossen> ack florian
<iank_> florian: Most differences are intentional
<iank_> florian: We probably need to do at the syntax level, where you specifiy that you need -webkit-box, etc, to apply the prefixed version.
<iank_> florian: We should do these tweaks, need to confess to alt. motive, i think feature is good on its own, the way that we spec'd it is good. Its the first step helps us solves a bigger problem.
<fantasai> s/alt./ulterior/
<iank_> florian: This solution is a subset which we need to get to overflow: fragments.
<iank_> florian: I think this is a good things.
<fantasai> s/Its/But it's also/
<iank_> florian: Wouldn't want to clean the hacks so much that we lose the nice version.
<Rossen> q?
<iank_> heycam: What is in the spec at the moment is good, I'll probably only implment the WLC for compat reasons, but want to try and get to the standards based version.
<iank_> heycam: The aim for the fragmentation based solution is good.
<florian> q?
<iank_> heycam: I don't think the line-clamp shorthand is possible.
<iank_> florian: I think there is an issue in the spec, about this.
<iank_> heycam: Can I ask people if skipping over new formatting contexts is a good thing?
<dholbert> s/the line-clamp shorthand/making the prefixed webkit-line-clamp property an alias of the standards-based thing/
<iank_> fantasai: I think that its not clear for new formatting context (like flex) its not clear what applies.
<iank_> fantasai: e.g. horz flexbox.
<iank_> heycam: I agree.
<fantasai> s/horz flexbox/horizontal flexbox or table, what do you clamp? each item in the row, first item only.../
<iank_> florian: I would to keep a vertical webkit-box w/ single item is simpler, if isn't sufficient for web compat, and need to handle multiple items, then if we need to handle that, yup can add to spec.
<iank_> heycam: Can I also ask if people are against the size calcuation the current implementations have.
<iank_> florian: Would rather not spec, until we need them.
<iank_> iank_: We might need them.
<iank_> heycam: I've written a bunch of tests to determine what is happening.
<iank_> heycam: One final difference, is the exact position, in standards version it is the block-end edge of the line-box, in impls its acutally block-end edge of the items within that linebox.
<iank_> fantasai: The line-box can be taller.
<emilio_> Scribenick: emilio
<emilio_> florian[m]: it makes the line shorter, because the line can be taller due to line-height
<emilio_> TabAtkins: is that what auto-sizing does?
<emilio_> (somebody): no
<emilio_> TabAtkins: then that's bad
<emilio_> heycam: I agree that line-box block-end edge makes more sense
<emilio_> iank_: I actually got a request a couple days ago about our behavior being bad, and it's a one-liner, so I may just try to change it
<emilio_> iank_: To do the same as auto-height
<emilio_> TabAtkins: cool
<emilio_> iank_: WebKit's behavior is also bad, and it's probably the same one-liner
<emilio_> heycam: another difference is that the flex item is inflexible if you have line-clamp on the flex container
<emilio_> heycam: I suspect this is not a problem in practice since authors are not using this feature for flexbox sizing anyway
<emilio_> heycam: I think this is all we wanted to get out of this
<florian> q+
<emilio_> heycam: I'll change the patch to use the line-box block-end edge as iank_ is going to do in Blink and land the weirdo behavior
<iank_> Use counters, see https://www.chromestatus.com/metrics/feature/popularity and WebkitBox* counters.
<emilio_> fantasai_: for the flex special-case, the simpler thing is that if you have an anonymous flex item, you inherit line-clamp from the parent
<emilio_> heycam: current patch makes it apply to both anon and non-anon flex containers
<emilio_> heycam: may be more complicated
<emilio_> emilio_: no, just inherit from ::-moz-anonymous-* thing
<emilio_> heycam: ah, ok, maybe not
<emilio_> florian[m]: If we specify that -webkit-line-clamp only applies to display: -webkit-box, we need to define what that is
<xfq> ack florian
<emilio_> iank_: some of it is in the compat spec
<emilio_> florian[m]: should we pull that in?
<emilio_> florian[m]: can we rely on the compat spec to do that?
<emilio_> dholbert: yeah, it's not exactly the WebKit implementation but has been good enough
<emilio_> florian[m]: ok, there's no w3c spec that depends on the compat spec, so may be an issue
<emilio_> fantasai_: isn't it a whatwg spec? we can refer to that
<emilio_> florian[m]: we can pull from compat spec as well
<emilio_> (everyone): let's not discuss that now
<emilio_> heycam: is the idea to do that when we have the non-webkit version as well?
<emilio_> heycam: or does it makes sense to do it already?
<emilio_> florian[m]: I think we should spec everything we're moderately sure we won't be able to rip off
<emilio_> dholbert: we can move -webkit-line-clamp to the compat spec too
<emilio_> florian[m]: the way I see it is that things that we need to define precisely how they work should get on the proper spec
<emilio_> florian[m]: you could see the compat spec as an incubation thing for these things
<emilio_> TabAtkins: The ideal is that things in compat should effectively migrate out into real spec

[frivoal]

Updated the spec to reflect what @heycam found to be necessary for webcompat, after discussing it with @heycam, @fantasai, @emilio.

Agenda+ to ask the WG to confirm this commit.

[heycam]

If you could also confirm #3697 at the same time that would be great, thanks.

[frivoal]

Thanks for #3697, that was a good clarification.