- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 17 Sep 2025 19:24:12 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Overflow Breakout
=====================
nowrap and block-ellipsis (Issue #12811)
----------------------------------------
- RESOLVED: Clarify the interaction between nowrap and block ellipsis
Interaction between whitespace collapsing and line-clamp (Issue #12008)
-----------------------------------------------------------------------
- RESOLVED: Rendering should be equivalent to line breaking at that
soft wrap opportunity, and applying white space
processing part 2 before inserting ellipsis at the end
How does `widows` and similar properties affecting fragmentation
interact with `continue: discard`? (Issue #9235)
----------------------------------------------------------------
- RESOLVED: The region break set by line-clamp ignores widows/orphans
How do empty blocks affect line-clamping by height? (Issue #12663)
------------------------------------------------------------------
- RESOLVED: Close no change until/unless users complain
Floats and line-clamp (Issue #12665)
------------------------------------
- RESOLVED: Floats do not increase the height of a line clamp
container. They are clipped to its content edge.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2025Sep/0009.html
Present:
David Baron
Andreu Botella
Yehonatan Daniv
Elika Etemad
Robert Flack
Daniel Holbert
Roman Komarov
Romain Menke
Florian Rivoal
Alan Stearns
Miriam Suzanne
Scribe: ydaniv
CSS Overflow
============
nowrap and block-ellipsis
-------------------------
github: https://github.com/w3c/csswg-drafts/issues/12811
florian: there seems to be some ambiguity about text spec
florian: when you remove content next to ellipsis it should disappear
florian: up to the next soft wrap opportunity
florian: but the way the white space is currently specified, nowrap
and pre do not suppress it
florian: so reading it says that even if it says nowrap they do not
suppress the wrapping opportunity, just not to take them for
line break processing
florian: so literal reading would have it do something else
florian: proposal is to not do that, and leave to the editor to find
exact spec wording, and confirm that when you can't wrap you
remove the whole thing to insert the ellipsis
andreubotella: if you have a forced line break inside pre or nowrap
then it forces to...
andreubotella: and there is enough room at the end of the line to fit
the ellipsis, that is allowed
andreubotella: it's only when the ellipsis doesn't fit and you're
looking for a previous placement point that nowrap
would require removing the whole content
astearns: so editorially if not specified, could spec editor specify
that?
astearns: is there some reason why nowrap is specified that way?
florian: my suspicion is editorial accident
astearns: proposed resolution is to clarify the interaction between
nowrap and block ellipsis
fantasai: I would prefer to define this on the line clamp side
fantasai: that opportunities don't exist unless we need to know where
they are for other reason
fantasai: say it ignores them with in nowrap
astearns: that's the safeset, wondering if it's enough
fantasai: question whether the information is there and can be
accessed
florian: I think editors can take that, since me and fantasai are
editors we could
astearns: objections?
astearns: none
RESOLVED: clarify the interaction between nowrap and block ellipsis
Interaction between whitespace collapsing and line-clamp
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12008
scribe: fantasai
scribe's scribe: astearns
andreubotella: Block finds the last soft wrap opportunity and removes
content from that point to end of line
andreubotella: What does that mean in terms of whitespace?
andreubotella: wrt unicode line breaking algorithm, line breaking
opportunity is after the space, not before
andreubotella: This is probably not what we want
andreubotella: Way I conceptualize this is, rather than finding last
opportunity that fits, remove the width of ellipsis
from the available width of the line, do regular line
breaking based on that, and then add the ellipsis
andreubotella: in that model, if the ellipsis is placed after white
space processing part II, which removes collapsible
spaces, it will be placed at the end of the word
andreubotella: I don't necessarily want to require that the
line-breaking algo has to take into account the
ellipsis, that's an implementation strategy
andreubotella: proposed resolution, if you have clamp point at white
space, make it work as if line break happened there,
and ellipsis was placed after WS Processing Part 2
andreubotella: which removes the space
florian: I agree with the proposal
florian: Don't want to require a particular implementation strategy,
but describing this way is helpful and easy because we
invoke existing spec text
florian: that's a very complicated logic depending on which spaces
and white space properties are at the end of the line
florian: so saying we do "as if" at the end of the line is a good idea
andreubotella: Another complication related to hanging white space
andreubotella: You can have space at the end of the line that isn't
collapsible, but can hang off the end of the line
(width isn't accounted for in line breaking or
alignment)
andreubotella: Only space at the end of the line can hang. If you put
ellipsis there, can't hang anymore.
andreubotella: We could make the ellipsis hang... so not impossible
andreubotella: but idk if we want to require that or what
astearns: Let's say that's a separate issue for now, and take a
resolution on what we do with collapsible white space
andreubotella: "Rendering should be equivalent to line breaking at
that soft wrap opportunity, and applying white space
processing part 2 before inserting ellipsis at the end"
astearns: Makes sense
PROPOSED: Rendering should be equivalent to line breaking at that
soft wrap opportunity, and applying white space processing part 2
before inserting ellipsis at the end
RESOLVED: Rendering should be equivalent to line breaking at that
soft wrap opportunity, and applying white space processing
part 2 before inserting ellipsis at the end
fantasai: fwiw, if we put ellipsis after the spaces, then nothing
should hang anymore
florian: yeah, question is whether that's where the ellipsis should go
How does `widows` and similar properties affecting fragmentation
interact with `continue: discard`?
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9235
andreubotella: Here's an implementation of continue:collapse. You can
see when the height is reduced to zero, the lines get
hidden one by one.
andreubotella: continue:discard is the previous version of this,
which was handled with fragmentation
andreubotella: You don't see the same thing, you see that first two
lines are hidden together
andreubotella: If you only leave space for first line, both discarded.
andreubotella: Reason for this is 2 properties called widows/orphans
andreubotella: Names are typographical terms, somewhat confusing,
maybe we need to rename? But that's off-topic
andreubotella: They control how many lines can be by themselves at
the start or end of a fragment
andreubotella: The default value is 2, meaning a single fragment
isn't allowed
fantasai: do you have an incorrect assumption?
fantasai: widows shouldn't affect the first fragment
fantasai: There's no breaking opportunity between the start of the
container and its first line box
fantasai: You will always place at least some content
florian: If you have a 2-line paragraph, and a many line paragraph...
in fragmentation it is what you want, but in this case maybe
not
florian: My suggestion is that line-clamp also sets widows/orphans
to 1.
florian: Otherwise if there's room for 3 lines, and you only get 2,
it will be surprising
andreubotella: My suggestion was to make line-clamp ignore widows/
orphans
dbaron: Principle is that you always place something.
dbaron: One reason it exists is not getting into an infinite loop
when all fragmentainers are identical.
dbaron: In this case, you have to place something.
dbaron: In context where fragmentainers are not all identical, you
may or may not want that principle.
dbaron: But I think we're coming to another solution here...
florian: Andreu's and mine would do the same thing by default, but
mine allows authors to set things so that they do take
effect, whereas in Andreu's there's no option
astearns: Chair hat off, I'm a little more comfortable with just
defining interaction between the properties, rather than
having one property set another...
florian: I'm split here. Andreu's version is less magic
florian: If you're doing a very small height in which you're
line-clamping, but if people are doing it on a bigger chunk
of content, room for 10 lines
florian: maybe in that case would want to have widows and orphans
take effect
florian: Completely suppressing most of the time might not be the
right call
fantasai: suppose you have clamp that's large and you are fragmenting?
fantasai: there you'd want widows to take effect
andreubotella: Question of whether line-clamp container should
fragment. It's very buggy and non-interop in browsers.
andreubotella: If we allow these containers to fragment, then
probably continue:discard, rather than block effects
of this property, it should say that they don't apply
for setting the region break
florian: Ok, my earlier pref for setting to 1 rather than ignoring,
is not an objection. I'm now on the fence, see arguments
both ways.
florian: Long-term, if we really need an opt-in, we can create one.
astearns: Let's go with andreubotella's suggestion for now. It's the
least we can do to fix this particular issue.
astearns: We can make that interaction more complicated in the future
if we need to
PROPOSED: The region break set by line-clamp ignores widows/orphans
RESOLVED: The region break set by line-clamp ignores widows/orphans
How do empty blocks affect line-clamping by height?
---------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/12663
andreubotella: Split off from a previous discussion on abspos and
stuff.
andreubotella: When clamping by height, the last possible clamp point
that doesn't overflow is chosen.
andreubotella: If you have a block element that has no content, it
would clamp after it.
andreubotella: That's probably fine, except it means that if there's
a line before that empty block, it will not be
ellipsized.
andreubotella: The presence or absence of that block before/after
clamp point, if that block is empty it doesn't matter.
But if the block has position:relative, and contains
an abspos, it does matter because it affects whether
abspos is hidden or shown
andreubotella: this can also affect boxes that have non-zero content,
but height set to zero
andreubotella: In those cases, the content of the box would also be
shown or not shown depending.
andreubotella: I think it makes sense to clamp after zero-height
boxes. Find the last possible clamp point before the
height overflows
florian: Main downside is because last thing before clamp point isn't
the line, we don't see the ellipsis
florian: Although in case of zero height *and* content, ellipsis
would be seen on that content.
florian: but I guess it's ok, don't put empty <div>s where you don't
need them.
andreubotella: If you have a box which is zero-height, but does have
content (whether overflowing or abspos), you probably
don't want the ellipsis to be placed on the previous
line
andreubotella: should we depend on that?
fantasai: if you have a paragraph and then a block that's a
horizontal rule
fantasai: do you want that paragraph to be ellipsised?
andreubotella: Currently it's not
andreubotella: block-ellipsis applies to the last line before clamp
point if only thing in between are abspos or end of
element
fantasai: is that the behavior you want?
florian: We discussed earlier, and resolved on this behavior given no
perfect solution.
andreubotella: For some use cases you might want it, and for others
you might not.
andreubotella: If you have a line, and then an independent formatting
context, you don't want the line before it to have the
ellipsis
astearns: So proposed resolution is no special handling for
zero-height or empty blocks?
fantasai: could we just say the kinds of blocks that inhibit margin
collapsing…
florian: Are you saying we should lean more on
margin-collapsing-through??
astearns: Could close no change and then explore later
florian: It's not interaction with margin-collapsing, it's trying to
identify which blocks we consider and those we don't
fantasai: No special handling, if people complain we'll reconsider
PROPOSED: Close no change until/unless users complain.
RESOLVED: Close no change until/unless users complain.
Floats and line-clamp
---------------------
github: https://github.com/w3c/csswg-drafts/issues/12665
andreubotella: For continue:collapse, definition says if block
container contains a clamp point, automatic size will
not take into account the content after the clamp point
andreubotella: What does that mean for the line clamp container? It
is an independent formatting context, so it is subject
to float clearance
andreubotella: If you have a float that is not hidden, it will add
clearance to the line clamp container
andreubotella: This is not always what authors expect
andreubotella: In this case, changing webkit-line-clamp to lines 3 or
4, it means float would make the box taller than you
would expect by the lines
andreubotella: but if you're clamping by height, the moment you reach
the end of the float and you try to push the height
upwards, then you would be clamping up to the line
before the float
andreubotella: the float is anchored to line 3
andreubotella: I like the consistency with regular sizing, but this
is not intuitive
andreubotella: It is also different from behavior you would get with
continue:discard, because the float would fragment
florian: Behavior is surprising, but consistent and explainable
florian: If we try to do better, might be able to say that a float
that grows the box by adding clearance is treated as
invisible, and you remove the float
florian: Don't remove floats in general, because they can cause
content to wrap differently
florian: but if it's increasing height of container, then remove it
florian: but then that would change the wrapping of earlier lines...
florian: so maybe put a dummy float?
florian: Anyway, current behavior is not terrible.
andreubotella: I'm worried about implementability even if it doesn't
cause lines to wrap differently
dbaron: I'm not sure how much the underlying mechanism here is
related to fragmentation
florian: meant not to
dbaron: but even if it doesn't, thinking about it analogously might
help
dbaron: The way floats fragment is not well-specified, and probably
not interoperable across engines
dbaron: but my memory of how it works in Gecko, you can push the
float to the next fragment without pushing the lines adjacent
to it
dbaron: In some cases you can also fragment the float
dbaron: that might not make sense here
dbaron: so idk how well analogy to fragmentation works
dbaron: but the other behavior I could imagine is the float goes away
at a shorter height in the first case, but lines do what you
expect simultaneously
<astearns> I think fragmenting floats is not terribly interoperable
dbaron: that said, idk how hard it is to implement
andreubotella: I worry it's not easy, but I will have to check
fantasai: I think that second case seems surprising
fantasai: if we did fragment it would be more in line with author
expectations
fantasai: where we introduce the line clamp could be treated as a
frag break
andreubotella: for continue:collapse, it doesn't work based on
fragmentation
andreubotella: it just sizes the container based on the size it would
have if you ignored the hidden content
andreubotella: and floats can be either shown or hidden
florian: So based on this, my suggestion is to close no change
florian: "we're doing collapse, but these advanced cases want
fragmentation", in that case use fragmentation
florian: But that assumes we'd actually define and implement
continue:discard.
florian: But I worry we'll end up with something as complicated as
fragmentation.
florian: [first picture is clamping by line number, second is
clamping by height]
andreubotella: Another possibility is to not include float clearance
in the sizing
andreubotella: the float would overflow the box essentially
andreubotella: That is a possibility that is easier than current
behavior. I think that's what Firefox and WebKit do
currently
andreubotella: This behavior is not what chromium does yet
fantasai: so you're saying we would size based on the in-flow
content only
fantasai: the float would clip?
fantasai: you'd want to clip it to the content edge of the box
fantasai: would be reasonable
florian: So clip at that point, without needing to specify it
fantasai: Yes. In particular to content edge, not padding edge
astearns: You're saying this is what other engines do?
andreubotella: FF and WebKit have the float overflow.
florian: That's oversimplifications. Not just overflow but
*everything* overflows and is visible, unless you make it
hidden.
astearns: Do we have a quick resolution?
PROPOSED: Floats do not increase the height of a line clamp
container. They are clipped to its content edge.
andreubotella: Comfortable with resolving this for now. Unsure how to
implement the clipping.
andreubotella: I suspect it won't be a blocker. Not opposed.
astearns: As you look into clipping to content edge, you can open up
a new issue if you come up with something that makes more
sense.
astearns: Any objections to proposed resolution?
RESOLVED: Floats do not increase the height of a line clamp
container. They are clipped to its content edge.
Received on Wednesday, 17 September 2025 23:24:48 UTC