[css-inline] Draft line-box-contain proposal

[fantasai]

@dbaron had a proposal called line-box-contain for controlling how line box heights are calculated. Some aspects of this feature probably need to be revived if we're going to have baseline-to-baseline distances that aren't wiggly in simple cases like a single-font-size paragraph mixing proportional and monospace text.

Proposed values need to include:

• current behavior value ('normal'? 'legacy'?)
• value that ignores > 1em line-height values on anything other than the root inline box (slightly more conservative approach than dbaron's proposal to only use the root inline) so that the line box only grows if its contents actually extend outside the outer leading edges of the root inline
• possibly an “absolute” value that does use only the root inline? This can introduce content overlap...
• quirks mode value?
• anything else?

[kojiishi]

I'm writing this only with half-baked understanding, so there might be some incorrect parts, please read with that understanding.

After I heard a proposal from @fantasai about leading-over/-under, I'm thinking the relationship between it and line-box-contain. As far as I understand, the current scope of leading-over/-under is only for the first and the last line box, but if we apply that to all line boxes, it can also solve the baseline jitter problem, as far as line-height is set to a fixed value, am I correct?

[fantasai]

@kojiishi No, because leading-over/under gets rid of the leading. In general you want leading between lines. :) We just need to make sure the contents of the line don't contribute excess space to the line box, and that the baseline is consistently positioned within that space.

[fantasai]

Some old discussions: dbaron's line-box-contain proposal and Hyatt's proposal to www-style

[kojiishi]

Thanks, right, I think I understand it better. And the proposal looks good to me.

[css-meeting-bot]

The CSS Working Group just discussed Draft line-box-contain proposal.

The full IRC log of that discussion

Topic: Draft line-box-contain proposal
github: https://github.com//issues/3199
fantasai: We talked about having a prop that does roughly this. Some control over height of line calc. Been discussed since before my time. dbaron had interesting proposals for how to do it
fantasai: Know we need 3 behaviors: now, quirks mode, and consistant lines people want
fantasai: Drafted rough proposal with behaviors talked about.
https://drafts.csswg.org/css-inline-3/#line-sizing-property
fantasai: Wanted to ask WG if we want to work on this? Add something? I think need to add to inline spec, this is a rough draft.
fantasai: I think we need to add a property that does something smooth with a syntax
fantasai: Vague, but I wanted a start
myles: Been thinking about this for a while and I don't know right approach. Need backwards compat, but mode switches are confusing and multiple ways to solve line-height is extra mantanence and makes web more complicated. Not sure right way to do this
florian: Hard time seeing anything but a mode switch here. Not sure we need that many values, I'd rather 2. One does legacy or quirk depending on mode and the better behavior. Others listing leave out until proven
fantasai: The 'better behavior' says [reads]
fantasai: It might be possible to slip that in without breaking too much. Any ledding is too much. It's possible that wont' break anything
q+ dbaron
myles: Not saying mode switch bad. More frustration about where we got to. Also, want to say this is one of the most requested features from people that care about text. Great to solve. We're between a rock and a hard place
s/Any ledding/Any leading/
dauwhe: I will use it as soon as it exists
q?
s/is too much/would break, but only eliminating positive leading might be possible/
Rossen: Where do we work on it?
dbaron: A few comments
ack dbaron
dbaron: I think there is an alternative to mode swhich is new syntax to line-height. Mode switch-like, but not as bad in some ways
I seem to only have mic issues with WebEx, need to figure out why as I use this setup for podcasts with no issue.
dbaron: May need >1 new value. bunch of use cases for things like images in a line and in default you want images to change line height, but there are cases where images within a line and do not want a change because images are roughly the size of the text
fantasai: In terms of new keywords for line-height for ergonomics a mode switch is better. Line-height you're talking about quantity of space, not the mechanism by which you want to measure. It's a separate thought in how you want to do it.
fantasai: You want the good line height calc on the whole page and forget it. Same way as box sizing is done. I used to think it was a mistake, but the way we did box sizing was originally almost always wrong. Webdev would rather set it once on a style sheet.
I actually disagree about box-sizing, since I think it depends whether you care about the inside-size or the outside-size
fantasai: This is similar. You almost never want to switch. You want to set at the top and you don't want to think anymore. If you put it in line-height you have to think every time you change the line height
myles: Would a mode swtich change the way line-height is inherited?
yes it was certainly my intent when I proposed box-sizing that it was a "just fix it so things work like I expect across all the things box related"
s/inherited/inherited or how it applies to only block elements and not inlines/
fantasai: Various behaviors prop. One that would fix most problems would be to change it so line-height is ignored on all inline elements. They just have a line-height of 1 effectively.
fantasai: Had to modify so if you set line-height <1 we add negative leading so your effect is honored
fantasai: Not that it doesn't apply, just only applies if negative leading. Applies to root and then applied to every line. As long as you're in that space, if the sizing box fits, it doesn't increase height of line or move it
myles: Any precedent for that type of behavior?
myles: I mean changing the behavior of a prop based on another prop. Not sure how I would impl
Rossen: sorry! i didn't realize the time
Rossen: Sorry to interrupt. We're 4 minutes overtime. I want convo to continue, but I want to let everyone else go. We won't resolve, but convo should continue
scribenick: gregwhitworth
oh
lol
myles: I have to go too.
fantasai: Schedule a separate call about this
Rossen: Good idea
Rossen: Focused group would be good. I'll send an email to private list to see if we can get folks
fantasai: I can sent
Rossen: Have a great Thanksgiving for those of you celebrating. Talk to you next week.

