- From: Andy Earnshaw via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Sep 2022 08:23:44 +0000
- To: public-css-archive@w3.org
andyearnshaw has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-overflow] block-ellipsis rules don't match text-overflow rules == The [spec text for `text-overflow`](https://www.w3.org/TR/css-overflow-3/#text-overflow) says: > For the ellipsis value implementations must hide characters and [atomic inline-level elements](https://www.w3.org/TR/CSS2/visuren.html#inline-boxes) at the [end](https://www.w3.org/TR/css-writing-modes-4/#end) edge of the line as necessary to fit the ellipsis, and place the ellipsis immediately adjacent to the end edge of the remaining inline content. The first character or [atomic inline-level element](https://www.w3.org/TR/CSS2/visuren.html#inline-boxes) on a line must be clipped rather than ellipsed. Whereas for `block-ellipsis`, the [spec text](https://www.w3.org/TR/css-overflow-3/#block-ellipsis) says > This inline is assigned [unicode-bidi: plaintext](https://www.w3.org/TR/css-writing-modes-3/#propdef-unicode-bidi) and [line-height: 0](https://www.w3.org/TR/CSS2/visudet.html#propdef-line-height) and is placed in the line box after the last [soft wrap opportunity](https://www.w3.org/TR/css-text-3/#soft-wrap-opportunity) (see [[CSS-TEXT-3]](https://www.w3.org/TR/css-overflow-3/#biblio-css-text-3)) that would still allow the entire block overflow ellipsis to fit on the line. As far as I understand, a soft-wrap opportunity usually means a hyphen, space or some other non-alphanumeric character depending on the language. The 'last soft wrap oppurtunity' could appear quite early on in the line of text. This matches the behaviour of `-webkit-line-clamp`. We're using `-webkit-line-clamp` on our data tables, where the browser supports it. Our row heights are configurable, so there could be one or more lines of text. This has led to a current customer issue where email addresses with hyphens are clipped very early, leaving a lot of space in the cell:  Our plan to work around this is to use `line-break: anywhere` when we set `-webkit-line-clamp: 1`. However, this only solves the issue for single-lines of text. Wherever we have multiple lines, we'll hit the same issue:  Ideally, we want to wrap text suitably so that it is readable, but still show as much text as possible on the last line before the ellipsis is inserted, the same as `text-overflow`. This maximises the amount of information the user will see and may mean they don't need to resize the row or column. We also want to be able to use the same CSS, regardless of whether the number of lines of text is 1, 10 or 100, otherwise we need a JavaScript solution (like the one we have at the moment) that relies on forced reflows to do the calculations. No browsers have implemented `block-ellipsis` yet, so I'm hoping that it's not too late to have this discussion. Is it something that has come up before? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7811 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 September 2022 08:23:45 UTC