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