[css-overflow-4] Clarification of text-overflow: <string> value; Rendering pipeline

[d-desiatkin]

I am working on implementation of text-overflow-4 for servo web engine.
Currently CSS specification is underspecified in rendering part of text-overlfow: <string>

1. How UA should handle bizzare symbols in user provided ellipsis string that will overflow the current linebox in block direction? (https://unicode-explorer.com/list/large , https://kai9987kai.pw/BU/Biggest%20Unicode.html)
2. Do specification really want to provide user an ability to execute animations on text ellipsis symbols? I can think of several bizzare text-ellipsis animations that will severely impact the performance of web page.

---

Illustrations for the first question.

Currently specification mentiones that clip should be applied: but I believe that this will happen only in inline direction.
Behaviour and interreaction in block direction must be additionaly specified.

Ideally we want clear definition on how such custom ellisis strings should be rendered (z-index of such elements, clip rectangles of such elements, e.t.c).

You can find the screenshot of current behaviour in mozilla.

https://www.w3.org/TR/css-overflow-4/#text-overflow

CSS

span {
border: dashed 1px;
}

.ellipsis {
border: solid 1px;
height: 100px;
width: 250px;
border: 1px solid black;
line-height: 1em;

white-space: nowrap;
overflow: auto;
text-overflow: "꧅ ꧅ ꧅𒐫 ";
}

HTML

<div class=ellipsis>
foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo <br>
foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo <br>
foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo <br>
foo foo foo foo
</div>

<div class=ellipsis><span style="position: relative; left: 20px;">
꧅ foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
</span><br><span style="position: relative; left: 20px;">
꧅ foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
</span><br><span style="position: relative; left: 20px;">
꧅ foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
</span><br><span style="position: relative; left: 20px;">
꧅ foo foo foo
</span>
</div>

Behaviour in Mozilla:

---

Illustrations of the second question

CSS

/* The animation code */
@keyframes example {
0% {text-overflow: "\E850";}
10% {text-overflow: "\E851";}
20% {text-overflow: "\E852";}
30% {text-overflow: "\E853";}
40% {text-overflow: "\E854";}
50% {text-overflow: "\E855";}
60% {text-overflow: "\E856";}
70% {text-overflow: "\E857";}
80% {text-overflow: "\E858";}
90% {text-overflow: "\E859";}
100% {text-overflow: "\e83f";}
}

span {
border: dashed 1px;
}

.ellipsis {
animation-name: example;
animation-duration: 1s;
animation-iteration-count: infinite;
border: solid 1px;
height: 100px;
width: 250px;
border: 1px solid black;
line-height: 1em;

font-family: 'Segoe MDL2 Assets';
white-space: nowrap;
overflow: auto;
text-overflow: "꧅ ꧅ ꧅𒐫";
}

HTML is the same as in the first example.

Behaviour in Mozilla:

Animations_css_text_overflow.mp4

[d-desiatkin]

Editors I invite you to discussion @dbaron @frivoal @fantasai !

[d-desiatkin]

I suggest to specifically allow only special UNICODE symbol Blocks, Sub-blocks or Categories that can be present in the string. Also all prohibited classes should be replaced by replacement character (web developer must see mistakes).

That could potentialy fix both questions. However, that not solve problems if user will use custom weird font.

We need some clear pipeline that will mention fragments and clipping operations and their behaviour in the spec

[tabatkins]

For 1, good question. The spec mainly just wants to avoid accidental inline overflow, since the ellipsis string isn't allowed to break. Block overflow isn't as much of a problem, tho. I suspect that we don't want to do any special clipping in the block axis. To me, it looks odd that Moz is clipping it to, I guess, within the line box?

The other details are all, generally, "like it was the last inline content in the block". Are there specific details of the rendering that you're concerned aren't well-defined by that, or that give bad behavior if you treat it like that?

For 2, this shouldn't be any more troublesome than animating 'content' on a ::before pseudo-element, which is currently allowed. I don't immediately see any reason to restrict it. If the author does something particularly weird, that's their fault.

[d-desiatkin]

@tabatkins Mozilla clipping ellipsis within linebox because css-overflow-4 have a requirement that ellipsis should not affect layout. That effectively means that providing ellipsis property should not modify the height of linebox and parent box element sizes.
https://www.w3.org/TR/css-overflow-4/#ellipsing-details

Right now Mozilla have the closest realization to the spec. I believe chromium realization of the feature will affect the layout

Also maybe additional clarification of "affecting layout" is required. My understanding is that changing the value of this property shouldn't trigger any relayout (layout reflows)

For 2, this shouldn't be any more troublesome than animating 'content' on a ::before pseudo-element, which is currently allowed. I don't immediately see any reason to restrict it. If the author does something particularly weird, that's their fault.

Off topic.
It is less of the issue for me. I understand that this is realized through animation keyframes and I don't need to think much about it. It is just the ideological thing, If we provide to much freedom for users we always pay for it with performance. I think that modern CSS standard allows too much. The same things could be achieved in the several ways.

In example the float in modern web could be safely replaced with Flex layout. And If we ever will deprecate floating elements browsers could win a lot on tasks parallelization on layout stage

[tabatkins]

Mozilla clipping ellipsis within linebox because css-overflow-4 have a requirement that ellipsis should not affect layout. That effectively means that providing ellipsis property should not modify the height of linebox and parent box element sizes.

Ah, that makes sense. Then yeah, more detail about clipping seems required. @frivoal @fantasai ?