[css-meeting-bot]

The CSS Working Group just discussed Proposal for a better line sizing model.

The full IRC log of that discussion

Topic: Proposal for a better line sizing model
https://drafts.csswg.org/css-inline-3/#line-sizing-property
fantasai: This is a very rough draft. I wanted to doc what we had discussed in the past.
https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking
fantasai: Also dbaron original proposal ^
fantasai: Then other discussion listed in issues
fantasai: Main goal is try and control jitter on the line and also make sure line box sizes are consistent and baseline position is consistent across line boxes.
fantasai: In common cases. If there's a giant image maybe it grows. This is where you have same font size, but you change font family midway you create jitter. As long as author has given adequite line height it shouldn't cause line box to grow.
q+ to ask if ruby reserve is in scope of the line height sizing
dbaron: Reason to want stable line heights sep then stable baseline patterns?
s/then/from/
fantasai: Mainly stable baselines. You can't see edge of linebox. If linebox is same height but baseline changes it makes jitter. This isn't wanting a line grid. That's a separate issue.
astearns: This is more about having a vertical rhythm within an element
fantasai: Right
ack nigel
nigel, you wanted to ask if ruby reserve is in scope of the line height sizing
nigel: Is this considering Ruby height?
fantasai: Current way Ruby is defined to work is if you have enough leading that double that would create enough space for Ruby you don't increase line. Line to line is half above and half below.
nigel: Ruby is in the line area
fantasai: Typically half in linebox and half outside. Assuming previous line box with space
Rossen: Which is one of the problems because everyone does something with first line and last. Hopefully can do better here
fantasai: For Ruby you want to make sure enough space. When doing first or last line you don't want to consider Ruby when placing because you usually have enough padding. Leading trim prop discussed at F2F as to where you consider top of line ot be. That exclused Ruby so lets you place as people expect
fantasai: If we want a switch that includes Ruby that's a different switch.
fantasai: I think most of the time people are asking for Ruby to be excluded so they line up
nigel: My expectation seems different. If you have or might have a Ruby before you want to make sure line space is big enough. Same with after. Have to be independent of content before. In the case of a caption where text keeps changing need to make sure baseline appears in consistent place weither or not Ruby appears
fantasai: For captions layout rules are slightly different then docs. Doing that we would need some way of saying leave this much space, but only on the top. Right now extra space is applied top and bottom
nigel: Exactly, yes
fantasai: That would prob have to be sep property. You'd want to say add this much extra space but only here
nigel: Before or after or both. A first and last line selector that adjusts it so you can be clever about where you put Ruby
fantasai: nigel is that issue filed?
nigel: There was question about Ruby reserve. I have to go hunting
Can’t have last lime pseudo because it’s contents van change what the last line is
fantasai: We need to think about that more. but I think it's a slightly different discussion. might end up interacting on same prop.
fantasai: Does make sense we need to solve
nigel: One outcome we should aim for is if we include Ruby reserve or not it's clear which we do. If there's a way to add Ruby reserve does it add line sizing? put a wrapper? need to be clear whatever the model is
fantasai: Might be able to add values to leading-trim property we discussed. It adds space instead of trims
github: https://github.com//issues/3199
-> https://github.com//issues/3240 [css-inline] Leading control at start/end of block #3240
fantasai: nigel can you file and issue?
-> https://github.com//issues/2998 [css-ruby][css-text-decor-4] Add over-most-under-last value to ruby-position & text-emphasis-position for captioning #2998
nigel: There was a TTML issue I put in IRC. Prob closest we have
nigel: Doesn't include reserve so that's the issue that needs raising
nigel: Happy to raise it
nigel: You think that Rubby reserve should be in leading control?
fantasai: Might make sense. Should look
nigel: IN Ruby?
fantasai: In CSS Inline
fantasai: Discussed at TPAC and decided to add the property
nigel: 3240 perhaps?
fantasai: Yes, that's the one. Haven't edited it into spec yet
nigel: I'll raise an issue
fantasai: I think the main thing we need is a behavior where we ignore the line-height prop on any inline level boxes. So toher than root inline. Continue to height only if leaking outside of line height set by root.
fantasai: That would solve a lot of the cases. Might be possible to jsut do it.
florian: The better behavior and the box model behavior are they distinct because different use cases or because one might be able ot be a default?
fantasai: Different behaviors.
fantasai: I don't know how useful box model is, but it uses margin box of inline boxes
koji: Can you describe different?
fantasai: Current line sizing model takes the root inline and applies half leading. every inline box ignores margins, border, padding and intead uses line height to calc leading. Makes sure line box includes text content and leading above and below
fantasai: Box model behavior doesn't use line height on any inline element. It uses margin edges and uses that as the sizing box and tries to make sure line box is big enough to contain all margin boxes.
-> https://github.com//issues/3351 [css-inline][css-ruby] Allow ruby reserve space to be allocated #3351
fantasai: Right now we ignore margin box for inline boxes
I raised the issue above in relation to the ruby reserve conversation.
dbaron: Almost feels like it's not clear to methe use case for better rather then box. Seems silly to not include a border if you have one. If you want to not you can use negative margin
florian: I think that's what I was thinking. You probably want either of those in similar cases. Might want better over box only because we might be able to make the better behavior a default. If we can't make better a default ight not want it
dbaron: I'm not sure risks are different between
florian: I'm not sure if there is a difference
fantasai: I listed everything we've discussed so we can talk about what we have
fantasai: If we think box model is better we can do that
I guess the risk is that it's more different from the current model
florian: On that train of thought, if we think better behavior might be usable as a default would anybody be willing to try as an impl and go first? Or is it jut a thought experiment and we don't need to consider it.
dbaron: Skeptical about making any of them the default
myles: With dbaron. I don't think we'd impl first to make them a default
astearns: Concern over unknowns? I assume first someone would impl and see what edge cases before any consideration of trying as a default.
gregwhitworth: I think you impl first. Similar to how we allow border boxsizing to change. Let authors use it. If it goes well we can do a trial
gregwhitworth: What authors are begging for this? I heard a few use cases. Is it high demand?
fantasai: People paying attention to typography are frustrated
dauwhe: I'm horrified that a superscript breaks line height
+1
+1
s/frustrated/frustrated that even within a paragraph where the font size doesn't change, the baseline-to-baseline spacing is inconsistent/
myles: Gotten many requests of people interested in line layout for typography. They have baseline to baseline metrics from a designer and there's nothing they can to to make that happen
There are entire books written about how to deal with the stupidity of the defaults. People who care about typography & graphci design are intensely frustrated with the status quo.
florian: Asked about default because if neither can be default no reason to have both. Prob box model over better behavior. If we can have a default maybe cause for both. But it's not obvious we do.
florian: Absolute behavior seems more risky. That makes sense as sep. Also wondering if this is a value where authors think it's right and on the user's computer something is different and there's overlap
fantasai: Very skeptical absolute behavior is right to add. Creates a large risk of things going wrong. I added it for completeness. Def not first edition.
florian: Quirks is different behavior. Is there request for opting into quirks sep from being in quirks?
fantasai: Don't think so
??: No
S/??/myles/
florian: Seems we could have 2 values. Current or Quirks and the other being box model behavior
fantasai: Legacy and normal?
Agreed. the quirks behavior here is crap. never heard anyone ask for it deliberately. though hard to tell since it's a default :(
florian: Yeah.
florian: dbaron I think you explored a prop with finer granualrity. Are there varients you thought useful not here?
dbaron's proposal was https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking
dbaron: It's poss there might be some cases where you want...if you need something like image-like text you might be okay with them extending. Pretty edge case-y
myles: [missed] authors not to have image like text. Or other way around
s/[missed]/we try to tell
fantasai: dbaron prop had sizing around glyph bounding block. Sometimes useful. One way to incorp is have it in inline sizing. Be able to switch and say this box uses glyph bounding. This switch will inherit through entire doc and it'll be just this box needs glyph sizing.
fantasai: That's the value I think prompted webkit to impl. Mainly to allow a box to pick up less space. Larger font size with cap letters it made the line increase even with no ink
koji: No strong pref between better and box models. Agree better to start with two values.
koji: Question: What do we do for line-height:normal in the case where all browsers correct. We correct for the containment box
q+ to ask for box-model what happens with negative half leading to other inline boxes than those whose block-axis margins, borders, and padding are zero
florian: Can you remind me in what way it collects things across elements? I remember line-ehight:normal on a single, but not on multiple
koji: We unifity allthe metrics so that all fonts are considered in the height. THen the inline box height is included in the parent height. Since we're only taking root line box I guess we need to change to treat all
myles: 2 desires. If there's content in the middle that's really big you want increase. A little bigger you don't want. We need rules to distinguish the cases
fantasai: THe better behavior and box model are supposed to have it be that if box leaks outside line box we increase size of box. Leading means if you're only a little bigger you'll fit inside unless you've got a really tight line height. Both break down on how they handle maintaining font size and changing font family. Normally you have enough leading for that, but if you're setting line-height:1 it'll create jitter and I'm not sure how to handle that case
nigel: Targetting avoidance of jitterbetween paragraphs?
fantasai: Mainly within
nigel: Typesetting you might have 2 paragraphs, one with a modification that adjust the line height. If it has paragraphs on other side it looks weird if other paragraphs have different. Typographic is here's my line spacing, use it everywhere.
fantasai: That's what we're trying. It's the same as when we have multiple line paragraph and only one line grows. We want to solve that and related cases where there's content that fits within the space but also when you try and include leading and there's already leading
astearns: MIght be good to add to draft text here are the cases we want to address. And here are the ones we're not fixing like an inlineblock with different line height.
fantasai: inline block is like an image in this case We don't know what's inside
florian: What we just discussed answers koji. line-height:normal shouldn't do anything special with looking at font metrics. If they do stick out line height increases. Shouldn't do anything different there then numeric values. Then we'd have the problems where have different line heights because different font
fantasai: Normal should behave as 1.1 or whatever it resolves on on the root inline. Take the value off the first available would be a reasonable behavior
koji: I think I like current, not sure it's well spec. Current impl of line-height:normal that takes all points. Doesn't give consistent but it makes text legible.
fantasai: If authro wants consistent they can set a value
myles: Valuable to take all used fonts into consideration. Could be all text comes from font far down list. But if we do that we get jitter. Sounds like we want to figure it all out and then layout, but that's 2 pass and prob too slow
fantasai: What if you ran calc based on all available fonts. Whatever you have in system. Prob too many fonts
koji: [missed]
myles: We create objects lazily so we're halfway through paragraph before realize have to create a font
myles: Either before layout paragraph you have 0 fonts or you layout twice. Or anyway do 2 passes
astearns: Seems to me kind of consideration koji said where look at whole line and metrics and decide what to set that happens after root inline box. You choose root inline box and for every actual line you look at used fonts, figure out metrics, and see if fits in root inline. If it does, no change. If it doesn't, line may increase in height
florian: I think I'm with you. Having a hard time thinking through
koji: I think we need some detailed definition written down for review. In general I like the line setting proposal. Make it 2 values. Probably have 2 behaviors, one when it's normal and one when it's not.
myles: Worth consulting other prop apps like inDesign and MS Word. They have line height. Should consider.
astearns: No one else have half leading like web does
myles: Yeah, but we should figure out what they do
koji: Agree. At least line sizing we're trying to define new model so learning what other apps do and try to incorperate is good
half-leading is an exclusively CSS weirdness. Even XSL-FO didn't attempt to adopt it.
fantasai: Summary: We want to have a line sizing prop with 2 vaues, legacy and normal. Hearing preference for box model behavior rather then better behavior. I can redraft to bring down to that.
fantasai: Looks like issue with how does line-height normal: interact
fantasai: Other issues?
ack nigel
nigel, you wanted to ask for box-model what happens with negative half leading to other inline boxes than those whose block-axis margins, borders, and padding are zero
nigel: I was reading text on box model. There's a not covered case. Not sure how important. It talks abotu applying postive and negative half leading. Neg it says [reads]. What about thosewhose margin/border/padding are not 0?
fantasai: Then we don't add negative half leading to that element.
fantasai: That sentence was trying to address...if you have a ling height of 0.8 you're adding negative half leading. One of our goals was to not have a span inside your line increase the line size unless it's significantly larger. Let's say all text is samefont and size. We apply leading. Then we encounter a span. Without this exception the box will be sizes as a line height of 1. It'll be taller b/c didn't apply line-height so it causes line to increase.
fantasai: If line height causes negative half leading we need to take the amount it shrinks and apply to other boxes. Don't want to do it >1 because then we grow too much.
florian: And we don't have to do that with padding or border?
fantasai: If you applied padding or boder you decided to take control and will be responcible to apply the negative margins
nigel: Seems liek a special case that will surprise. Imagine you only want a border around a piece of text, no other change. Seems like a surprise if it causes an increase?
fantasai: Could add negative half leading unconditionally
nigel: More obvious to me
florian: Might want to leave as an option issue, but unconditional seems to make sense to me.
myles: Which spec is this?
fantasai: Inline
q+
myles: Not there already?
fantasai: It's where it's drafted
ack dbaron
https://drafts.csswg.org/css-inline-3/ ?
dbaron: Seems to me there are different use cases that lead to neg half leading and might want different things to happen. Font has a relatively large...the size you add the leading around is large. Line height might do negativehalf leading b/c tight line height. Doesn't mean you want to remove from everything else
dbaron: On the other hand fonts that do that don't play well with this model either
myles: Case you described is common b/c designers don't know their font metrics. They put a font and adjust line height until it looks good. Theydon't know if that crosses the invisible line of ascent and descent
fantasai: Can say it adjusts the content box so then the padding and border added outside leading
florian: That makes sense to me
nigel: Couldn't that cause clipping?
fantasai: No, don't clip inline boxes
s/Couldn't/And that wouldn't
florian: I think that's quite reasonable. Experiments might show something else, but thinking it's a good model
myles: We seem to have a lot of ideas and theories. If this goes into a spec it should have a don'timpl marker
astearns: Section does have that.
astearns: This discussion of negative half leading is that a sep issue?
fantasai: Yeah. We'll put it unconsitionally it adjust content box and file and issue to discuss further
astearns: Action for you?
fantasai: Yeah
ACTION fantasai put it unconditionally negative padding adjust content box and file and issue to discuss further
Created ACTION-875 - put it unconditionally negative padding adjust content box and file and issue to discuss further [on Elika Etemad - due 2018-12-05].
astearns: Converging on 2 value legacy and new thing. Will need to be a lot of cleaning up of section in spec and adding details discussed and then going over spec text.
fantasai: Yes and going over filed issues
fantasai: Should this prop apply to block containers or inline boxes?
koji: Prefer block container I think
dbaron: If inherited and it can apply to inline boxes there's not a disadvantage to doing it. Might bea little weird in terms of effects.
astearns: Want to avoid a case where we introduce shift because we introduct it to an inline container that breaks across lines
dbaron: Haven't htought through inline boxes well
fantasai: I'll have it apply to inline boxes and file an issue
astearns: Sounds good
astearns: Anything more on this topic?
astearns: I'm really happy we had this conversation. Winnowing the options and having something more focused for the future is an excellent result.
+1 to what Alan said
astearns: Likely can't take over the regular call in the future, I'm happy to have extra line layout TF calls when needed.
fantasai: I'll draft up stuff and we'll meet again soon

