[css-inline] Allow background of an inline area to extend to before-and after-edges of the line area

[palemieux]

Per the 20171109 joint TTWG/CSS meeting

As illustrated at fillLineGap.pdf, a common captioning style requires the background of inline areas to extend to the before-and after-edges of the containing line area. This styling capability is not currently supported by CSS.

This capability mirrors the itts:fillLineGap styling attribute at https://www.w3.org/TR/ttml-imsc1.0.1/#itts-fillLineGap

[astearns]

@palemieux what should happen when the line boxes are actually separated (here by a float outside the paragraph)?

Is the only requirement that the background extend to the edges, or should we define it to create a contiguous background area in a case like this?

[palemieux]

@astearns What would the background look like in the illustration above with zero padding?

[astearns]

With a background on a span containing the text:

[palemieux]

@astearns Thanks! and what would be the line boxes in that example? In particular, is the after edge of the line box that contains "some" aligned with the bottom of the green square?

[astearns]

No, this is a case where line box stacking does not give a result where the before and after edges coincide. Each line box is exactly the same height - the float rules just move the second line down below the float

[palemieux]

So, in this scenario and according to the current definition, the background would not be continuous.

The result would be presumably different if the green square were inline the paragraph (instead of a float).

[nigelmegitt]

This case does not generally arise in subtitles and captions; if it did, I would expect a gap in the background areas, i.e. the rule to align the span background before and after edges with the line area before and after edges would still seem acceptable to me. The alternative might be a very large background block containing no foreground content.

To flip that around, what if someone wanted that background block to be contiguous in the block progression direction but tight to line areas in the inline progression direction? I don't see how that could sensibly be done - it's asking to align not with the current line area's before and after edges but the previous line area's after edge and the next line area's before edge. I suppose that could be another keyword option, but I'd give it lower priority.

[css-meeting-bot]

The Working Group just discussed Allow background of an inline area to extend to before-and after-edges of the line area.

The full IRC log of that discussion

Topic: Allow background of an inline area to extend to before-and after-edges of the line area
github: https://github.com//issues/1974
astearns: In this onethere is a PDF of what they'd like. There can be vertical gaps between lines that don't get a background color in CSS. They'd like to spec that hte background should be extended to be contiguous even if there's a gap like this.
TabAtkins: I don't like the magical background
fantasai: Should say it's the box.
TabAtkins: Is this related to linebox size calc proposal?
dbaron: Prob not. One questions is what to do if box is bigger then the line gap.
florian: semi-transparent you don't want transparency to pile up.
what about background-clip: line-box? :)
tantek: For borders you can do the cheap and ugly overlapping borders or the likely wanted borders around the whole thing.
astearns: My summary was insuficeient. It's also extending background on both sides to half the gap.
florian: Consistent with increasing height of inline block.
dbaron: What if there's a tall image on one line?
astearns: I asked about what if a float is in the way and they didn't care.
smfr: Feels a little like how when webkit does selection and tries to eliminate selection gaps?
TabAtkins: In float example I suspect that...it wouldn't be contiguous...first line is a little bigger but not touching. That's solved by inlines being the height of the line property.
astearns: How to accomplish this.
florian: inline height: auto and fill
florian: inline property with legacy and filled.
leaverou: line box as psuedo element?
fantasai: Wouldn't solve the problem.
leaverou: Wouldn't line height address it?
TabAtkins: Inline box sizing wrap the content reasonably tight such that line height can produce gaps.
leaverou: If there's a linebox psuedo element wouldn't they be able to set padding?
florian: pseudo element controls too many things.
fantasai: Can we pause this and switch to next issue? It's similar in the opposite axis.

[css-meeting-bot]

The Working Group just discussed Allow background of an inline area to extend to before-and after-edges of the line area, and agreed to the following resolutions:

• RESOLVED: Add a property to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.

The full IRC log of that discussion

