- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 02 Apr 2025 15:24:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-overflow] What counts as "immediately preceding" for `block-ellipsis`?``, and agreed to the following: * `RESOLVED: when doing a height-based clamp, content after the last fitting line but within the height still gets displayed. a line-based clamp clamps after the clamped line` * `RESOLVED: Leave the spec as-is wrt ellipsis when the last thing before the clamp isn't a line. (aka don't draw the ellipsis in this case)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> florian: if you're line-calmping pure text it's easy, but there are things that aren't lines, like a block image<br> <TabAtkins> florian: so an interseting set of questions, maybe the asnwer is the same when you clamp by line count vs height, but...<br> <TabAtkins> florian: say you have 3 lines of text, several blockified images, then a fourth lines<br> <TabAtkins> florian: if you say line-clamp:4, you clamp after 4 lines, easy<br> <TabAtkins> florian: if you say line-clamp:4 but there's not room for all four, just three lines + some images, do you stop after the last line of text, o rkeep everythingg that fits<br> <TabAtkins> florian: same question if you clamped by height, and that line ends after a few of the images<br> <TabAtkins> florian: a possible answer is you stop after the last line that fits, everything else is dropped even if you have room for it<br> <TabAtkins> florian: another is you keep the extra content, but then where do you put the ellipsis?<br> <TabAtkins> florian: on the alst line of text that fits even tho it's well above the cu tpoint?<br> <TabAtkins> florian: or just dont' do an ellipsis, since the last thing beofre the break isn't a line?<br> <TabAtkins> florian: do we want the same answer for count and height clamping? or different?<br> <TabAtkins> florian: i think that's the full problem space. we got the questions thru thinking about this issue<br> <TabAtkins> florian: i think it would be unfortunate to have room for more content and not dipslay it<br> <TabAtkins> florian: i have a mild preference for displaying the images, and not having ellipsis<br> <TabAtkins> florian: I think Tab would prefer the ellipsis on the last line of text, followed by images<br> <TabAtkins> florian: as it still tells you there's more to come<br> <astearns> ack dbaron<br> <TabAtkins> dbaron: I think I mostly agree with your preferences, with the caveat i don't really care about the ellipsis itself<br> <TabAtkins> dbaron: but agree about showing content that fits<br> <TabAtkins> dbaron: question is in the case where you're counting lines, does it make sense to count block images as lines rather than pretend they don't exist? or is there a reason not to?<br> <TabAtkins> florian: we started from just counting lines as lines, didn't think further. don't think that solves the problem entirely.<br> <TabAtkins> iank_: there's a small reason to keep them separated to just count lines<br> <TabAtkins> iank_: block level images, eh, but imagine you have block content at the start of the cdontext, then say line-clamp:3, it would be surprising if you had the image and then just two lines<br> <TabAtkins> iank_: so i do think you just want to count actual lines<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: agree with preferenc e to show ccontent if there's space<br> <TabAtkins> fantasai: question about where to put ellipsis is interesting<br> <TabAtkins> fantasai: what does the spec say if there's no lines/<br> <TabAtkins> florian: i htink you don't put it<br> <TabAtkins> andreubotella: yes<br> <astearns> q+<br> <iank_> q+<br> <TabAtkins> andreubotella: current spec is based on continue:discard, it says the block-overflow ellipsis is..... can't find it righ tnow. it says it's immediatley before a region break or the clamp point. if there is no line, there's nothing<br> <TabAtkins> florian: a bit more detail, the block-ellipsis longhand property doesn't apply to the clamping container, it applies to block containers<br> <TabAtkins> florian: wherever your clamp point ends up being, if it's in the middle of a block element, it inserts the ellipsis on *its* final line.<br> <TabAtkins> florian: and if there's no line, no ellipsis<br> <TabAtkins> fantasai: i think that makes sense<br> <TabAtkins> fantasai: so i think it makes sense to not insert the ellipsis unless we're clamping right before the line<br> <TabAtkins> fantasai: think it woudl also be a bit misleading if the paragraph had the ellipsis right before the images, it looks like the paragraph isn't completed<br> <TabAtkins> astearns: i think the ellpsis is an important part of the feature. to ensure we're always displaying the ellipsis in a place that makes sense, i'd be happy to discard the block content after the ellipsis to prioritize showing the ellipsis<br> <TabAtkins> astearns: but this is an edge case, don't strongly care<br> <TabAtkins> florian: another variant is we could say that, once you're dsicard remaining contents, if the last thing doesn't have lines, you insert one more line just for the ellipsis, and if that doesn't fit you remove until it does<br> <TabAtkins> florian: so if cut point allowed three lines and two images, you remove the second image and put in a line with the ...<br> <TabAtkins> astearns: so if there's only one block-level image before the clamp point, we woudln't display the image, the ellipsis would be on a separate line below the last actual line<br> <andreubotella> q+<br> <TabAtkins> astearns: it might be too complicated or such an edge case, but i think i would prefer it to the other options<br> <astearns> ack astearns<br> <TabAtkins> iank_: i think we agreed previously that the line-clamp:auto case should behave the same as specifying the number of lines clamped<br> <TabAtkins> iank_: and this seems to be going against that<br> <TabAtkins> iank_: i think i have a preference of hiding the content after the clamped line<br> <TabAtkins> q+<br> <TabAtkins> iank_: for consistency<br> <astearns> ack iank_<br> <TabAtkins> iank_: and it feels more consistent that if there's a ... there's more content. having content after that feels wrong to me<br> <TabAtkins> iank_: don't think we should have a line that just containts an ellipsis, suspect we'd get bug reports on that<br> <TabAtkins> florian: i think if you have line-clamp:3 you should get three lines, not 3 lines and some images<br> <TabAtkins> iank_: right, i think we have some discussion about that<br> <TabAtkins> florian: no reoslution<br> <astearns> ack andreubotella<br> <TabAtkins> andreubotella: so we're talkinga bout block images, but it's not just that. if you have an IC, a block with a height but no lines, these are also cases where this would happen<br> <TabAtkins> andreubotella: so i'm unsure if it's as edge-casey as we might otherwise think<br> <TabAtkins> andreubotella: only block images, sure, but with all these other options seems more common, a table or something<br> <astearns> ack TabAtkins<br> <fantasai> s/IC/independent formatting context/<br> <fantasai> TabAtkins: Big thing I want to be consistent with, is that we should not be giving 'auto' to produce behavior that cannot be produced with an integer<br> <fantasai> TabAtkins: that doesn't necessarily mean that 'auto' behavior Florian wants is wrong<br> <iank_> sorry<br> <fantasai> TabAtkins: whether that's something we do turn on for an integer clamp, e.g. if you clamp to 4 lines, we should show 3 lines of text and following images<br> <fantasai> TabAtkins: and maybe add a keyword to show whatever still fits<br> <fantasai> TabAtkins: Either works for me<br> <fantasai> TabAtkins: Because they produce consistent behavior between the two pieces<br> <fantasai> TabAtkins: I just don't want 'auto' to have a different behavior not tied to concept of a height clamp<br> <TabAtkins> so like `line-clamp: 3 and-then-some;` to mean "3 lines, and whatever else non-line content sitll fits after the third line"<br> <fantasai> florian: In case where you clamp by line number<br> <fantasai> florian: and then adding extra<br> <fantasai> florian: how do you determine more stuff?<br> <fantasai> [something baout 3 lines and 1000px ]<br> <fantasai> TabAtkins: auto means some specific line clamp value, just auto-clamped for you. You don't get a magic behavior, it's a calculation that turns into a describable behavior<br> <fantasai> florian: So line-clamp: 3 magic<br> <astearns> I am not sure the difference in behavior is something authors will want to choose between. We can probably just choose one thing (and wait to see if people need the other)<br> <fantasai> florian: You get 3 lines plus however non-line things fit<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to flip Tab's argument<br> <TabAtkins> fantasai: what property is this "auto" value on?<br> <TabAtkins> andreubotella: it's in the <block-ellipsis> production (which is in line-clamp shorthand)<br> <TabAtkins> fantasai: so we don't actually ahve line-clamp with amgic keywords<br> <TabAtkins> fantasai: we have 'continue', we have 'height', we have 'max-lines'<br> <TabAtkins> fantasai: max-lines says the intrinsic height is what you get after N lines<br> <TabAtkins> fantasai: so if you set max-lines it doesn't cause clamping<br> <TabAtkins> TabAtkins: in the thoertical world where these are separate longhands, sure<br> <TabAtkins> florian: if you set line-clamp to some value that doesn't have an integer, these expand to the block-ellipsis property, and turns on the correct 'continue value<br> <TabAtkins> florian: but becuase you don't have a strict number of lines, in continue:discard you discard when you'd start to overflow...<br> <TabAtkins> fantasai: lets go back. there's no magic auto keyword<br> <TabAtkins> fantasai: all block-ellipsis does is set the ellipsis, we can ignore it<br> <TabAtkins> fantasai: i want to flip tab's argument in the other direction. tab is saying we should describe all behavior in terms of clamping lines, i'm saying we should describe in terms of height, and you clamp to that height.<br> <TabAtkins> fantasai: so clamping to a specified height is not a special case of clamping to a number of lines, clamping to lines is a special case of clamping to a magically determined height<br> <TabAtkins> fantasai: so i don't think we need to turn height-based clamping into some kind of line-based clamping, that doesn't make snese<br> <TabAtkins> astearns: i think a consequence of your conception is that a height clamp *will* contain block-level things, but a line clamp won't<br> <TabAtkins> fantasai: right<br> <astearns> that makes sense to me<br> <TabAtkins> florian: and line clamp gives you a different height where things after the line doens't fit<br> <iank_> i've got to drop<br> <TabAtkins> fantasai: but if you have no fourth line, you say line-clamp:4 and don't have four lines, you just show everything<br> <florian> +1<br> <fantasai> TabAtkins: Sounds reasonable to me<br> <fantasai> TabAtkins: is it currently the case in the spec, given our example, if you set line-clamp: 4 you get all the content without a clamp because the ...<br> <fantasai> TabAtkins: if you have line-clamp: 4 and a fixed height<br> <TabAtkins> fantasai: what you're setting is max-lines:4, and height:1000px, and you clamp at whichever comes first<br> <fantasai> andreubotella: Implementation-wise that is more complicated<br> <TabAtkins> andreubotella: impl-wise i think it's more complex<br> <TabAtkins> andreubotella: it depends on a number of factors<br> <florian> q+<br> <TabAtkins> andreubotella: currently in my impl, if you set both max-height and line-clamp:4, then max-lines takes priority because it's easier to deal with<br> <TabAtkins> andreubotella: so it's not impossible we could do the other way and clamp to whichever comes earlier<br> <TabAtkins> andreubotella: and if we ahve "line-clamp: 3 plus-more" that would solve some other<br> <astearns> ack florian<br> <TabAtkins> florian: what elika described is how we described "continue:discard" to work, and i like that<br> <TabAtkins> florian: not sure how that works in "continue:collapse", it's not purely height bsaed<br> <TabAtkins> florian: if you have decorated box with 5 lines and some borders, and you say clamp:3, you dont cut after that third line, you have the borders as well. so height is more than just the three lines height<br> <TabAtkins> florian: so line-clamp:N isn't exactly clamping after the height of N lines<br> <TabAtkins> andreubotella: well there is a height that would let you calmp after N lines, it just also depends on MBP<br> <TabAtkins> astearns: putting aside ellipsis, can we resolve that a height clamp will show trailing block-level things that fit, but a line clamp stops at the last line<br> <fantasai> TabAtkins: Possibly implies that line-clamp: 4 would clamp to 3 lines if that's all that would fit<br> <TabAtkins> florian: andreu, remind me what happens if you have line-clamp:N and a height?<br> <TabAtkins> andreubotella: if you have both, only number of lines matters in my impl<br> <TabAtkins> andreubotella: we could change to make it whichever comes first<br> <fantasai> andreubotella: but would be difficult to implement<br> <fantasai> TabAtkins: So if 4th line is overflowing, we would just overflow the box?<br> <fantasai> andreubotella: yes<br> <TabAtkins> astearns: so can we resolve on this now?<br> <TabAtkins> fantasai: yes, and the question of what happens hwen you have both a line and height clamp can be separate<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: when doing a height-based clamp, content after the last fitting line but within the height still gets displayed. a line-based clamp clamps after the clamped line<br> <fantasai> (applying both simultaneously tbd)<br> <TabAtkins> florian: so next question, if the last thing that fits before the calmp point isn't a line, do we (as currently specced) not have an ellipsis, or do we want an ellipsis somewhere?<br> <TabAtkins> astearns: for all that i prioritized dislay of ellpsis in my mind, the options are icky. so i'm happy to leave the spec as is<br> <fantasai> TabAtkins: I'm weakly for putting on last line that's visible<br> <fantasai> TabAtkins: but ok to go the other way<br> <TabAtkins> astearns: objections?<br> <TabAtkins> fantasai: think it's reasonable. if authors complain we can reconsider<br> <TabAtkins> RESOLVED: Leave the spec as-is wrt ellipsis when the last thing before the clamp isn't a line. (aka don't draw the ellipsis in this case)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10868#issuecomment-2772944494 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 2 April 2025 15:24:14 UTC