- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Nov 2018 17:58:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Proposal for a better line sizing model`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Proposal for a better line sizing model<br> <fantasai> https://drafts.csswg.org/css-inline-3/#line-sizing-property<br> <dael> fantasai: This is a very rough draft. I wanted to doc what we had discussed in the past.<br> <fantasai> https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking<br> <dael> fantasai: Also dbaron original proposal ^<br> <dael> fantasai: Then other discussion listed in issues<br> <dael> 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.<br> <dael> 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.<br> <nigel> q+ to ask if ruby reserve is in scope of the line height sizing<br> <dael> dbaron: Reason to want stable line heights sep then stable baseline patterns?<br> <dbaron> s/then/from/<br> <dael> 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.<br> <dael> astearns: This is more about having a vertical rhythm within an element<br> <dael> fantasai: Right<br> <astearns> ack nigel<br> <Zakim> nigel, you wanted to ask if ruby reserve is in scope of the line height sizing<br> <dael> nigel: Is this considering Ruby height?<br> <dael> 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.<br> <dael> nigel: Ruby is in the line area<br> <dael> fantasai: Typically half in linebox and half outside. Assuming previous line box with space<br> <dael> Rossen: Which is one of the problems because everyone does something with first line and last. Hopefully can do better here<br> <dael> 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<br> <dael> fantasai: If we want a switch that includes Ruby that's a different switch.<br> <dael> fantasai: I think most of the time people are asking for Ruby to be excluded so they line up<br> <dael> 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<br> <dael> 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<br> <dael> nigel: Exactly, yes<br> <dael> fantasai: That would prob have to be sep property. You'd want to say add this much extra space but only here<br> <dael> 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<br> <dael> fantasai: nigel is that issue filed?<br> <dael> nigel: There was question about Ruby reserve. I have to go hunting<br> <myles> Can’t have last lime pseudo because it’s contents van change what the last line is<br> <dael> fantasai: We need to think about that more. but I think it's a slightly different discussion. might end up interacting on same prop.<br> <dael> fantasai: Does make sense we need to solve<br> <dael> 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<br> <dael> fantasai: Might be able to add values to leading-trim property we discussed. It adds space instead of trims<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3199<br> <nigel> -> https://github.com/w3c/csswg-drafts/issues/3240 [css-inline] Leading control at start/end of block #3240<br> <dael> fantasai: nigel can you file and issue?<br> <nigel> -> https://github.com/w3c/csswg-drafts/issues/2998 [css-ruby][css-text-decor-4] Add over-most-under-last value to ruby-position & text-emphasis-position for captioning #2998<br> <dael> nigel: There was a TTML issue I put in IRC. Prob closest we have<br> <dael> nigel: Doesn't include reserve so that's the issue that needs raising<br> <dael> nigel: Happy to raise it<br> <dael> nigel: You think that Rubby reserve should be in leading control?<br> <dael> fantasai: Might make sense. Should look<br> <dael> nigel: IN Ruby?<br> <dael> fantasai: In CSS Inline<br> <dael> fantasai: Discussed at TPAC and decided to add the property<br> <dael> nigel: 3240 perhaps?<br> <dael> fantasai: Yes, that's the one. Haven't edited it into spec yet<br> <dael> nigel: I'll raise an issue<br> <dael> 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.<br> <dael> fantasai: That would solve a lot of the cases. Might be possible to jsut do it.<br> <dael> 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?<br> <dael> fantasai: Different behaviors.<br> <dael> fantasai: I don't know how useful box model is, but it uses margin box of inline boxes<br> <dael> koji: Can you describe different?<br> <dael> 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<br> <dael> 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.<br> <nigel> -> https://github.com/w3c/csswg-drafts/issues/3351 [css-inline][css-ruby] Allow ruby reserve space to be allocated #3351<br> <dael> fantasai: Right now we ignore margin box for inline boxes<br> <nigel> I raised the issue above in relation to the ruby reserve conversation.<br> <dael> 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<br> <dael> 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<br> <dael> dbaron: I'm not sure risks are different between<br> <dael> florian: I'm not sure if there is a difference<br> <dael> fantasai: I listed everything we've discussed so we can talk about what we have<br> <dael> fantasai: If we think box model is better we can do that<br> <dbaron> I guess the risk is that it's more different from the current model<br> <dael> 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.<br> <dael> dbaron: Skeptical about making any of them the default<br> <dael> myles: With dbaron. I don't think we'd impl first to make them a default<br> <dael> astearns: Concern over unknowns? I assume first someone would impl and see what edge cases before any consideration of trying as a default.<br> <dael> 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<br> <dael> gregwhitworth: What authors are begging for this? I heard a few use cases. Is it high demand?<br> <dael> fantasai: People paying attention to typography are frustrated<br> <dael> dauwhe: I'm horrified that a superscript breaks line height<br> <nigel> +1<br> <astearns> +1<br> <fantasai> s/frustrated/frustrated that even within a paragraph where the font size doesn't change, the baseline-to-baseline spacing is inconsistent/<br> <dael> 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<br> <jensimmons> 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.<br> <dael> 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.<br> <dael> 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<br> <dael> 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.<br> <dael> florian: Quirks is different behavior. Is there request for opting into quirks sep from being in quirks?<br> <dael> fantasai: Don't think so<br> <dael> ??: No<br> <myles> S/??/myles/<br> <dael> florian: Seems we could have 2 values. Current or Quirks and the other being box model behavior<br> <dael> fantasai: Legacy and normal?<br> <tantek> Agreed. the quirks behavior here is crap. never heard anyone ask for it deliberately. though hard to tell since it's a default :(<br> <dael> florian: Yeah.<br> <dael> florian: dbaron I think you explored a prop with finer granualrity. Are there varients you thought useful not here?<br> <fantasai> dbaron's proposal was https://dev.w3.org/cvsweb/~checkout~/csswg/css3-linebox/Attic/Overview.html?rev=1.5;content-type=text%2Fhtml#LineStacking<br> <dael> 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<br> <dael> myles: [missed] authors not to have image like text. Or other way around<br> <myles> s/[missed]/we try to tell<br> <dael> 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.<br> <dael> 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<br> <dael> koji: No strong pref between better and box models. Agree better to start with two values.<br> <dael> koji: Question: What do we do for line-height:normal in the case where all browsers correct. We correct for the containment box<br> <nigel> 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<br> <dael> 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<br> <dael> 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<br> <dael> 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<br> <dael> 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<br> <dael> nigel: Targetting avoidance of jitterbetween paragraphs?<br> <dael> fantasai: Mainly within<br> <dael> 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.<br> <dael> 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<br> <dael> 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.<br> <dael> fantasai: inline block is like an image in this case We don't know what's inside<br> <dael> 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<br> <dael> 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<br> <dael> 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.<br> <dael> fantasai: If authro wants consistent they can set a value<br> <dael> 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<br> <dael> fantasai: What if you ran calc based on all available fonts. Whatever you have in system. Prob too many fonts<br> <dael> koji: [missed]<br> <dael> myles: We create objects lazily so we're halfway through paragraph before realize have to create a font<br> <dael> myles: Either before layout paragraph you have 0 fonts or you layout twice. Or anyway do 2 passes<br> <dael> 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<br> <dael> florian: I think I'm with you. Having a hard time thinking through<br> <dael> 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.<br> <dael> myles: Worth consulting other prop apps like inDesign and MS Word. They have line height. Should consider.<br> <dael> astearns: No one else have half leading like web does<br> <dael> myles: Yeah, but we should figure out what they do<br> <dael> 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<br> <chris> half-leading is an exclusively CSS weirdness. Even XSL-FO didn't attempt to adopt it.<br> <dael> 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.<br> <dael> fantasai: Looks like issue with how does line-height normal: interact<br> <dael> fantasai: Other issues?<br> <astearns> ack nigel<br> <Zakim> 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<br> <dael> 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?<br> <dael> fantasai: Then we don't add negative half leading to that element.<br> <dael> 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.<br> <dael> 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.<br> <dael> florian: And we don't have to do that with padding or border?<br> <dael> fantasai: If you applied padding or boder you decided to take control and will be responcible to apply the negative margins<br> <dael> 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?<br> <dael> fantasai: Could add negative half leading unconditionally<br> <dael> nigel: More obvious to me<br> <dael> florian: Might want to leave as an option issue, but unconditional seems to make sense to me.<br> <dael> myles: Which spec is this?<br> <dael> fantasai: Inline<br> <dbaron> q+<br> <dael> myles: Not there already?<br> <dael> fantasai: It's where it's drafted<br> <astearns> ack dbaron<br> <myles> https://drafts.csswg.org/css-inline-3/ ?<br> <dael> 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<br> <dael> dbaron: On the other hand fonts that do that don't play well with this model either<br> <dael> 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<br> <dael> fantasai: Can say it adjusts the content box so then the padding and border added outside leading<br> <dael> florian: That makes sense to me<br> <dael> nigel: Couldn't that cause clipping?<br> <dael> fantasai: No, don't clip inline boxes<br> <nigel> s/Couldn't/And that wouldn't<br> <dael> florian: I think that's quite reasonable. Experiments might show something else, but thinking it's a good model<br> <dael> myles: We seem to have a lot of ideas and theories. If this goes into a spec it should have a don'timpl marker<br> <dael> astearns: Section does have that.<br> <dael> astearns: This discussion of negative half leading is that a sep issue?<br> <dael> fantasai: Yeah. We'll put it unconsitionally it adjust content box and file and issue to discuss further<br> <dael> astearns: Action for you?<br> <dael> fantasai: Yeah<br> <dael> ACTION fantasai put it unconditionally negative padding adjust content box and file and issue to discuss further<br> <trackbot> 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].<br> <dael> 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.<br> <dael> fantasai: Yes and going over filed issues<br> <dael> fantasai: Should this prop apply to block containers or inline boxes?<br> <dael> koji: Prefer block container I think<br> <dael> 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.<br> <dael> astearns: Want to avoid a case where we introduce shift because we introduct it to an inline container that breaks across lines<br> <dael> dbaron: Haven't htought through inline boxes well<br> <dael> fantasai: I'll have it apply to inline boxes and file an issue<br> <dael> astearns: Sounds good<br> <dael> astearns: Anything more on this topic?<br> <dael> astearns: I'm really happy we had this conversation. Winnowing the options and having something more focused for the future is an excellent result.<br> <jensimmons> +1 to what Alan said<br> <dael> astearns: Likely can't take over the regular call in the future, I'm happy to have extra line layout TF calls when needed.<br> <dael> fantasai: I'll draft up stuff and we'll meet again soon<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3199#issuecomment-442544210 using your GitHub account
Received on Wednesday, 28 November 2018 17:59:05 UTC