- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 10 Apr 2018 15:30:21 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Allow background of an inline area to extend to before-and after-edges of the line area<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1974<br> <dael> fantasai: In this case I think we need to apply to the inline.<br> <dael> florian: I don't know if you need to but there's no complication on it.<br> <fremy> https://www.bloomberg.com/news/articles/2017-09-20/google-is-said-close-to-buying-htc-assets-to-bolster-hardware<br> <dael> koji: When talking about extending inline boxes height?<br> <fremy> q+<br> <dael> fantasai: Only for painting.<br> <dael> Rossen: Is it?<br> <dael> fantasai: Yes, layout is based on line height. We don't care about padding, amrgins etc.<br> <dael> fremy: I put a link on IRC that's a website that tries to do this.<br> <dael> fremy: I think how the did it is set some padding on the line and let's you extend the background.<br> <dael> Rossen: They'll have overlap.<br> <dael> dbaron: If you choose too much you cover up text in other line.<br> <dael> Rossen: If you resize the window down to 3 lines you lose some of the y<br> <leaverou> fremy: I've also seen it done with box-shadow to simulate line-padding, it's a very common effect<br> <dael> fremy: They also used box shadow.<br> <dael> florian: Are we discussing a protential property that siwtches the outer content height of inline boxes to be the height of the line?<br> <dael> dbaron: I think border height<br> <dael> fantasai: Outer is margin<br> <dael> florian: meant border.<br> <dael> 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]<br> <dael> 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.<br> <dael> 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.<br> <dael> fantasai: Should be clear regardless of the vertical positioning the background moves with the txt.<br> <dael> fantasai: Might be margin box you want.<br> <dael> dbaron: NO harm in the margin box because then it makes margin useful.<br> <dael> dbaron: Then you could inset some of the background.<br> <dael> florian: It's commonly set i nboth direction because it only does something in one.<br> <dael> TabAtkins: This won't be turned on by default.<br> <dael> florian: I guess.<br> <dael> dbaron: Also let's people make the border stick out by using a negative margin.<br> <dael> florian: Okay. I buy that.<br> <dael> florian: Property with normal and fill?<br> <dael> fantasai: Or add it as a keyword on padding property. Padding top-fill so it means make the padding such...<br> <dael> astearns: Then you have to do it on each direction<br> <dael> fantasai: We have padding-block-start.<br> <dbaron> I'd note that this does introduce negative padding, which might be interesting...<br> <fantasai> fantasai: You could say 'padding-block: fill'<br> <fantasai> on the inline<br> <dael> 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.<br> <dael> 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.<br> <dael> fantasai: Wht makes it more complex to impl? On every inline you haev to call the paint your backgrounds function.<br> <dael> iank_: This goes over the size of the line potentially.<br> <dael> fantasai: You have to handle that for line-height.<br> <dael> iank_: That's line-box sixe.<br> <dael> fantasai: If I set my line ehight ot 10 and padding on my inline box is 10 above and below I'll leak over.<br> <dael> florian: Rossen you're version if the middle is top green and bottom yellow how to you know it doesn't overlap.<br> <dael> Rossen: It doesn't. It's a simplification because it's one background behind all.<br> <dael> Rossen: But they want different colors. Not jsut one element.<br> <dael> s/rossen/fantasai<br> <dael> 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.<br> <dael> fantasai: padding doesn't effect [missed]. it changes box size but not things around.<br> <dael> Rossen: You can have tearing or overlapping.<br> <dael> fantasai: You can already do the overlapping. i'm not sure how concerns about overlapping or not are valid.<br> <dael> 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.<br> <dael> fantasai: But then what about when you do images?<br> <dael> 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.<br> <dael> Rossen: If we leave to authors we'll have different rounding.<br> <dael> 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.<br> <dael> astearns: Do we follow TTML lead and call it fill-linegap?<br> <dael> fantasai: No.<br> <dael> florian: inline-box-sizing?<br> <dael> koji: Sizing is not right.<br> <dael> florian: inline-height: normal|fill<br> <dael> leaverou: Too much like line-height.<br> <koji> s/is not right/sounds like layout/<br> <dael> astearns: Line-extend<br> <dael> iank_: border-outsets<br> <leaverou> line-area?<br> <dael> fantasai: You're not outsetting, you could be insetting.<br> <dael> florian: inline-height and line-height are similar but if you're aware of both you won't be confused.<br> <dael> iank_: Not all webdev know all css properties.<br> <dael> fantasai: line-gap-fill<br> <dael> astearns: Pierre suggests line-box-fill on IRC<br> <dael> [quiet contemplation]<br> <dael> 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.<br> <dael> 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.<br> <dael> astearns: line-gap-fill-ink<br> <dael> florian: if padding is applied to the outer padding goes in from there. Or we apply box-sizing.<br> <dael> fantasai: Let's name the property. Fill value picks a value such that it fills the margin box.<br> <dael> fantasai: We need a name and it should be compat with having different values in the future.<br> <dael> fantasai: inline-sizing.<br> <dael> florian: inline-height sounds fine to me.<br> <dael> astearns: All the names inples changing geometry<br> <dael> fantasai: We do change the geometry of the box. If you put a border the size of the border changes.<br> <dael> astearns: [reads pal question]<br> <dael> dbaron: replaces the padding I think. It's adjusting the paddign to make margin edge line up.<br> <dael> dbaron: Also introduces possiblity of negative padding.<br> <dael> florian: Do we only grow or also shrink is a separate question.<br> <dael> fantasai: leaverou suggests<br> <dael> leaverou: We can reuse line paddign and have it take 1-4 values for all directions and have a fill keyword.<br> <dael> fantasai: I think....we had a fill keyword with 1-4 values what if you apply it to the inline-start.<br> <dael> leaverou: I'm not sure.<br> <dael> 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.<br> <dael> myles: And that's on a span so it's only to the end of the span if there's a linebreak?<br> <dael> fantasai: Only if it's the end of the line.<br> <dael> 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.<br> <dael> myles: Line break in the middle?<br> <dael> 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.<br> <dael> myles: You have to look at deepest span?<br> <dael> 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.<br> <dael> florian: Confusing if there's whitespace with a different span at the end?<br> <dael> fantasai: If you use whitespace-pre that's your fault.<br> <dael> 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.<br> <dael> astearns: Prop: Have a line padding shotrhand with all the attendant longhands that in additon to lengths takes a fill keyword.<br> <dael> leaverou: Can we have a background:clip keyword that makes it so they don't have to wrap it in a span?<br> <dael> fantasai: What element has the background?<br> <dael> leaverou: Heading and you want to apply the linbox to the heading but you don't want to wrap the heading in a span.<br> <dael> fantasai: You want a pseudo element for the root inline.<br> <dael> leaverou: A new pseudo is more complex to add.<br> <dael> fantasai: This is for a box that exists.<br> <dael> leaverou: Why can't we use padding on that rather then a line wrapping property?<br> <dael> fantasai: Padding is applied to inner most, not outer.<br> <dael> florian: I thought we had normal and fill and you said lengths and fill.<br> <dael> fantasai: This use case for inline needs lengths.<br> <dael> florian: They apply to different things.<br> <dael> myles: Instead oa new property why wouldn't you use lineheight to move lines?<br> <dael> fantasai: Not changing layout which is what line height does. We're changing how box is painted.<br> <dael> myles: what does length do?<br> <dael> 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.<br> <dael> 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<br> <dael> astearns: Prop: A line-padding property?<br> <dael> myles: It's valuable to not conflaint properties that mess with layout and ones that mess with paint<br> <dael> fantasai: line-padding was for the letter spacing type thing. I think line-padding is a fine name.<br> <dael> fantasai: We need a name for the one in the other axis.<br> <dael> 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.<br> <dael> myles: CHange veritical alignment?<br> <dael> fantasai: It does not.<br> <dael> florian: We might in the future want to separate extending top and bottom side.<br> <dael> fantasai: I think we'll start with one value for both of these. If someone wants different we can split.<br> <dael> myles: Background will paint outside of the boxes the spans create?<br> <dael> florian: You're extending that.<br> <dael> fantasai: That box has no effect on layout in vertical. It's only about painting.<br> <dael> fantasai: It doesn't change where the text is for that or any element.<br> <dael> florian: And you can already set hte border.<br> <dael> leaverou: We're trying to come up with a second property name for the fill keyword, why not work in one direction?<br> <dael> 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.<br> <dael> fantasai: One takes lengths and the other keywords.<br> <dael> florian: And we are only missing a good name.<br> <dael> astearns: Prop: A propserty to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.<br> <astearns> q?<br> <fantasai> and might take additional keywords in the future<br> <dael> florian: Remaining question for that property is if you have enough borders it would shrink into the text and then what?<br> <dael> florian: If you have 20px height and 30px borders, did you ask for that and that's your problem?<br> <dael> dbaron: Related to the can it go negative question.<br> <dael> fantasai: Overflow doesn't apply for inline. Border goes behind the text.<br> <dael> 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.<br> <dael> florian: Okay.<br> <dael> florian: Do we need to define borders are behind the text or is that clear?<br> <fantasai> The glyph area of a character might be significantly smaller than the em box<br> <dael> astearns: I think next step is get this in the draft.<br> <dael> astearns: Obj to having this property?<br> <dael> RESOLVED: Add a property to be named that applies to everything with 2 values, normal and fill. It inherits and applies to inline boxes.<br> <dael> astearns: Added to CSS Inline. Ideas on names are welcome.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1974#issuecomment-380143598 using your GitHub account
Received on Tuesday, 10 April 2018 15:30:24 UTC