Re: [csswg-drafts] [css-overflow] Consider support for multiple-line ellipsis

A few comments on the [block-overflow](https://drafts.csswg.org/css-overflow-3/#block-ellipsis) spec (in the order of the text):
> clip
>     The content is not altered. 

I'd suggest "The rendering is unaffected." instead. (Some people might read "content" as "DOM" which might give them the wrong idea that the other property values modify the DOM).

> If there is no next fragmentation container and thus the remainder of the content after the break would be discarded, then the UA may visually replace the contents of the line, as it does for text-overflow.

I think this "may" should be changed to a "must", or alternatively, the entire sentence be removed.  I don't see any upsides to allowing UAs to have  incompatible behavior for this common case.

> [...] and the block overflow ellipsis inserted and laid out exactly as if it were part of the in-flow contents of the line.

Does the inserted text affect `::first-letter/::first-line` in any way?  (even if it doesn't, it'd be good to spell that out explicitly for clarity)

> The means of breaking any resulting cycles is up to the UA.

Again, vague spec text like this will likely lead to incompatible behavior in different UAs. I'd prefer the spec to say something concrete about how to solve it and make that behavior mandatory.

> If the block overflow ellipsis is too long to fit in the line, the result is undefined. (The UA may, for example, treat the block overflow ellipsis as an unbreakable string, or it may lay out the string across more than one line, replacing content in earlier lines as well.)

Again, this is too lenient IMO.  The spec should say exactly how to handle this case and make that mandatory. Authors deserve to have compatible rendering across compliant UAs.



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

Received on Sunday, 11 March 2018 19:49:38 UTC