- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 24 Apr 2024 19:11:30 -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.
=========================================
+++Text Breakout+++
CSS Overflow
------------
- RESOLVED: Start work on middle ellipsis in css-overflow-4 (Issue
#3937: Ellipsizing of text in middle of string)
CSS Text
--------
- RESOLVED: Number of lines can change if it's 6+ lines being
balanced, and note that this is about line breaks not
content height shifts (Issue #10186: Should
text-wrap-style:balance be allowed to affect the block
height?)
CSS Text & Overflow
-------------------
- RESOLVED: Clamp, then balance (Issue #9310: Interaction of
`text-wrap: balance` and `(-webkit-)line-clamp`)
CSS Ruby
--------
- The group was poised to resolve on the proposal
( https://github.com/w3c/csswg-drafts/issues/10073#issuecomment-1995455391
)
within issue #10073 (Breaks within implicit bases is not
Web-compatible). However, there were concerns about performance
and not enough time to address them so discussion will return to
the issue.
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Apr/0005.html
Present:
David Baron
Andreu Botella
Emilio Cobos Álvarez
Elika Etemad
Daniel Holbert
Jonathan Kew
Roman Komarov
Chris Lilley
Florian Rivoal
Alan Stearns
Sebastian Zartner
Chair: astearns
Scribe: fantasai
Scribe's scribe: dbaron
+++Text Breakout+++
CSS Overflow
============
Ellipsizing of text in middle of string
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3937
SebastianZ: Longstanding thing I proposed 10 years ago, a way to crop
content of an element in the middle instead of at the
beginning or end
SebastianZ: proposal went through some iterations
SebastianZ: current idea is to make text-overflow a shorthand and
introduce text-overflow-handling and
text-overflow-position
<SebastianZ> https://github.com/w3c/csswg-drafts/issues/3937#issuecomment-1624382903
text-overflow = <'text-overflow-handling'> ||
<'text-overflow-position'>
text-overflow-handling = auto | [ clip | ellipsis | <string> |
fade | <fade()> ]{1,2}
text-overflow-position = [ start || end ] | middle
SebastianZ: We cover the current behaviors, plus cropping
SebastianZ: Also outlined rudimentary algorithm later on
SebastianZ: Anyone on the call have comments?
florian: My main concern here is the handling of bidi
florian: In general, just like in start/end of line, should do visual
cropping not logical
florian: logical cropping is going to be having some strange questions
florian: In generalized case, including bidi, makes me worry
florian: because when you chop start/end, clear what happens, but if
you crop middle you have to move the other parts
florian: suspect it's more complex than we wish
kizu: I don't have any opinion on bidi, but ellipsing in the middle
is something I've wanted for more than 10 years
kizu: Last time, there was concern about not allowing clipping in the
middle
kizu: but still good way to do it, if it's exactly in the middle then
author can position something interesting there
kizu: but this will require browser to know
kizu: Other than that, lots of people want this
kizu: idk if in this issue or other, if we need an ellipsis in
multiline
kizu: in our product we need this, but should discuss separately
kizu: but for single-line, a lot of use cases
jfkthame: I still disagree with Florian that visual ellipsizing in
the middle is the right approach for bidi
jfkthame: In most cases, the most important content will be the
beginning of the text and/or the end of the text logically
speaking
jfkthame: so those pieces should be preserved
jfkthame: I wonder if, given the complexity/uncertainty, is define
middle as a feature but leave the behavior of bidi cases
for browsers to experiment with initially
jfkthame: until we see what works in real-world use case
<SebastianZ> +1 to what Jonathan said.
fantasai: I think this makes sense -- the question is whether there's
implementor interest. If so, we should spec it.
astearns: Do you want to gate specifying on implementor interest? Or
should we start it, mark it at risk, and work on spec in
parallel?
florian: In this case, I think yes
florian: We agree that this is hard, and we don't know enough to
spec it
florian: so even if we did spec it, we wouldn't be able to get
interop-level detail
astearns: Even if there's open questions, the majority of use cases
aren't bidi
astearns: it's something devs need and have a use for
andreubotella: Chromium has an implementation of ellipsis in the
middle that they use for file selection
andreubotella: I don't know what it does wrt bidi, but they have an
implementation
florian: Even if not bidi, there's still ambiguity wrt visual or
logical middle
florian: if non-monospace font, where is the middle?
florian: Effect of disagreeing will be less dramatic, but still will
have disagreement
florian: but maybe useful enough to spec
florian: Would prefer to wait until interest, but not an objection
SebastianZ: There was at some point an implementation in XUL
SebastianZ: but they removed it at some point
dholbert: We replaced it with another hack based on HTML+CSS
dholbert: We have something, but idk how good it is. Similar to
Chromium
astearns: Given that there does appear to be something implemented,
is that enough?
fantasai: Can't speak for Apple, but doubt we'd object
jfkthame: Unsure when we'd get to it, but some interest
jfkthame: We know that what we've got doesn't handle i18n well
jfkthame: and partly lack of a spec has discouraged us from being
more thorough about integrating with CSS
astearns: I'm inclined to resolve that we start the spec of this,
knowing it will be complicated, and it may take awhile
florian: Do we start with SebastianZ's proposal of two longhands?
astearns: Seems like a good place to start
fantasai: Probably need to bikeshed -handling at some point
astearns: Proposed to start?
RESOLVED: Start work on middle ellipsis in css-overflow-4
CSS Text
========
text-autospace: what gets copied?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/8511
florian: Current recommendation from i18n is to just copy the source
florian: Elika does point out there might be more nuance, because in
CJK it adds spacing but doesn't add space characters (but
can remove them)
florian: whereas in other cases, it can insert actual characters
florian: unsure if this was considered well enough
florian: maybe we should chat with i18n for that last point first,
and come back
Should text-wrap-style:balance be allowed to affect the block height?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10186
jfkthame: Came up as I was fixing a bug
jfkthame: Spec requires that text-wrap: balance doesn't change the
number of lines
jfkthame: though an author might expect it doesn't affect the overall
size of the block
jfkthame: I wondered if that was a correct expectation, or whether
it's OK for it to alter the block height
jfkthame: currently that's a constraint in Firefox
florian: In Firefox, is that constraint generally observed or always?
Complicated wrt floats etc.
jfkthame: Always
fantasai: When we wrote the spec it wasn't about wanting to restrict
the height -- it was about the general case of not wanting
the 2 line heading to become a 3 line heading because you
turned on text-wrap:balance
fantasai: since then it's been brought up about balancing a larger
number of lines, e.g., 20-30 or more. At that point you
might not care if a line is added/removed if you balance
the text.
astearns: We have a current limit at 10, implementations may be more
restrictive
fantasai: Not required to do more than 10, but can
fantasai: I don't think we should restrict effects on the block
height. Changing the way text wraps can change the height
of the lines. Maintaining a stable height wasn't
particularly the goal of the feature.
fantasai: Instead, we should say for a small number of lines (e.g.,
< 8) then the restriction should stay, but for more than
that (between 6 and 10) the number of lines can change.
fantasai: Trying not to change it but might shift by 1 or 2 lines.
Enables some faster algorithms which might make larger
numbers of lines more possible.
florian: Agree with fantasai, also curious about firefox
florian: Did you implement this way for a specific reason?
jfkthame: It was fallout from fixing a different bug
jfkthame: That ended up with ensuring that the height doesn't change,
that wasn't a specific demand
florian: In that case, the current definition is maybe too specific
about precisely how much balancing is the right amount
florian: Maybe we shouldn't require the the Firefox behavior, but
allow some amount of discretion
florian: might want to balance other considerations
astearns: The method to evaluate whether to evaluate whether
something is more balanced
astearns: it's not "you must achieve this", but if you hadn't done
this then the line breaks you're considering are not more
balanced
astearns: Seems we could resolve on loosening the requirement on
changing number of lines if number of lines balancing is a
larger number
astearns: maybe other things fall out from that
<dbaron> (and is it clear that the requirement is about "number of
lines" rather than about "height")
florian: If we don't require FF behavior, should make that clear
fantasai: If we change it so the # of lines is possible to change
that will be more obvious
astearns: Might still be worth clarifying
astearns: Proposed that we relax the restriction on changing the
number of lines, and clarify it's only about number of line
breaks not resulting height
[discussing what's the limit]
PROPOSED: Number of lines can change if it's more than 6-ish lines
being balanced
RESOLVED: Number of lines can change if it's 6+ lines being balanced,
and note that this is about line breaks not content height
shifts
CSS Text & Overflow
===================
Interaction of `text-wrap: balance` and `(-webkit-)line-clamp`
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9310
florian: Do we clamp first and then balance, or balance first and
then clamp?
florian: Dominant view in the issue is clamp first, then balance
florian: but jfkthame points out that if you animate the height, this
could be a lot of rebalancing
florian: which is weird
jfkthame: The current safari tech preview seems to do balance and
then clamp behavior
jfkthame: opposite of Blink
fantasai: If we want both behaviors, we could change based on
'will-change'
fantasai: Could clamp-then-balance if it doesn't have 'will-change',
and vice-versa
florian: The fewer additional corner cases we add for fragmentation
etc the better it is for later
astearns: I'm convinced that people want both. In case where you're
not animating, if you do it one way it looks like balance
doesn't do anything
astearns: and in other case, animating is bad
florian: Animatable way seems complicated in general case. With
simple version of line-clamp probably alright
florian: Assume part after laid out same as before
florian: but if we have `continue: fragment`, the next fragment might
be a different width
florian: I'm not even sure if you move the clamping point between
containers of different widths before you clamp, what does
that mean?
[balancing independently before/after line breaks or page breaks]
fantasai: It's a little bit not what 'will-change' was designed for.
[in response to astearns asking why fantasai was laughing when
suggesting the switch]
kizu: This seems like a rare enough use case... for authors if the
animation is fast enough you won't notice
kizu: and can otherwise work around it
kizu: will-change suggestion is kinda weird, maybe better to use a
dedicated switch
florian: Agree this is a rare case. not that revealing progressively
is not rare, but on something that has balance seems rare.
For headlines etc.
florian: so my inclination is to start by clamp then balance, and if
we need an opt in later we worry how it works then
astearns: Given that jfkthame's test results consider this a change
in WebKit, is that Ok with WebKit?
<dbaron> I agree with Florian that it's a rare case and we should
pick something and not add switches.
fantasai: Seems reasonable to try, since it seems that would be
desired by authors.
RESOLVED: Clamp, then balance
CSS Ruby
========
Breaks within implicit bases is not Web-compatible
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10073
fantasai: In suggested UA style sheet, we had rb { white-space:
nowrap}. Most ruby bases don't have an rb element for
reasons that I disapprove of, but it's where we're at.
fantasai: We wanted to allow bases to wrap... so we don't want to
forbid wrapping within bases entirely with no way to change
it.
fantasai: There are different approaches we could take to solve this.
fantasai: One is to have the UA apply text-wrap-mode to anonymous...
but if we did that author wouldn't be able to allow
wrapping.
fantasai: We could say anonymous ruby bases have text-wrap-mode:
nowrap on them, and if author wants to wrap the base they
could use an rb or a span.
fantasai: Another option is to have a pseudo-element for anonymous
ruby bases.
florian: If a pseudo, then all ruby bases whether anonymous or not
fantasai: Or that
fantasai: Third option, have white-space: normal compute to nowrap on
ruby bases and magically inherit that way. So unless you
explicitly set it to something else it will be nowrap.
1. apply `text-wrap-mode: nowrap` to anonymous bases
2. add a ::ruby-base pseudo-element and apply it that way
3. make `white-space: normal` compute to `nowrap` on ruby bases
florian: I think a pseudo-element would be overkill
florian: if just for this use case
florian: so first option would make sense
florian: but there are other use cases for a ruby base pseudo-element
florian: so maybe we get one later; but that's complicated so
wouldn't start there
<emilio> I think that's the simplest approach
dbaron: I also lean towards the first proposal
dbaron: The one other thought is, I'm concerned about making
pseudo-element apply to all ruby bases whether anonymous
or not
dbaron: As of right now we don't have a pseudo-element that also
matches real elements
dbaron: There are some proposals that might take us down this path,
but it's got some interesting issues and wouldn't want to go
down this path without thinking about it carefully first
florian: Fair enough
astearns: Sounds like we're converging on 1st option
astearns: Personally concerned about that, because we're dictating
styling that you can only change by changing your markup
astearns: which seems like the wrong path
astearns: Should have a way to override the thing we're applying to
the anonymous bases
astearns: but if people want that, we could add the pseudo element
florian: That said, you're not changing your markup to something
unrelated, if you elide markup you have fewer things to style
fantasai: Two points:
fantasai: One, the suggestion about computing text-wrap-mode
differently... we'd make text-wrap-mode: normal | wrap |
no-wrap
fantasai: normal would be the initial value and mean wrap except for
a ruby base
fantasai: so if you wanted to style it differently you could set
text-wrap-mode: wrap on the ruby element
fantasai: Second, we wouldn't have this problem if html parsers
injected rb tags into ruby, which they should have done,
and I'm still annoyed about that.
florian: Is that still fixable?
fantasai: I don't know. We'd have to analyze existing content to see
what kinds of selectors are being used.
fantasai: If people are using child selectors in combination with
ruby, those could break
fantasai: I don't expect people to do that unless they're doing
something fancy with rp
dbaron: It feels less costly to do a pseudo-element than to do the
extra value of text-wrap-mode
dbaron: so given choice between those two, I would lean towards
pseudo-element
fantasai: Implementation cost aside, agree it's a lower cost to
authors, since they only encounter the complication if
they're working in ruby (which is highly specialized)
emilio: Analogy with table parts is good, if you wanted you can just
write it
fantasai: Tables inject tbody even if you don't write it
emilio: I mean, if you set 'display: table-cell' on a random element
no way to style the table
emilio: I agree with styling the anonymous boxes, it's consistent
florian: And also it's compatible with extending to introduce a
pseudo-element
florian: and it's also compatible with fixing the HTML parsing, if
we're ever able to do that
PROPOSED: Adopt `text-wrap-mode: nowrap` styling to anonymous ruby
bases
<fantasai> ruby > :not(rb, rbc, rtc, ruby) { text-wrap-mode: nowrap; }
fantasai: We'd have to add this rule also, because real elements
can't inherit from anonymous
dbaron: A bit concerned about that selector because it looks
expensive from performance perspective ... unsure for current
engines
dbaron: I don't know if will require parent of every element
emilio: That rule is not great
RESOLVED: Style anonymous bases with text-wrap-mode: nowrap as
described in
https://github.com/w3c/csswg-drafts/issues/10073#issuecomment-1995455391
<dbaron> (I'm a little worried the 2 things are tied together and we
may need to reconsider.)
emilio: Regarding performance, it's probably not as terrible as it
used to be, but only probabilistic filtering
emilio: overall I don't think it's great
emilio: Can we set nowrap on the ruby element itself?
fantasai: Ruby itself needs to be able to wrap
emilio: Can we explicitly list stuff?
florian: All possible inline elements?
astearns: Can it be magic?
emilio: Not really great...
astearns: Ok, out of time. Can either leave open or resolve to add it
and then work through the perf concerns.
astearns: What's the preference?
dbaron: Lean towards leaving it open
RESOLVED: unresolve previous resolution
Received on Wednesday, 24 April 2024 23:12:02 UTC