Topic: Allow background of an inline area to extend to before-and after-edges of the line area
github: https://github.com//issues/1974
fantasai: In this case I think we need to apply to the inline.
florian: I don't know if you need to but there's no complication on it.
https://www.bloomberg.com/news/articles/2017-09-20/google-is-said-close-to-buying-htc-assets-to-bolster-hardware
koji: When talking about extending inline boxes height?
q+
fantasai: Only for painting.
Rossen: Is it?
fantasai: Yes, layout is based on line height. We don't care about padding, amrgins etc.
fremy: I put a link on IRC that's a website that tries to do this.
fremy: I think how the did it is set some padding on the line and let's you extend the background.
Rossen: They'll have overlap.
dbaron: If you choose too much you cover up text in other line.
Rossen: If you resize the window down to 3 lines you lose some of the y
fremy: I've also seen it done with box-shadow to simulate line-padding, it's a very common effect
fremy: They also used box shadow.
florian: Are we discussing a protential property that siwtches the outer content height of inline boxes to be the height of the line?
dbaron: I think border height
fantasai: Outer is margin
florian: meant border.
fantasai: Interesting thing is this is all element. What if I have superscript? I think what they would want is ou're still going from top to bottom of linebox. Amount of extra background ink [whiteboards]
fantasai: If we draw this and want to increase by x on each side, but if you have an element with different baseline you'll want to go from top to bottom of linebox. Normally when calc size of background area you're going to use the size of the contents, your font metrics.
fantasai: We're saying isntead of doing that ignore where all the text is, just find the lin box and draw from the top to the bottom.
fantasai: Should be clear regardless of the vertical positioning the background moves with the txt.
fantasai: Might be margin box you want.
dbaron: NO harm in the margin box because then it makes margin useful.
dbaron: Then you could inset some of the background.
florian: It's commonly set i nboth direction because it only does something in one.
TabAtkins: This won't be turned on by default.
florian: I guess.
dbaron: Also let's people make the border stick out by using a negative margin.
florian: Okay. I buy that.
florian: Property with normal and fill?
fantasai: Or add it as a keyword on padding property. Padding top-fill so it means make the padding such...
astearns: Then you have to do it on each direction
fantasai: We have padding-block-start.
I'd note that this does introduce negative padding, which might be interesting...
fantasai: You could say 'padding-block: fill'
on the inline
Rossen: I would the prefer this to be inline background. We can figure out what the bounds are. We don't have to implode padding or margin. It's a drawing effect. That way once we switch we can ensure there's no overlapping so when you're using semi-transparent it's always complete.
Rossen: If it's only after rendering I would prefer higher lelev. Pushing this down to lineline you'll have some times do it and it's more complex.
fantasai: Wht makes it more complex to impl? On every inline you haev to call the paint your backgrounds function.
iank_: This goes over the size of the line potentially.
fantasai: You have to handle that for line-height.
iank_: That's line-box sixe.
fantasai: If I set my line ehight ot 10 and padding on my inline box is 10 above and below I'll leak over.
florian: Rossen you're version if the middle is top green and bottom yellow how to you know it doesn't overlap.
Rossen: It doesn't. It's a simplification because it's one background behind all.
Rossen: But they want different colors. Not jsut one element.
s/rossen/fantasai
koji: smfr pointed out we do that code for selection painting. The approach is like what Rossen suggested, it's easy to impl. If we go with padding it's more complex.
fantasai: padding doesn't effect [missed]. it changes box size but not things around.
Rossen: You can have tearing or overlapping.
fantasai: You can already do the overlapping. i'm not sure how concerns about overlapping or not are valid.
florian: When you do approauch where you'r line height wasn't 20 pixels it's possible you migth get a bit of a gap inbetween. Instead of sizing each individually you can edit as one shape.
fantasai: But then what about when you do images?
myles: Our selection does it piecemeal. We're very deliberate about how we round and floor. It fills peices 1 by 1 and avoid pixel crack with careful rounding.
Rossen: If we leave to authors we'll have different rounding.
astearns: We're saying design the feature at an inline level and impl deal with stiching together with the rounding errors. And it's what TTML is asking for in the issue.
astearns: Do we follow TTML lead and call it fill-linegap?
fantasai: No.
florian: inline-box-sizing?
koji: Sizing is not right.
florian: inline-height: normal|fill
leaverou: Too much like line-height.
s/is not right/sounds like layout/
astearns: Line-extend
iank_: border-outsets
line-area?
fantasai: You're not outsetting, you could be insetting.
florian: inline-height and line-height are similar but if you're aware of both you won't be confused.
iank_: Not all webdev know all css properties.
fantasai: line-gap-fill
astearns: Pierre suggests line-box-fill on IRC
[quiet contemplation]
fantasai: thinking about to where we might extend there's a variety of metrics you might be interested in. Right now it's not entirely defined where the content box of the inline element is. You could want it to match em box, glyph bounding box.
fantasai: Or match the edge of the line-box. There's several different values we might want at some point. You have a zapfino heading and you want a highlight behind.
astearns: line-gap-fill-ink
florian: if padding is applied to the outer padding goes in from there. Or we apply box-sizing.
fantasai: Let's name the property. Fill value picks a value such that it fills the margin box.
fantasai: We need a name and it should be compat with having different values in the future.
fantasai: inline-sizing.
florian: inline-height sounds fine to me.
astearns: All the names inples changing geometry
fantasai: We do change the geometry of the box. If you put a border the size of the border changes.
astearns: [reads pal question]
dbaron: replaces the padding I think. It's adjusting the paddign to make margin edge line up.
dbaron: Also introduces possiblity of negative padding.
florian: Do we only grow or also shrink is a separate question.
fantasai: leaverou suggests
leaverou: We can reuse line paddign and have it take 1-4 values for all directions and have a fill keyword.
fantasai: I think....we had a fill keyword with 1-4 values what if you apply it to the inline-start.
leaverou: I'm not sure.
fantasai: If you have line-padding-inline-end: fill on a short line the color goes all the way to the edge. THat's not unreasonable.
myles: And that's on a span so it's only to the end of the span if there's a linebreak?
fantasai: Only if it's the end of the line.
astearns: If it's in the middle it goes to the end of the span. If the span ended a line it goes to the end of the line box.
myles: Line break in the middle?
fantasai: If the span is in the middle and there's text at the end there's no effect. If the span breaks or is last thing the background goes to the end.
myles: You have to look at deepest span?
fantasai: In fill case...yeah. Yeah. You'd impl as adding extra space and all the spans extend to the end of the line. Wont' effect position, it's jsut poiint.
florian: Confusing if there's whitespace with a different span at the end?
fantasai: If you use whitespace-pre that's your fault.
astearns: I think we have vague consensus on an approach. Is this in Inline? Would be nice for all TTML in one spec. Others are in Text L4. But this is more inline then text.
astearns: Prop: Have a line padding shotrhand with all the attendant longhands that in additon to lengths takes a fill keyword.
leaverou: Can we have a background:clip keyword that makes it so they don't have to wrap it in a span?
fantasai: What element has the background?
leaverou: Heading and you want to apply the linbox to the heading but you don't want to wrap the heading in a span.
fantasai: You want a pseudo element for the root inline.
leaverou: A new pseudo is more complex to add.
fantasai: This is for a box that exists.
leaverou: Why can't we use padding on that rather then a line wrapping property?
fantasai: Padding is applied to inner most, not outer.
florian: I thought we had normal and fill and you said lengths and fill.
fantasai: This use case for inline needs lengths.
florian: They apply to different things.
myles: Instead oa new property why wouldn't you use lineheight to move lines?
fantasai: Not changing layout which is what line height does. We're changing how box is painted.
myles: what does length do?
fantasai: We discussed adding space like letter spacing, that needs length. Then we discussed how to fill disance between edge of box and edge of linebox and that takes keywords. leaverou asked why not have a single set of 4 properties that solves both use case.. But we're not ure we can.
florian: One was desc as working on block and the other on inlines. fill could be made to work in both, but let's not. It looks like 2 sets of 2 things
astearns: Prop: A line-padding property?
myles: It's valuable to not conflaint properties that mess with layout and ones that mess with paint
fantasai: line-padding was for the letter spacing type thing. I think line-padding is a fine name.
fantasai: We need a name for the one in the other axis.
fantasai: That's changing how we size the box for painting purposes. We've got normal which is what we do not and fill the line box.
myles: CHange veritical alignment?
fantasai: It does not.
florian: We might in the future want to separate extending top and bottom side.
fantasai: I think we'll start with one value for both of these. If someone wants different we can split.
myles: Background will paint outside of the boxes the spans create?
florian: You're extending that.
fantasai: That box has no effect on layout in vertical. It's only about painting.
fantasai: It doesn't change where the text is for that or any element.
florian: And you can already set hte border.
leaverou: We're trying to come up with a second property name for the fill keyword, why not work in one direction?
astearns: I think we're at the point where we can't combine the effects because where we're adding them in the inline is only block container and fixing the gaps can't.
fantasai: One takes lengths and the other keywords.
florian: And we are only missing a good name.
astearns: Prop: A propserty to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.
q?
and might take additional keywords in the future
florian: Remaining question for that property is if you have enough borders it would shrink into the text and then what?
florian: If you have 20px height and 30px borders, did you ask for that and that's your problem?
dbaron: Related to the can it go negative question.
fantasai: Overflow doesn't apply for inline. Border goes behind the text.
fantasai: Which is reasonable in a lot of cases. The alyout area you might want to have negative padding to get things to look the way you want.
florian: Okay.
florian: Do we need to define borders are behind the text or is that clear?
The glyph area of a character might be significantly smaller than the em box
astearns: I think next step is get this in the draft.
astearns: Obj to having this property?
RESOLVED: Add a property to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.
astearns: Added to CSS Inline. Ideas on names are welcome.

[fantasai]

OK, I checked in edits for this. The property is called something-or-other for now. We need an actual name... and possibly to rename normal to be a bit more specific about what it does, once we figure out what it does. T_T

[fantasai]

https://www.w3.org/TR/css-inline-3/#line-fill