-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-break-3] rules for direction to use when slicing inline borders for box-decoration-break:slice are unclear #4989
Comments
Good catch. I think the better behavior would be to use the |
The CSS Working Group just discussed 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 |
(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? |
If you need it for testing or creating examples, i can provide the text of the above. |
@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 |
@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?? |
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? |
The rules for joining boxes with
box-decoration-break: slice
currently say: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.)
The text was updated successfully, but these errors were encountered: