W3C home > Mailing lists > Public > public-css-archive@w3.org > February 2019

Re: [csswg-drafts] [css-overflow] convert -webkit-line-clamp alias requirement into a spec issue (#2847)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 28 Feb 2019 00:20:54 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-468084957-1551313253-sysbot+gh@w3.org>
The CSS Working Group just discussed `-webkit-line-clamp compatibility issues`.

<details><summary>The full IRC log of that discussion</summary>
&lt;xfq> Topic: -webkit-line-clamp compatibility issues<br>
&lt;xfq> github: https://github.com/w3c/csswg-drafts/issues/2847<br>
&lt;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<br>
&lt;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.<br>
&lt;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<br>
&lt;iank_> heycam: As in blink/WK you'll end up with an element w/ this size, however the remaining lines will appear as overflow.<br>
&lt;iank_> these differences aren't insignificant, i've written patch for what blink/WK have done. Wanted to do this in a reasonable time.<br>
&lt;iank_> TabAtkins: The existing WLC impls are bad and horrible.<br>
&lt;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.<br>
&lt;fantasai> The differences are largely intentional https://medium.com/mofed/css-line-clamp-the-good-the-bad-and-the-straight-up-broken-865413f16e5<br>
&lt;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.<br>
&lt;fantasai> Main concern is really interaction with -webkit-box<br>
&lt;iank_> TabAtkins: iank_ did some looking.<br>
&lt;florian> q+<br>
&lt;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.<br>
&lt;iank_> iank_: This allowed us to kill percentage WLC<br>
&lt;iank_> heycam: yaya<br>
&lt;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.<br>
&lt;astearns> https://www.chromestatus.com/metrics/feature/timeline/popularity/2139<br>
&lt;iank_> heycam: Where this difference has more of an effect, as it only works on a "box-item" that establibishs a independent formatting context.<br>
&lt;iank_> heycam: If repsected that rule, we'd never be able to apply that line-clamp. Needs to be an exception around this.<br>
&lt;Rossen> q?<br>
&lt;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.<br>
&lt;iank_> heycam: I think that's a sensible thing to do.<br>
&lt;xfq> ack florian<br>
&lt;Rossen> ack florian<br>
&lt;iank_> florian: Most differences are intentional<br>
&lt;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.<br>
&lt;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.<br>
&lt;fantasai> s/alt./ulterior/<br>
&lt;iank_> florian: This solution is a subset which we need to get to overflow: fragments.<br>
&lt;iank_> florian: I think this is a good things.<br>
&lt;fantasai> s/Its/But it's also/<br>
&lt;iank_> florian: Wouldn't want to clean the hacks so much that we lose the nice version.<br>
&lt;Rossen> q?<br>
&lt;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.<br>
&lt;iank_> heycam: The aim for the fragmentation based solution is good.<br>
&lt;florian> q?<br>
&lt;iank_> heycam: I don't think the line-clamp shorthand is possible.<br>
&lt;iank_> florian: I think there is an issue in the spec, about this.<br>
&lt;iank_> heycam: Can I ask people if skipping over new formatting contexts is a good thing?<br>
&lt;dholbert> s/the line-clamp shorthand/making the prefixed webkit-line-clamp property an alias of the standards-based thing/<br>
&lt;iank_> fantasai: I think that its not clear for new formatting context (like flex) its not clear what applies.<br>
&lt;iank_> fantasai: e.g. horz flexbox.<br>
&lt;iank_> heycam: I agree.<br>
&lt;fantasai> s/horz flexbox/horizontal flexbox or table, what do you clamp? each item in the row, first item only.../<br>
&lt;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.<br>
&lt;iank_> heycam: Can I also ask if people are against the size calcuation the current implementations have.<br>
&lt;iank_> florian: Would rather not spec, until we need them.<br>
&lt;iank_> iank_: We might need them.<br>
&lt;iank_> heycam: I've written a bunch of tests to determine what is happening.<br>
&lt;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.<br>
&lt;iank_> fantasai: The line-box can be taller.<br>
&lt;emilio_> Scribenick: emilio<br>
&lt;emilio_> florian[m]: it makes the line shorter, because the line can be taller due to line-height<br>
&lt;emilio_> TabAtkins: is that what auto-sizing does?<br>
&lt;emilio_> (somebody): no<br>
&lt;emilio_> TabAtkins: then that's bad<br>
&lt;emilio_> heycam: I agree that line-box block-end edge makes more sense<br>
&lt;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<br>
&lt;emilio_> iank_: To do the same as auto-height<br>
&lt;emilio_> TabAtkins: cool<br>
&lt;emilio_> iank_: WebKit's behavior is also bad, and it's probably the same one-liner<br>
&lt;emilio_> heycam: another difference is that the flex item is inflexible if you have line-clamp on the flex container<br>
&lt;emilio_> heycam: I suspect this is not a problem in practice since authors are not using this feature for flexbox sizing anyway<br>
&lt;emilio_> heycam: I think this is all we wanted to get out of this<br>
&lt;florian> q+<br>
&lt;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<br>
&lt;iank_> Use counters, see https://www.chromestatus.com/metrics/feature/popularity and WebkitBox* counters.<br>
&lt;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<br>
&lt;emilio_> heycam: current patch makes it apply to both anon and non-anon flex containers<br>
&lt;emilio_> heycam: may be more complicated<br>
&lt;emilio_> emilio_: no, just inherit from ::-moz-anonymous-* thing<br>
&lt;emilio_> heycam: ah, ok, maybe not<br>
&lt;emilio_> florian[m]: If we specify that -webkit-line-clamp only applies to display: -webkit-box, we need to define what that is<br>
&lt;xfq> ack florian<br>
&lt;emilio_> iank_: some of it is in the compat spec<br>
&lt;emilio_> florian[m]: should we pull that in?<br>
&lt;emilio_> florian[m]: can we rely on the compat spec to do that?<br>
&lt;emilio_> dholbert: yeah, it's not exactly the WebKit implementation but has been good enough<br>
&lt;emilio_> florian[m]: ok, there's no w3c spec that depends on the compat spec, so may be an issue<br>
&lt;emilio_> fantasai_: isn't it a whatwg spec? we can refer to that<br>
&lt;emilio_> florian[m]: we can pull from compat spec as well<br>
&lt;emilio_> (everyone): let's not discuss that now<br>
&lt;emilio_> heycam: is the idea to do that when we have the non-webkit version as well?<br>
&lt;emilio_> heycam: or does it makes sense to do it already?<br>
&lt;emilio_> florian[m]: I think we should spec everything we're moderately sure we won't be able to rip off<br>
&lt;emilio_> dholbert: we can move -webkit-line-clamp to the compat spec too<br>
&lt;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<br>
&lt;emilio_> florian[m]: you could see the compat spec as an incubation thing for these things<br>
&lt;emilio_> TabAtkins: The ideal is that things in compat should effectively migrate out into real spec<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2847#issuecomment-468084957 using your GitHub account
Received on Thursday, 28 February 2019 00:20:56 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:44 UTC