- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 18:09:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-overflow-4] Syntax to opt into clamping at the earlier of a size and a number of line`, and agreed to the following: * `RESOLVED: accept proposal in this comment, with change of moving auto value to max-lines longhand` * `RESOLVED: no special processing; this all works with webkit-legacy as well` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> florian: a while back we talked about how it's not web-compat simultaneously, by default, clamp by lines *and* height<br> <TabAtkins> florian: if you say 3 clamping by lines works, 'auto' clamp by height works, but doing which happens first doesn't work by default<br> <TabAtkins> florian: coming up with an opt-in<br> <TabAtkins> florian: goal is, if you use shorthand and say "auto 3" it'll clamp by both, whichever comes first<br> <TabAtkins> florian: how does that work with longhands<br> <TabAtkins> florian: max-lines doesn't change, none | int<br> <TabAtkins> florian: continue: normal | collapse && auto?<br> <TabAtkins> florian: collapse is count only, collapse auto is both<br> <TabAtkins> florian: block-ellipsis is unchanged<br> <TabAtkins> florian: this all rolls up into the shorthand in what I think kis the obvious way<br> <TabAtkins> florian: so this changes nothing to what's already shipped<br> <TabAtkins> florian: but rejiggered some new stuff<br> <TabAtkins> florian: contineu:normal is what used to be "auto" but i'm using that for something else<br> <TabAtkins> block-ellipsis:no-ellipsis also used to be "auto"<br> <astearns> q+<br> <TabAtkins> florian: I gave in the gh issue some syntax examples<br> <TabAtkins> florian: because it rejiggered in a minor way all these things, if we want to do it it needs to happen now, before shipping<br> <andreubotella> q+<br> <TabAtkins> astearns: to clarify, you had to rename the block-ellipsis values to avoid shorthand collision?<br> <TabAtkins> florian: yes<br> <astearns> ack astearns<br> <TabAtkins> florian: currently shorthand is deceptively doing right thins for wrong reasons<br> <TabAtkins> florian: line-clamp:3 clamps by 3 lines, line-clamp:auto clamps by height but by accident, that "auto" is actually a block-ellipsis values. it's the lack of a number that triggers height clamping<br> <astearns> ack andreubotella<br> <TabAtkins> andreubotella: I don't have issue with these auto renames<br> <TabAtkins> andreubotella: for line-clamp, the absence of an integer still causes continue to be collapse auto<br> <TabAtkins> andreubotella: but you can also set `3 auto` on purpose<br> <TabAtkins> andreubotella: that seems fine<br> <arronei> q+<br> <TabAtkins> andreubotella: with -webkit legacy it seems complicated<br> <florian> q+<br> <florian> q-<br> <TabAtkins> andreubotella: not a keyword included in here<br> <florian> q++ to respond on the webkit legacy<br> <TabAtkins> andreubotella: you couldn't have auto keyword when you have webkit-legacy, would also need an integer...<br> <TabAtkins> andreubotella: seem fine with that<br> <TabAtkins> andreubotella: wouldn't be easy to express the entire legacy syntax without having a totally separate grammar branch<br> <TabAtkins> andreubotella: think saying "auto" and "webkit-legacy" together would be invalid<br> <TabAtkins> andreubotella: I don't have a problem with this but it seems complicated<br> <astearns> ack +<br> <Zakim> +, you wanted to respond on the webkit legacy<br> <TabAtkins> florian: I wanted to talk without the webkit-legacy first, to check it makes sense<br> <TabAtkins> florian: for legacy part, two ways<br> <TabAtkins> florian: one, keep minimalist as we've done so far, it doesn't include height clamping<br> <TabAtkins> florian: so `continue` gains one more keyword, the legacy thing, and rejigger the shorthand so you can't say "auto" and "legacy" at same time<br> <TabAtkins> florian: or we do allow them at the same and allow height clamping. don't care<br> <TabAtkins> florian: the shorthand syntax is just a little weird<br> <TabAtkins> andreubotella: for me not having webkit-legacy makes sense, it makes the set of shorthand values a bit awkward<br> <TabAtkins> andreubotella: either nearly-identical branches, or ban it in prose<br> <TabAtkins> florian: I think `[auto | webkit-legacy]` would work?<br> <TabAtkins> andreubotella: right now webkit-legacy can only go at the end<br> <TabAtkins> florian: ah I see<br> <TabAtkins> florian: so whichever is fine, depending on whether we want to keep shorthand more complicated or allow legacy to gain new features<br> <TabAtkins> andreubotella: i'm fine with the shorthand getting more complicated. webkit-legacy shouldn't be used by devs anyway<br> <astearns> ack arronei<br> <TabAtkins> arronei: if we're doing some renames here, I don't love 'block-ellipsis: ellipsis' and no-ellipsis. lots of repeat. don't have great suggestions<br> <TabAtkins> arronei: like 'hidden' becomes a little ambiguous..<br> <TabAtkins> arronei: just a general discomfort<br> <florian> q+ to respond to arronei<br> <astearns> ack florian<br> <Zakim> florian, you wanted to respond to arronei<br> <TabAtkins> fantasai: note it matches text-overflow:ellipsis<br> <TabAtkins> florian: right. over there it's not a repeat, here it is.<br> <TabAtkins> florian: "none" is used for something else, is why it's not used here<br> <TabAtkins> q+<br> <TabAtkins> fantasai: it works well in the shorthand, which is probably what people would use anyway<br> <TabAtkins> arronei: would we be against change the property name...?<br> <TabAtkins> florian: in principle no but I don't have a suggestion for rit<br> <TabAtkins> florian: suggest in the absence of an idea we go with this for now<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: overall this makes sense<br> <TabAtkins> fantasai: especially the way the shorthand maps out<br> <TabAtkins> fantasai: the way we have auto tracked onto collapse strikes me as weird<br> <TabAtkins> fantasai: continue is about what you do with the overflowing content<br> <TabAtkins> fantasai: auto is about the eheight<br> <TabAtkins> fantasai: that's totally different concept<br> <TabAtkins> fantasai: and "auto" is so generic there<br> <TabAtkins> florian: I considered putting it into max-lines<br> <TabAtkins> florian: but if continue:discard is a thing, it has the behavior already<br> <TabAtkins> florian: that's just how fragment works<br> <TabAtkins> florian: so it's a mode of collapse<br> <TabAtkins> fantasai: it's a variant of collapse because we decided collapse doesn't do that by default<br> <TabAtkins> florian: yeah but the other values don't have that. it would be weird to have discard not to both by default<br> <TabAtkins> fantasai: auto is just so generic, if it's shorthand magic it's fine.<br> <fantasai> scribe+<br> <fantasai> TabAtkins: Go ahead and put it in max-lines. It's fine for some parts of the property to not apply.<br> <fantasai> TabAtkins: max-lines seems like the right place to put it<br> <fantasai> florian: So maybe move auto to max-lines<br> <fantasai> florian: or maybe split collapse into two variants, collapse-variant1 and collapse-variant2<br> <fantasai> florian: If you don't have 'auto' you only clamp by number of lines. With it, you can clamp by either lines or height.<br> <fantasai> TabAtkins: You either specify auto and get height clamp, or lines and get line clamp, or both and get both clamp.<br> <fantasai> TabAtkins: So 'auto' seems ok. Height I don't want cuz writing modes. Size is weird.<br> <fantasai> TabAtkins: But you determine the max-lines automatically based on the height of the box.<br> <fantasai> TabAtkins: 'auto' is fine.<br> <TabAtkins> andreubotella: so then 'auto' is independent of legacy because eit's different property<br> <TabAtkins> andreubotella: and that's simpler<br> <astearns> consider-height?<br> <TabAtkins> fantasai: makes sense<br> <TabAtkins> astearns: proposed, accept proposal in this comment, with change of moving auto value to max-lines longhand<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: You said you switched to no-ellipsis to avoid clash with none.<br> <fantasai> florian: We resolved on that awhile back. I think it was about that.<br> <fantasai> andreubotella: Paris. Pretty sure it was none previously, and was to avoid the clash.<br> <astearns> s/the clash/the clash with max-lines/<br> <fantasai> florian: line-clamp: none; would give no clamping. But line-clamp: 3 none; would give you clamping with no ellipsis which seemed weird.<br> <fantasai> florian: It wasn't that we couldn't parse it, but it was confusing.<br> <TabAtkins> astearns: so any objections?<br> <TabAtkins> RESOLVED: accept proposal in this comment, with change of moving auto value to max-lines longhand<br> <TabAtkins> florian: and about webkit-legacy, keep it minimalist or allow it to be combined with new functionality?<br> <TabAtkins> andreubotella: if "auto" is in continue, I see a much stronger point to not allowing both at the same time<br> <TabAtkins> andreubotella: for the shorthand, there's already thing you can do with webkit-legacy that you couldnt' do with -webkit-line-clamp<br> <TabAtkins> andreubotella: so i'm fine with allowing it<br> <TabAtkins> florian: so proposal is this also works with webkit-legacy<br> <TabAtkins> TabAtkins: what property does the value live in?<br> <TabAtkins> florian: continue<br> <TabAtkins> florian: so trying to ban it would be a little awkward<br> <TabAtkins> astearns: do we need to resolve?<br> <TabAtkins> florian: it falls out somewhat naturally, but might as well resolve<br> <TabAtkins> florian: proposed: no special processing; this all works with webkit-legacy as well<br> <TabAtkins> RESOLVED: no special processing; this all works with webkit-legacy as well<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13670#issuecomment-4179572519 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 18:09:09 UTC