- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 20 Aug 2025 12:48:27 +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: for purposes of block-ellipsis "immediately preceding", abspos and end of element are ignored` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> andreubotella: block-ellipsis is a longhand for line-clamp. says it only affects a line box if it's immediately preceding a clamp point<br> <TabAtkins> andreubotella: when you clamp by line count, "immediately precedes" is clear<br> <TabAtkins> andreubotella: when you clamp by height it's not cleaer<br> <TabAtkins> andreubotella: here's two styles for the same html<br> <andreubotella> https://github.com/w3c/csswg-drafts/issues/10868#issuecomment-2991132884<br> <TabAtkins> (one clamps by 2, one clamps by 2lh height)<br> <TabAtkins> andreubotella: in "2", line 2 is before the clamp point, so it's ellipsized<br> <TabAtkins> andreubotella: abspos is after the clamp point, but still shown (per issue)<br> <TabAtkins> andreubotella: but in height based, abspos is immediately before the clamp point, line 2 isn't. so it's not ellipsized, per naive spec reading<br> <TabAtkins> andreubotella: these two visually clamp at the same point but ellipsize differently. probably not what we want<br> <TabAtkins> andreubotella: two options.<br> <TabAtkins> andreubotella: first is ignoring abspos for "immediatley precede"<br> <TabAtkins> andreubotella: another is not allowing clamp points to be after abspos<br> <TabAtkins> andreubotella: currently continue:collapse already restricts clamp point to be a) at start, b) between line boxes, or c) between in-flow sibling boxes<br> <astearns> abspos is not the only thing that can invoke this discrepancy, right? Anything that has not height…<br> <TabAtkins> andreubotellawe dont' allow clamping at start or end of the box (other than line-clamp container itself)<br> <TabAtkins> andreubotella: in this example there's no allowed clamp point before the abspos. but clamping after div shoudl probably ellipsize line 1<br> <andreubotella> https://github.com/w3c/csswg-drafts/issues/10868#issuecomment-3045732790<br> <TabAtkins> andreubotella: how to spec this?<br> <TabAtkins> andreubotella: my feeling is we might want to do both these options<br> <TabAtkins> andreubotella: so if there are abspos between two siblings, clamp point goes before it<br> <florian> q+<br> <astearns> ack fantasai<br> <TabAtkins> andreubotella: but also tweaking "immediately preceding" text<br> <TabAtkins> fantasai: i think abspos should be ignored for determining ellipsis<br> <TabAtkins> fantasai: any out of flow<br> <TabAtkins> fantasai: we shoudl be consistent about whther the abspos is included before/after the clamp point<br> <TabAtkins> fantasai: seems like including it makes the most sense<br> <TabAtkins> andreubotella: yes. i suppose to some extnet it's an editorial question about how best to spec<br> <TabAtkins> andreubotella: "immediately before" is also a problem with the ???<br> <TabAtkins> fantasai: so in this exapmle obvs the abspos should go with the element it's in, whereever it's clamped to<br> <TabAtkins> fantasai: but if the abpsos is between two siblings, including it if the clamp falls between the siblings makes sense<br> <TabAtkins> florian: is it observable whether it's befor eor after the clamp point?<br> <TabAtkins> fantasai: for discard, yes<br> <astearns> ack florian<br> <TabAtkins> florian: do we ahve a variant of the same problem with empty divs?<br> <TabAtkins> andreubotella: currently in-flow with zero height count as something that blocks the ellipsis on the preceding line<br> <TabAtkins> florian: i don't mind that if they actually ahve content<br> <TabAtkins> florian: but if they're empty.... seems unfortunate to block the ellipsis just because an empty div follows it<br> <TabAtkins> fantasai: i don't feel too strongly about whether it's before or after those, i just want to consistent across the modes<br> <TabAtkins> fantasai: but empty boxes probably shoudl be ignored<br> <TabAtkins> fantasai: for ellipsis<br> <TabAtkins> fantasai: so clamping and ellipsis might not be exactly the same point. from the clamp point, you walk backwards until you find some content<br> <TabAtkins> florian: for the clamp and "immediately before", maybe if you have element boundaries or static position of OOF things, I'd like to skip<br> <TabAtkins> florian: empty elements id' like to skip, but an empty with padding/border, i'm less sure<br> <TabAtkins> florian: but a thing you'd margin-collapse thru should be ignored<br> <TabAtkins> florian: roughly<br> <TabAtkins> andreubotella: tying to match that might be pretty complicated<br> <TabAtkins> TabAtkins: i think if you ahve an element that can be collapse thru, that's your problem. don't do that<br> <TabAtkins> florian: so element boundaries and OOF things don't count for blocking ellipsis. anything else?<br> <TabAtkins> andreubotella: i don't think so.<br> <TabAtkins> andreubotella: for floats, you treat the whole float as monolithic, i think<br> <TabAtkins> florian: floats can be fragmented, but...<br> <TabAtkins> florian: a float:left isn't after the line, it's before<br> <TabAtkins> florian: a float:right, tho<br> <TabAtkins> andreubotella: the spec i drafted for finding the clamp point is... the block size (ignoring hidden elements) isn't larger than the clamp length<br> <TabAtkins> andreubotella: in that definition, floats are monolithic.<br> <TabAtkins> andreubotella: not sure that's what we want<br> <TabAtkins> florian: i think for continue:collapse, this is designed to be simple and usable, not sophisticated and doing fancy things in all cases<br> <TabAtkins> florian: so it's not meant to do something smart with floats. just define something simple. smart is for continue:discard<br> <TabAtkins> andreubotella: so conclusion is we should open an issue to talk about what to do with floats, open an issue about empty blocks, and for abspos, both abspos and end of an element are ignored for "immediately preceding"<br> <TabAtkins> astearns: we want to be consistent with where we clamp and where we place ellipsis<br> <TabAtkins> andreubotella: proposed resolution is, for purposes of block-ellipsis "immediately preceding", abspos and end of element are ignored<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: for purposes of block-ellipsis "immediately preceding", abspos and end of element are ignored<br> <TabAtkins> andreubotella: for abspos, whether clamp point is before or after it doesn't matter, no visual difference i think. abspos will be shown regardless<br> <TabAtkins> astearns: for floats there might be a difference<br> <TabAtkins> andreubotella: for empty elements, it might have a difference<br> <TabAtkins> andreubotella: if an empty element has relpos and there's some abspos using it as CB, that would be a case where the clamp point would matter<br> <TabAtkins> astearns: okay so for this issue, clamp point doesn't matter.<br> <TabAtkins> astearns: you'll have more issues to get to, but we'll break for now<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-3206198816 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 20 August 2025 12:48:28 UTC