[css-break] Consider adding clone-most-nested

[nigelmegitt]

box-decoration-break offers the options: "slice" and "clone". Neither of those allows for cloning the decoration as it applies at the point where the break occurs, e.g. the background-color of a nested <span> element within whose text the break occurs.

A proposal has been made for the semantically identical tts:inlineAreaBreak style attribute in TTML2 to add a new keyword "cloneMostNested" to fulfil this requirement - the equivalent non-Camel case value in CSS would likely be "clone-most-nested".

Please consider adding "clone-most-nested" with this semantic.

[fantasai]

Thanks for filing the issue! Question to you... should it clone the most nested, or the most nested that has something to clone?

[nigelmegitt]

That's a good question! My feeling is that "the most nested that has something to clone" is a little hard to define so my instinct is to go with "the most nested", and consider adding a different keyword later should the subtler functionality be needed. However instinct isn't the best decider - I will check back with TTWG on this point.

Also want to mention @skynavga to alert him to this issue - he may have a direct answer here.

[css-meeting-bot]

The CSS Working Group just discussed CSS Break.

The full IRC log of that discussion

<fantasai> Topic: CSS Break
<TabAtkins> ScribeNick: TabAtkins
<TabAtkins> fantasai: We had a request from Nigel to add a value for the box-decoratio-break property. CAn you explain?
<fantasai> github: https://github.com//issues/1633
<TabAtkins> nigel: IMagine you're displaying subtitles, and for a11y you want to put a high-contrast background behind the text. Not on the whole <p>, just behind the lines.
<TabAtkins> nigel: You don't want the bg to be tightly wrapped to the text edges - you want it to extend slightly out for readability
<TabAtkins> nigel: But you cant predict the linebreaks.
<TabAtkins> nigel: That's okay righ tnow with b-d-b: clone
<TabAtkins> nigel: But then what if you have a span in the middle of the text with a different color bg.
<TabAtkins> nigel: And the break falls in the middle of that other span.
<TabAtkins> nigel: You want the span's bg to be what extends; you want to use padding to display that.
<TabAtkins> nigel: So the most relevant bg color to "extend" is from the innermost element at the break, not the element that sets b-d-b.
<TabAtkins> nigel: fantasai asked a good question.
<TabAtkins> nigel: Should it be "most nested" or "most nested thing that *counts", paraphrasing.
<TabAtkins> fantasai: I think we have this problem generally with fragmentation.
<TabAtkins> fantasai: At the break, you want to ahve a little bit of extra padding with the bg beneath it.
<TabAtkins> fantasai: It's possible that maybe we can solve this by just saying "add this amount of padding at the break".
<TabAtkins> fantasai: Whether that solves this is, do you need borders too? Or just backgrounds.
<TabAtkins> fantasai: Like a border around the inline that only closes if it's the innermost nested border?
<TabAtkins> fantasai: Seems weird, I guess not.
<TabAtkins> nigel: I think for border-radius you want [...]?
<TabAtkins> fantasai: If both have b-r; normally we'd just slice and get the green and black backgrounds overlapping eachother on a clean break.
<TabAtkins> fantasai: If only the green gets a border-radius, you'll see the black background peeking out from under the green.
<TabAtkins> fantasai: That's a problem.
<TabAtkins> Rossen: I think this is in conjuction with the line-padding property in TTML, right?
<TabAtkins> nigel: Yeah.
<dbaron> a general 'break-padding' property sounds like it could be useful...
<TabAtkins> Rossen: box decoration and fragmentation, you're talking about linebreaking, nto general box breaking
<TabAtkins> TabAtkins: It can be about boxes too.
<astearns> I think it would be helpful to have a diagram in https://www.w3.org/TR/ttml2/#style-attribute-inlineAreaBreak that showed a rendering using each value for cases where there's a difference
<TabAtkins> Rossen: Sure, but that's not his requirement.
<TabAtkins> Rossen: Also something we don't have in CSS is line-padding that extends in every break.
<fantasai> dbaron, yeah, that's what I was thinking. But it doesn't solve the border-radius case he was describing
<TabAtkins> nigel: Line padding was introduced to IMSC when border-radius wasn't available in TTML; at that point the only styling you could do was bg-color and get a square box.
<TabAtkins> nigel: Now with b-r it's gotten more complicated, and probably need to extend it a little further than just the line-padding semantic, to include the other bg effects (or things that otherwise affect the background)
<TabAtkins> nigel: Your point about targeting line areas specifcially is well made.
<TabAtkins> nigel: If there was a way to say "for each line in this <p>, apply this styling" that would be really helpful, but that doesn't seem to exist yet.
<TabAtkins> fantasai: I think it would be relatively easy to describe as only things that work are background and things on the box, not background.
<Rossen> Here's nigel's example https://github.com/w3c/imsc-tests/blob/master/imsc1/png/linePadding2/0.000000.png
<TabAtkins> fantasai: Once inheritance applies it's hard.
<TabAtkins> fantasai: We have this problem with ::first-line; it's a mess, lots of bugs, spec isn't precise enough despite our efforts.
<TabAtkins> fantasai: But if it's just about "background here, put a b-r on it", it's not too hard.
<TabAtkins> fantasai: Not high prio to do in browsers, but wouldn't be too hard.
<TabAtkins> iank_: We don't have an architecture that can support that (styling lines individually). It's several years away.
<TabAtkins> Rossen: The existing model of line boxes in most impls, certainly in Edge, is not easily extdendable to support this. Not impossible, but it would be quite hard.
<TabAtkins> Rossen: Tho this is a valid use-case and feature.
<TabAtkins> fantasai: What's line-padding?
<TabAtkins> Rossen: Imagine you have a span - I posted on of Nigel's examples - that adds bg to the current inline. And the span breaks. You can put padding on the span - you'll get padding at the start and end of the span. If it fits on one line, great; the bg will extend a little past the text.
<TabAtkins> Rossen: But if the text breaks in the middle, you have some padding on start of first fragment and end of last fragment, but all other broken edges have no padding.
<TabAtkins> Rossen: line-padding feature adds padding to every break-edge.
<TabAtkins> Rossen: Basically to the linebox itself.
<TabAtkins> Rossen: if the linebox has background, it extends.
<TabAtkins> fantasai: The linebox is wider than that actually, but I get what you're saying.
<TabAtkins> fantasai: Taht makes sense, and I see how adding border-radius would be tricky.
<TabAtkins> nigel: Doing just the inline-padding isn't the only place we want to do something with line areas.
<TabAtkins> nigel: Another feature, fill-line-gap, says "draw background areas between lines".
<TabAtkins> nigel: Hard now, because character heights are UA-dependent.
<TabAtkins> nigel: So can't specify a padding-top/bottom that correctly fills in the space between lines.
<TabAtkins> fantasai: Question I have - you ahve a line of text with some line-spacing, say 1.5. You're seeing there's a bg below the text, and a .5em gap between the lines.
<TabAtkins> fantasai: When asking to fill the linegap, you're filling that .5em space, what happens at the top and the bottom? Do you add .25em at each? So each line gets .25em of bg above and below? Or just between the lines?
<TabAtkins> nigel: At the moment we don't say.
<TabAtkins> fantasai: Ok, thiat's a really important question to answer in CSS.
<TabAtkins> fantasai: Second question, if two lines have different lengths, what happens?
<Rossen> line-box-margin: collapse
<TabAtkins> nigel: Probably we take whatever answer is most convenient.
<TabAtkins> nigel: But as far as I know you can't set a padding value, because you can't calculate it...
<TabAtkins> fantasai: We should specify that...
<TabAtkins> TabAtkins: Why's it hard? Just the diff between font-size and line-height, right?
<TabAtkins> fantasai: Not quite - the bg area isnt' the size of the line box. The area around an inline - in 2.1 there were two ways to calculate the area, based on font metrics, and impls might do different things.
<TabAtkins> Rossen: This is going a bit off topic, can we bring it back to b-d-b?
<fantasai> s/line box/line height box of the inline that's used for layout/
<nigel> -> https://github.com//issues/814 [css-inline] Define the content area of inline boxes #814
<Rossen> q?
<TabAtkins> TabAtkins: So it sounds like b-d-b: inner-clone badly solves border-radius issues, and limiting it to just background is better solved with a break-padding property?
<fantasai> break-padding also causes problems with border-radius
<TabAtkins> fantasai: So I think those are the main two request from Nigel, this and figuring out the fill-the-gaps issue.
<TabAtkins> fantasai: Which I think is best done by making impls interoperable, then just using padding on the element.
<TabAtkins> fantasai: If we have a consistent box height, then having a line-height of 1.5 and a padding on inline of .25em above and below *should* fix the gap; if it doesn't, we should fix that.
<TabAtkins> fantasai: And for the other issue of cloning spaces - it seems the solution you're proposing doesn't actually solve the problem.
<TabAtkins> fantasai: It's not just "clone most nested"; if there is b-r involved, you want to spam that innermost b-r all the way up, so the lower backgrounds dont' show up underneath the topmost's b-r.
<TabAtkins> Rossen: So yeah, the feature request is something we'll work on, probably as part of Break. We'll go from there!

[atanassov]