[fantasai]

Note: There were some interesting comments related to this from dbaron in https://lists.w3.org/Archives/Public/www-style/2020Feb/0020.html

[fantasai]

Agenda+ to decide whether to publish with the previously-drafted text or not. (I don't think it's good, it's just a starting point.) https://drafts.csswg.org/css-inline-3/#line-sizing-property

[css-meeting-bot]

The CSS Working Group just discussed Draft line-box-contain proposal, and agreed to the following:

• RESOLVED: Publish css-inline

The full IRC log of that discussion

Topic: Draft line-box-contain proposal
github: https://github.com//issues/3199
fantasai: this is the main one we've discussed a bunch about drafting alternate models for line layout
... some of the ideas are captured in the draft
... do we want to publish with them in the draft?
... it's not in any way final, question is just whether we want a placeholder in there to solicit discussion on the ideas
florian: agree it's not final, but it's worth leaving in to get extra review
dbaron: I think it's mostly reasonable, though there's a sentence in there I don't understand
... "half-leading is inserted inside the content box edges rather than overlapping the pbm areas"
fantasai: I can remove that sentence
... if you wanted a line height that's less than 1, somehow we have to reduce the size of the box that we're considering for the height of the line
... otherwise it would increase the height of the line box
... there's needs to be a reduction at least on the margin
... somewhere we need to reduce the size
dbaron: I guess there's 2 questions. one is what you said makes it sound like you want line height to change where the pbm go
... when half leading would be negative
fantasai: yes
... that's one option
... but we could also not do that. it's not critical, I can remove it from the draft for now, but we should discuss at some point
... other option is to reduce the margin box
dbaron: I think it might be good to move into an issue
... might be good to remove that part, but otherwise I'm fine with publishing with this in
Rossen_: any other reasons to hold back publishing?
baseline-source: auto | first | last
fantasai: we also added a baseline-source property for #861
... the syntax wasn't resolved yet
... we also added a leading-trim proposal, which again is not anywhere near final, but it's tracking the discussion we've had in the past
... then I pulled in a bunch of CSS 2.1 with florian's help, so we have some line height calculations defined in this draft. no changes, just imported text
florian: just to clarify, the 2.1 changes we're talking abotu (actually 2.2) we resolved
... they've been reverted to clean up CSS 2
... the wording we had resolved on and applied to CSS 2 is not present anywhere if we don't publish it here
... so I'm strongly in favor of publishing it
Summary of the changes we didn't quite resolve on at https://lists.w3.org/Archives/Member/w3c-css-wg/2020AprJun/0137.html
Rossen_: any objections, to this and publishing inline?
fantasai: issue needs to remain open
... the issue on adding a new model for line height calculations. the issue isn't closed yet, despite publishing
s/reverted to clean up CSS 2/reverted along with every other edit to CSS 2 as part of a temporary clean up/
all changes at https://drafts.csswg.org/css-inline-3/#changes
In 3.5 "Leading Control" I'd change "the ascend and descent font metrics" to change "ascend" to "ascent"
RESOLVED: Publish css-inline
https://github.com//issues/862