[CSSWG] Minutes Text Breakout 2024-04-24 [css-overflow][css-text][css-ruby]

  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

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.


Agenda: https://lists.w3.org/Archives/Public/www-style/2024Apr/0005.html

  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
  <SebastianZ> https://github.com/w3c/csswg-drafts/issues/3937#issuecomment-1624382903
      text-overflow = <'text-overflow-handling'> ||
      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
  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
  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
  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
  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

  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

  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
  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
  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

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
  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
  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
  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 |
  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
  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
  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

  <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
  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

  <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