- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 06 Nov 2017 22:43:59 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Line Clamping`. <details><summary>The full IRC log of that discussion</summary> <iank_> Topic: Line Clamping<br> <TabAtkins> GitHub: https://github.com/w3c/csswg-drafts/issues/390<br> <iank_> TabAtkins: Ignore the topic of the github issue, basically many years ago, hyatt added some hacky code that turned the -webkit-box code, to allow it to do line clamping.<br> <iank_> TabAtkins: If you have more ignore them for sizing purposes.<br> <iank_> TabAtkins: The implemenation is weird, very weird behaviour, property etc.<br> <iank_> TabAtkins: We'd like to address this properly.<br> <iank_> TabAtkins: This is the only major part of the -webkit-box code that needs to be maintained.<br> <iank_> TabAtkins: What needs to be mapped, preserved for line-clamp, and removed.<br> <iank_> TabAtkins: We'd like to start up a spec to handle the line-clamping behaviour.<br> <smfr> q+<br> <iank_> eae: Would like a way to eventually alias this property over.<br> <iank_> eae: And would like to do this in a way that other folks can alias.<br> <iank_> florian: I don't remember the discussion of the spec.<br> <leaverou> q+<br> <iank_> florian: Expand on what we already have?<br> <iank_> TabAtkins: yes.<br> <astearns> ack smfr<br> <iank_> smfr: Would like to extend this feature a little.<br> <iank_> smfr: Collapses quoted text...<br> <iank_> smfr: Collapses in the middle of the content.<br> <Rossen> q?<br> <smfr> q-<br> <iank_> smfr: We would like to see this as start, end, middle.<br> <iank_> q+<br> <fantasai> q+<br> <iank_> florian: max-lines as currently specified is a fragmentation thing, makes the div into a fragmentainer, that breaks after a certain number of lines.<br> <iank_> florian: Drop the rest of the lines.<br> <fantasai> s/Collapses quoted text.../Mail client has a feature where it keeps some lines at the beginning, keeps osme lines at the end, and collapses in the middle of the content, with clicky in the middle to expand itall back/<br> <iank_> florian: Could make it such that you get additional lines.<br> <iank_> smfr: We did consider fragmentation to implement this feature, I don't really have opinions on how to do this.<br> <iank_> smfr: It does interact with fragmentation possibly<br> <astearns> ack leaverou<br> <iank_> leaverou: Why is this being discussed in terms of max-lines, and not max-height?<br> <iank_> florian: images inbetween for example, typically people want to clamp lines.<br> <fantasai> florian: and break at a fragmentation point ,not slice partway through a line<br> <iank_> florian: The generalized this in overflow-4 lets you deal with heights...<br> <gregwhitworth> q+<br> <iank_> florian: And let you decide if the additonal div gets dropped.<br> <iank_> leaverou: In most cases i've seen the clipping is visual.<br> <iank_> florian: But you don't want to split in the middle?<br> <iank_> leaverou: If an ellipsis isn't displayed, people want use this.<br> <iank_> florian: Its a separate issue...<br> <TabAtkins> s/want/won't/<br> <eae> ScribeNick: eae<br> <tantek> I am absolutely for postponining ellipsis discussion variants until CSS3-UI is a REC :)<br> <astearns> ack iank_<br> <tantek> s/postponining/postponing<br> <eae> iank_: One thing I'd like to stress is that we've seen a lot of demand for somehting simple like clamping the number of max-lines. Would like to keep it simple and not expand scope too much.<br> <eae> iank_: Clamping both start and end adds complexity as it requires layout out all of the text. Have to think about.<br> <eae> iank_: We're looking to remove support for percentage values for webkit-line-clamp. Behavior is bizare and there is essentially zero usage.<br> <astearns> ack fantasai<br> <eae> use counter for percentage values: https://www.chromestatus.com/metrics/feature/timeline/popularity/2139<br> <florian> q+<br> <gregwhitworth> ack gregwhitworth<br> <eae> fantasai: I agree that we should limit scope. A lot of thoughts are great and valid use cases. I don't want to go there right now. Want to understand actual proposal<br> <eae> fantasai: As I understand from proposal, treat as max lines and set height based on that. Is there more to it then that?<br> <eae> TabAtkins: Yon don't want the lines to still be there like with line-clamp, we want to omit the rest of the lines.<br> <eae> TabAtkins: Want to supress display of line boxes after the cut off.<br> <eae> TabAtkins: Right now they are simply considered to be of zero height for sizing but are still there<br> <eae> fantasai: So the ellipsis gets inserted?<br> <TabAtkins> https://drafts.csswg.org/css-overflow-4/#issue-6fadc074<br> <eae> florian: The machinery of clamping or cloning or fragmentation is invoked implicitly if set max-lines. There is an issue saying that one has to explicitly enabling the fragmentation support.<br> <gregwhitworth> q+<br> <eae> iank_: My only concern with that is that invokes a bunch of machinery that takes a lot of implementation work. A simple max-lines beahvior is potentially a lot simpler.<br> <eae> florian: Concerned that it would require a lot of reinvention.<br> <eae> Rossen: Want to reemphasis fantasais question. In my mind we keep going back and forth between two different things:<br> <eae> Rossen: 1) Fragmentation and stop layout at some boundary. should thing of this in css4<br> <eae> Rossen: 2) Existing pane, what tab is taking about. We have a a lot of requests for webkit-line-clamp support.<br> <eae> Rossen: My point here again. This is different. If we want to be compatible with -webkit-line-clamp then the behavior is different. Not fragmenting, consumes space differently.<br> <eae> Rossen: Not that different to implement as long as it doesn't involve fragmentation.<br> <eae> fantasai: Would like to see a concrete proposal.<br> <eae> TabAtkins: The goal of this was to start up something that at the bare minimum addresses the "I want n of something".<br> <eae> TabAtkins: All resonable things that I'd like to see addressed. Should resolve whether we want to do or not.<br> <eae> fantasai: line-clamp can be made to support a subset of uses cases but if you want support for more complex use cases then the problem gets a lot harder.<br> <eae> fantasai: Should try to tackle the problems one at a time. Have something basic that isn't quite 0webkit-ine-clamp, but without eventually supporting everything.<br> <Rossen> q?<br> <eae> TabAtkins: I would like to explore the space. Replace -webkit-line-clamp first and then, maybe, extend it later.<br> <astearns> ack florian<br> <fantasai> What I'm saying is I don't want to expand line-clamp, I would rather it stayed as some minimally simple property that could be used to build other things. not be expanded to do other things.<br> <eae> florian: responding to ian/rossen. When I was talking about invoking the machinery not walking about ..., to deal with fragmentation. I think we sort of have to, if not then we'd have to resolve what to do about text shadow, intruding floats etc. Would rather refer to the fragmentation spec.<br> <eae> florian: Would also be compatible with the rest of the spec in the future.<br> <eae> florian: css overflow invokes css break, max-lines already speced there.<br> <fantasai> https://www.w3.org/TR/css-break-3/#possible-breaks<br> <TabAtkins> ScribeNick: TabAtkins<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/390#issuecomment-342313201 using your GitHub account
Received on Monday, 6 November 2017 22:44:10 UTC