[css-break-3] rules for direction to use when slicing inline borders for box-decoration-break:slice are unclear

[dbaron]

The rules for joining boxes with box-decoration-break: slice currently say:

For boxes broken across lines
First, fragments on the same line are connected in visual order. Then, fragments on subsequent lines are ordered according to the element’s inline base direction and aligned on the element’s dominant baseline. For example, in a left-to-right containing block (direction is ltr), the first fragment is the leftmost fragment on the first line and fragments from subsequent lines are put to the right of it. In a right-to-left containing block, the first fragment is the rightmost on the first line and subsequent fragments are put to the left of it.

The normative text seems to say that it's the inline element's own direction, but the examples both refer to the containing block's direction. It should be clear which one is used.

(I got here as part of filing Mozilla bug 1632228.)

[fantasai]

Good catch. I think the better behavior would be to use the direction of the element (rather than the containing block) when joining fragments split across lines. Then, for example, if you have a gradient from the start to the end of the box, it will increase in parallel with progress through the text.

[css-meeting-bot]

The CSS Working Group just discussed which direction to use when slicing inline borders/backgrounds.

The full IRC log of that discussion

<fantasai> Topic: which direction to use when slicing inline borders/backgrounds
<astearns> github: https://github.com//issues/4989
<fremy> dbaron said the rules for box-decor-break slice are not clear
<fremy> fantasai: but the spec is not clear on which direction you should use for the splicing
<fremy> fantasai: either the inline element itself
<fremy> fantasai: or the parent block
<fremy> fantasai: and I would suggest to use the inline
<fremy> fantasai: for example if you used a rainbow gradient it should splice in the direction of the element
<Rossen_> q?
<fremy> florian: I am curious about what the alternative would do
<fremy> florian: but I agree that what you described sounds like the right solution
<florian> s/curious/confused/
<fremy> Rossen_: ok sounds reasonable
<fremy> Rossen_: any objection to resolve this?
<fremy> Rossen_: (repeats r12a question on irc)
<fremy> r12a: if you add unicode ?conference? you can move to the next line, not unicode
<fremy> r12a: and in this case it would not to that in terms of what the text actually does
<fremy> r12a: but in terms of rendering maybe it does
<fremy> florian: for the border, you want the side that is the side on the end of the line to be open
<fremy> florian: but that doesn't match what we just discussed with the background
<fremy> r12a: yes, we should probably look at a few examples
<fremy> r12a: I can provide examples if the group wants
<fremy> Rossen_: that sounds great
<fremy> Rossen_: (the examples)
<fremy> Rossen_: fantasai does that change your mind?
<r12a> https://r12a.github.io/scripts/tutorial/part5#latin-in-rtl
<fremy> fantasai: yes, let's take another look after we considred all the examples
<fremy> Rossen_: ok, if the examples don't break everything (no pun intended) we will resolve what we decided
<fremy> Rossen_: but otherwise we will rediscuss

[r12a]

(Generally, i think it would be helpful to have more diagrams here – at least one for inline text broken across lines.)

I wanted to check what happens when a line break occurs inside a LTR sequence of words that is embedded in a RTL paragraph. Here is an example from https://r12a.github.io/scripts/tutorial/part5#latin-in-rtl

Note how 'Unicode Conference' (which would have 'Unicode' on the left normally, remains on the first line when rearranged around the line break. This seems to suggest to me that it's the parent's directionality that needs to be taken into account, rather than the direction of the inline element.

I'd personally expect (though we may want to check with native speakers) to see

become

even though the 'U' was originally against a vertical line.

Do we need to change anything here to make this work right?

[r12a]

If you need it for testing or creating examples, i can provide the text of the above.

[frivoal]

@r12a my intuition about what should happen to a border in this situation matches what you described, so so far I'm happy.

However, I'm terribly confused as to what ought to happen if the inline element had a background. Say that before fragmentation, it had a background gradient going from cyan under the U of Unicode to pink under the last e of Conference. What would you expect to see what it's broken into two lines with box-decoration-break: slice? What if the background was a long rightwards arrow, or something photo realistic, does that make a difference?

[r12a]

@frivoal, indeed. My picture was just an example, and i was expecting that the question would get more complicated when talking about backgrounds. I don't know the answers, and could see a case for the directionality of the backgrounds following the text but also for the backgrounds to follow the overall direction of the paragraph – depending on the nature of the background. Perhaps the properties need to make that clear??

[xfq]

It feels a bit like the problem here (but not exactly the same, because there is no fragmentation or line break in the html-bidi example): https://www.w3.org/TR/html-bidi/#image-flip

I wonder if it's possible to solve this issue by recommending the author to specify a directionality for the background gradient/image?