Re: [csswg-drafts] [css-text-4] add 'avoid' to text-wrap-mode (#9448)

Does an inherited `text-wrap-mode: avoid` still allow the children of an element that already avoids text wrapping to more strongly avoiding wrapping? Take the following HTML as an example, using non-inheriting `wrap-inside: avoid`, and presuming a monospace font:
```html
<span><span style="wrap-inside: avoid;">a b c d <span style="wrap-inside: avoid;">e f g</span></span> h <span style="wrap-inside: avoid;"><span style="wrap-inside: avoid;">i j k</span><span style="wrap-inside: avoid;">l m n</span> o</span></span>
```
1.  Let's start with a `max-content` width top-level `<span>`:
    ```
    a b c d e f g h i j k l m n o
    ```
2.  As we shrink the container, text has to wrap. Line breaking occurs around `h`, as the spaces around it are the only ones without `wrap-style: avoid`. First:
    ```
    a b c d e f g h
    i j k l m n o
    ```
3.  And right after, to avoid line-breaking inside `i j k l m n o`:
    ```
    a b c d e f g
    h
    i j k l m n o
    ```
4.  Next, line breaking is required inside both `a b c d e f g` and `i j k l m n o` at the same time. Line breaking occurs before `e f g` (to avoid wrapping inside that nested `wrap-style: avoid` span) and before `o`.
    ```
    a b c d
    e f g
    h
    i j k l m n
    o
    ```
5.  Line breaking is required inside `i j k l m n`, and `l m n` is `wrap-inside: avoid`:
    ```
    a b c d
    e f g
    h
    i j k
    l m n
    o
    ```
6.  There's a normal line break point before `d`:
    ```
    a b c
    d
    e f g
    h
    i j k
    l m n
    o
    ```
7. Any further reductions in width would incur word breaking or overflow.

To me, this whole process feels *very* different from `text-decoration`. We're not declaring a binary state of "underline"/"don't underline" or "allow wrapping"/"don't allow wrapping", where it both makes sense to inherit a parent's state and override a parent's state, but rather we're rather declaring box-level prioritization in the line-breaking process. You could view this like `font-size` if you wanted to think about calculated root-relative wrap priorities, e.g. `<span style="wrap-inside-relative-badness: 0.5;">a b</span> c d <span style="wrap-inside-relative-badness: 2;">e f</span>` to eagerly wrap between `a` & `b` (the least bad valid line break point) and avoid wrapping between `e` & `f` (the most bad valid line break point), but that's still a non-inherited property. (Side note: `nowrap` is like infinite badness. It's equivalent if you never break at an infinitely bad break point.) I don't know what the equivalent of `white-space: normal` is for a child of a box with `wrap-inside: avoid` is, besides something like `<span style="wrap-inside-relative-priority: 0.5;"><span style="wrap-inside-relative-priority: 2;">…</span></span>`. If you can reverse the `text-wrap-mode: avoid` of an outer box with `text-wrap-mode: wrap` on an inner box, then that suggests to me that `<span style="text-wrap-mode: avoid;"><span style="wrap-inside: avoid;">…</span></span>` *shouldn't* cause the nesting behavior specified for `wrap-after: avoid`, and that makes `text-wrap-mode: avoid` much less useful, at least to me. I'd love a composable way to discourage wrapping inside CSS.

Additionally, `wrap-inside: avoid` parallels `wrap-before: avoid`. If `text-wrap-mode: avoid` is used, there should also be a `flex-wrap-mode: avoid` to parallel `wrap-before: avoid-flex`.

Also, something I'm not sure about from the current `wrap-inside: avoid` language of «If boxes with [avoid](https://drafts.csswg.org/css-text-4/#valdef-wrap-inside-avoid) are nested and the UA must break within these boxes, a break in an outer box must be used before a break within an inner box may be used.»: if a break has already occurred in an outer box, and a break is used within an inner box, may that outer break be collapsed/reversed if there's space? For example, could 4. from above be rendered as the following, where the line break between `e f g` and `h` is undone due to available space? This does cause a rendered output where the inner `a b c d e f g` box still uses a break while the valid break point after `a b c d e f g` in the outer box isn't used.
```
a b c d
e f g h
i j k l m n
o
```

-- 
GitHub Notification of comment by bb010g
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9448#issuecomment-1857718566 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 15 December 2023 11:24:38 UTC