15:59:56 RRSAgent has joined #css 15:59:56 logging to https://www.w3.org/2020/06/17-css-irc 15:59:59 RRSAgent, make logs Public 16:00:00 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:00:13 present+ 16:00:17 present+ 16:00:21 ScribeNick: dael 16:00:50 present+ florian 16:00:52 alisonmaher has joined #css 16:00:55 present+ dholbert 16:01:03 present+ 16:01:13 present+ 16:01:23 Rossen_: We'll get going in a few minutes to give late arrivers time 16:01:32 present+ 16:01:53 present+ 16:01:53 jfkthame has joined #css 16:01:59 Rossen_: We will do a 90 minute call. Will try and stop around 1 hour mark because we have to let dael go and also for the others that can't stay over 60 minutes it's a good time for a break 16:02:10 futhark has joined #css 16:02:29 Rossen_: Let's get going 16:02:33 faceless2_ has joined #css 16:02:35 present+ 16:02:50 present+ 16:02:54 Rossen_: Let's go with the agenda unless there's a last minute change. 16:02:57 present+ 16:02:59 Topic: [css-inline-3] Shift top | bottom | center values from alignment-baseline to baseline-shift 16:03:07 github: https://github.com/w3c/csswg-drafts/issues/5180 16:03:20 present+ 16:03:25 fantasai: top bottom and center values. center is new, top and bottom have been since css 1. 16:03:28 present+ 16:03:32 present+ 16:03:42 fantasai: When we pulled in alignment-baseline and basline-shift we made them longhands for vertical-align 16:03:49 present+ 16:04:02 fantasai: Weren't sure what to to with top and bottom b/c don't spec baseline or a shift exactly. put under alignment-baseline. 16:04:32 fantasai: Seemed to make more sense to go under baseline-shift property. Alignment baseline is a concept that exists for a lot of other boxes but top and bottom don't have a meaning. 16:04:41 q? 16:05:04 fantasai: I was thinking would make more sense on baseline-shift which is how much to shift afte ryou align. In which case we ignore baselines b/c top and bottom don't care. THey use top and bottom of align subtree 16:05:47 florian: PoV from insie element top and bottom values don't combine with either, they take over. From PoV of element reltationship with parents it does make sense to continue applying alignment-baseline even if top and bottom shifted. Am I getting that right? 16:05:53 present+ 16:06:39 fantasai: Yeah. Prob only case for both is table cells where top and bottom values trigger behavior on align-content. In that case if you have a table with a single table cell and if you veritical=align top the baseline still has a meaning to allowt able to align to. In which case we have to export a baseline so there's a meaning to having both values 16:06:56 fantasai: Within inline layout top and bottom has no ability to combine with aligned baseline or baseline shift. 16:07:40 florian: Another approach is from cascade and setting. Most of the time you set in shorthand. If set separate having some feeling that align-baseline is based on broad context and you could be doing this for whole doc but locally switch to top and bottom 16:07:51 florian: It's a good fit for neither, but I weak lean toward your proposal 16:08:12 myles has joined #css 16:08:17 AmeliaBR: What's our impl status? Are we asking impl to change shipped things or is all still new stuff adding extra vertical-align keywords 16:08:19 present+ myles 16:08:34 florian: I don't think impl have switched to long hands except in SVG which doesn't have these keywords. 16:08:48 fantasai: I don't think alignment-baseline is in FF 16:09:11 AmeliaBR: THat' smy only concern. If we're changing after something has shipped not worth changing. If nothing has shipped I agree with fantasai this makes more sense 16:09:25 florian: MDN doesn't seem to know these have shipped, but it has a ? 16:09:29 fremy: We can check 16:09:40 fantasai: I can't get FF to do anything with alignment-baseline 16:09:50 oriol has joined #css 16:09:53 Rossen_: Doesn't sound like strong impl constraints 16:10:02 fremy: Not able to get FF to do something and I'm in FF dev. 16:10:25 florian: Alternative would be spawn another long hand but I'm not sure I'm excited about it 16:10:46 AmeliaBR: I suggested if these override both longhands but it gets confusing from cascade PoV 16:10:56 florian: It can't do something in the shorthand without doing something in long hand 16:11:17 Confirmed that Chromium doesn't support these keywords in alignment-baseline 16:11:20 according to this code, alignment-baseline is indeed not currently supported in Firefox: https://searchfox.org/mozilla-central/rev/eef39502e08bcd3c40573c65a6827828dce4a032/dom/svg/SVGElement.cpp#974-975 16:11:29 fantasai: Values are mutually exclusive with baseline-shift. You can't do shift and do top and bottom. B/C mutually exclusive might as well be same property 16:11:49 fantasai: Does anyone have other comments or should we accept and move on? There's arguments in favor of change and none against 16:12:01 dbaron: Seems only sort of exclusive. You can do top and down but not top and up 16:12:15 faceless2_: Spec says you can't combine them 16:12:29 florian: Browsers haven't impl syntax. But even if they did does it mean anything? 16:12:39 fantasai: Can't really combine. If you want to shift there's a lot of other ways. 16:12:46 dbaron: Okay with it. Makes sense to forbid it 16:12:57 Rossen_: Seems like leaning toward forbidding it. 16:13:06 Rossen_: astearns pointed out.... 16:13:20 florian: Have clarity, but not enthusiasm. Everyone leaning in that direction 16:13:27 Test: https://jsbin.com/hodevav/edit?html,output 16:13:28 tantek has joined #css 16:13:33 present+ 16:13:35 AmeliaBR: Resolve to accept change as proposed by fantasai unless strong impl argument? 16:13:40 Rossen_: That's the proposal, yes 16:13:45 Rossen_: Objections? 16:13:48 bkardell_ has joined #css 16:13:58 RESOLVED: accept change as proposed by fantasai unless strong impl argument 16:14:08 Topic: [css-inline-3] Rethinking line-sizing and leading-trim 16:14:14 present+ 16:14:16 github: ttps://github.com/w3c/csswg-drafts/issues/5168 16:14:20 github: https://github.com/w3c/csswg-drafts/issues/5168 16:14:39 present+ 16:14:40 fantasai: Combines a lot of ideas. I can go back over line-sizing. Might be helpful if people watch video b/c it has pictures. 16:15:45 fantasai: Line-sizing we had several discussions on size of lines. 2 properties. line-sizing which is between current model to use line-height of each inline box and draft line box over effective height. Problem is we get line larger than author wants b/c they set line height with slack. If they add stuff they don't want extra leading added to all the lines. That's one problem 16:16:04 fantasai: Tried to solve by using margin edges of content box which is usually top and bottom ascent/decent. 16:16:50 fantasai: Problem with that model is it works fine when line-height is big enough. Doesn't work when line-height is close to 1 b/c not extra leading for shift with something like font-family. Lots of times ascent and descent are noticeably taller than glyphs 16:17:35 fantasai: Other discussions were about leading-trim and how to handle setting inline. Trim or not. And if you're trying to figure out metric to trim maybe you want to set it doc wide and not figure out which each time you trip. Trim usually depends on language 16:17:41 q? 16:18:10 fantasai: Might makes sense to rethink relationship between these. Prop was switch to a model where leading-trim is a switch if you trip and a separate property to say what is top and bottom edge of text for inline layout 16:18:30 dbaron: What does seoncd property do? Just leading trim or other things? 16:18:36 fantasai: Just leading trim 16:19:20 florian: leading-trim just trips start end or none. First says where you trip if you do and it's the switch between legacy and normal with variants of normal that lets you pick something else than text-top and -bottom and let syou switch to a different font metric for line sizing 16:20:23 florian: General feeling is this is going an interesting direction. if it will work depends on details which are not fleshed out. Example when we trim what do we trim. Layout box, content box? WHne trim to metric is it first available font, tallest font? Without trying varients of these I have a hard time convincing it works right, but it's worth exploring 16:20:57 Rossen_: Feel like we can make more progress on this issue except that its' worth exploring? 16:21:18 fantasai: This was one of the main issues to discuss. We can wait 5 mintues for people to think. If people need a week we need to wait 16:21:25 dauwhe: Wish we had a whiteboard 16:21:31 florian: Very much so. 16:21:39 ii 16:21:52 [fantasai works on projecting her whitboard] 16:22:20 https://user-images.githubusercontent.com/5687700/84923354-1d839600-b095-11ea-927c-cb17ab91de78.png 16:23:09 dauwhe: I put in an old drawing trying to understand sin of a superscript in a paragraph messing up spacing and it labels some font metrics. Would love to understand better how options effect this 16:24:27 florian: Switching between legacy and margin-box would let us not take into account green part of 5. Being able to have metric helps. Let's assume top of ascent in yellow is more far away than ink of 5. A different metric you'd be able to trim more. Ink of 5 is out of bounds. MIght be able to have enough slack on line before we could increase but nothing in the proposal does that. Can get rid of green and some of yellow 16:24:42 dauwhe: In real life all of yellow box fits bottom half leading of previous line 16:24:49 florian: Yes if there is one and not something there 16:25:01 dauwhe: Yes, it's a middle of block sort of example 16:26:51 [more whiteboard set up] 16:27:30 http://fantasai.inkedblade.net/style/talks/vertical-rhythm/slides.pdf 16:27:43 fantasai: We have a whiteboard, we have diagrams from dauwhe, we have these slides^ which I'll start with 16:28:11 fantasai: Slide 52 shows [draws] 16:28:48 fantasai: You've got a line box and another line box and another [they're stacked on top] You have leading above and below 16:29:33 fantasai: The line gap is the leading of the two boxes that are adjacent. You have text that's in the line box. Does it fit in the line box or do we need to increase 16:30:09 fantasai: Traditionally each element has its own leading. If we trim it out then can still have a different font which may or may not fit in line box. Depends on ascent or descent. 16:30:26 bradk has joined #css 16:31:04 present+ 16:31:10 fantasai: When trying to figure out if something fits in line-box we need to ask what is bounds of thing and what do we consider fitting in the linbox? Do we assume half-leading on the next box and take that and boundries [assumed gap], include the leading. 16:31:19 fantasai: We take assumed gap when we're doing Ruby. 16:31:29 fantasai: That's one question we haven't covered yet 16:31:49 fantasai: Other question is what is the metric on text which we consider fitting. What is the size of the thing. 16:31:56 q+ 16:32:18 fantasai: What I'm trying to answer is can we change what it means for the thing we're trying to align. What's the size of the inline box we care about to try and fit inside hte line box 16:32:33 I assume that using the assumed gap will still avoid collisions with previous line descenders because the gap only includes the previous half-leading 16:32:51 fantasai: Current is use the line height, but that's bad b/c includes half leading and we don't care about that. New is use margin-box edges which coinceisde with ascent and descent in most cases. 16:33:29 fantasai: Some fonts it matches height, some go a bit heigher for accents, some a lot higher for acents. So you end up with a lot of vertical space being considered. 16:33:46 q? 16:33:54 fantasai: Combining metrics iwith inheritence you let author say I only care about cap height and don't care if ascender leak. 16:34:07 gtalbot has joined #css 16:34:12 fantasai: Trying to tak eleading-trim which is non-inherit, use the metric, and put it in an inheritable property. 16:34:27 fantasai: Can also say do we care about fitting and should we make what the default 16:34:45 fantasai: Making the linebox work for dauwhe use case it's what is size of inline box and what is size of linebox for purpose of fitting 16:35:02 fantasai: Prop is saying let's put some controls over what inline box is and allow it to trim to particular metrics. 16:35:07 fantasai: Making sense? 16:35:17 Rossen_: I don't think you need to explain again. We have a queue 16:35:24 drousso has joined #css 16:35:31 Rossen_: Quick ask to mute on webex if you're not talking. 16:36:01 [webex usage tutorial] 16:36:36 ack florian 16:36:55 goal rendering: https://user-images.githubusercontent.com/5687700/84924250-4193a700-b096-11ea-8149-0266693b8f84.png 16:37:21 florian: The original proposal/issue wasn't discussing if we're using assumed gap. Combo of explaination and picture from dauwhe makes this interesting. Depending on what sticks out this design, unlike previous, lets us introduce another propertyt hat lets us pick between linebox and ssumed gap 16:38:19 florian: We'd be lacking something to decide text bounds if we do jsut that. This gives us the switch as opposed to previous design which coupled to leading-trim. Now it's re-usable and you can decide. Convinced me more this is right direction. My inclination is start spec this knowing it's not final but with sense it's better 16:38:29 q? 16:39:07 dauwhe: In general I like this idea of almost being able to pick how these stack up 16:39:16 dauwhe: Pick which edge will contribute here 16:39:35 dauwhe: I don't think I can say more and have it mean anything without making drawings for myself so I understand 16:39:58 q+ to ask what happens when the text doesn't fit 16:40:06 florian: If we say pick one do we mean metrics of first available font or of all used fonts. Is there a correct answer or a switch. Don't want a switch but not sure which 16:41:09 fantasai: If we're going with this model means that you're going to consider content of descendant inlines. Each inline will contrinue an edge. If contents are different font they contribute their edge. Multiple fonts on a line the line box will go from highest top to lowest bottom. Currently ascent+leading, in future have other options. 16:41:37 fantasai: At that point makes sense to consider fallabck fonts. Once trimming not adding a lot of excess so by default considering fallbacks is where I would start 16:41:43 florian: Range in there 16:42:17 fantasai: That would be appropriate place to start and if need stricter can add. Lots of cases where we mix fonts so weird if you say I wont font-height of this and it chops 16:42:56 q+ 16:43:03 florian: If we start from content box and add padding & margin if we trim from that difference from content box and union. Content box is only first available so how do we trim from first available to all font metric. I buy everything you said so I'd try that direction 16:43:09 fantasai: Feels like follow-up issue 16:43:12 q? 16:43:15 florian: Yeah, probably 16:43:30 myles: 2 questions. First is what happens when text doesn't fit? 16:43:33 ack myles 16:43:33 myles, you wanted to ask what happens when the text doesn't fit 16:43:35 fantasai: Increase linebox height 16:43:38 myles: Just the one? 16:43:42 fantasai: Yes. 16:44:06 myles: When you drew you did black lines and than added red text. Is that the model where red text tries to fit in lines? 16:44:49 fantasai: Yeah. Weither this proposal or not we only accept positive leading on root inline box so the text inside the root inline are going to care that they fit in the leading bounds. If they leak outside we increase. 16:45:55 fantasai: Baeline of root inline will be here and they will try and fit. In either model we don't care if some text is big enough to go into leading area. If it's a bit too big it's fine. Question is what if it's big enough to go outside leading of own root inline. DO we stretch line for that case or assume half leading of previous line belongs to this. 16:46:13 fantasai: Stricter and looser model. In no case do we apply positive half leading to inline boxes inside 16:46:22 dbaron: I think myles asked if changes order of impl 16:46:26 fantasai: I don't think so 16:46:32 dbaron: I think the answer is no 16:46:51 Ms2ger has joined #css 16:46:57 florian: Spec is you align based on baselines and add leading and margin boxes if you need. Then you draw linebox around them all 16:47:25 myles: And in this model you do all the layout, draw a black box and it's only determined by primary font metrics and than adjust form fallback fonts? 16:47:31 florian: Tricky b/c lots of similar names boxes 16:48:21 florian: Inline boxes have 2 models depending on line-height normal. If it's normal inline box takes into account all actually used fonts incl font fallbacks. Anything other than normal then it's jsut that size that's set. Only take metrics of first available font into account to figure out where baseline goes. 16:48:25 q? 16:49:09 florian: On your time there may be more than one box. Once all inlines are in box you do top of tallest to bottom of deepest. Depending on how each box was sized is lineheight. WHat top is previous question. Top of margin box or add leading. Legacy is we add leading which is prob not what we want. 16:49:18 florian: New model is margin box which doesn't have leading 16:49:24 Rossen_: myles does that address your question 16:49:27 myles: Think so 16:50:08 fantasai: linebox model doens't change, jsut changing what is top of each box. Even if doing assume gap we can do it in same way. Only calc layout bounds of each inline box. 16:50:37 fantasai: In legacy it's defined as line-height. New it's text metrics based. Model on how you calc line height is not changes. 16:50:52 Rossen_: Couple of people on queue then break. 16:51:11 q? 16:51:12 Rossen_: We've made progress on understanding. Let's drive to conclusions 16:51:22 ack jfkthame 16:52:13 jfkthame: Question of if we're trimming through method like cap height would that be on first available. My instinct is to say only first available is better answer. Thinking from experience of page design where stability and predictability is of great value and if we merge metrics of fallback fonts it gets difficult as a designer to figure out what's going to happen. 16:53:01 fantasai: Main concern is to extent we've been using looser metrics that works better. When mixing fonts there's slack. Bringing to tight metrics I'm afraid you'll have substantial ink overflow when yous witch fonts. 16:53:37 jfkthame: I can see that. Counter by saying these are controls that will only be used by designers looking for careful control of content. If want to allow some stuff to leak that's their choice and we shouldn't stop them 16:54:10 myles: General principle website designers don't know if webfonts will load. THat's choice of user. We should be resilient to if different font that designer wanted. 16:54:45 fantasai: And you could have picked a lovely script and get chimera fallback. Trying to make sure text is readable even when unexpected thigns happen. 16:55:05 q+ 16:55:09 fantasai: If your font loads properly you get what you want but if you have a fallback thing bias toward fitting by default makes sense to me. 16:55:23 fantasai: I think it is secondary to issue. We can open a separate item on fallbacks 16:55:27 Rossen_: Reasonable. 16:55:33 q- 16:55:35 dbaron: Two comments 16:55:41 q+ to propose a resolution 16:55:49 ack dbaron 16:55:54 s/lovely script/lovely multi-script font/ 16:55:57 dbaron: One is about the question someone asked about which of this applies to first available font vs all 16:56:11 dbaron: Maybe that wasn't quite the question 16:56:49 dbaron: It was. First or all fonts. In this proposal that's only for text over and udner not leading leading looks at root inline box so only one font. I think that's the model for this purpose. 16:57:26 dbaron: Second is text edge over and under having 2 properties is weird in some cases but nec. in others. For leading and normal want one but for metric values you can't. Wonder if this should be one property that takes one or two values 16:57:32 fantasai: Either way should have shorthand 16:58:30 fantasai: I think we should push fallbacks or not to a separate issue. Look at overall structure of these properties 16:58:40 Rossen_: florian you want to propose a resolution? 16:59:39 florian: Noting that the previous proposal is marked as rough in the spec. Even if this isn't fully fleshed out including question of short/long or properties and question of fallbacks. I propose we replace the current vague proposal with this vague proposal in the spec and add these as issues to keep drilling down. 16:59:57 florian: I haven't heard arguments that led to us preffering the old model. 17:00:47 Rossen_: Let's give a 5 minute break. If there are people that have to skip that's fine but we prefer you skip. Stretch, get water, and think about florian proposal to swap the old model with the currently proposed one. 17:01:06
17:07:08 scribe+ dauwhe 17:07:18 Rossen_: let's go back to it 17:07:26 ... Florian was talking about a proposal 17:07:36 ... take this new model and replace the old model with it 17:07:44 ... and then continue to work on it 17:07:53 ... can we do that? do we have enough info to make that decision? 17:08:11 +1 17:08:40 Rossen_: any objections to the proposed resolution 17:08:46 ... I hear no objections 17:08:50 RESOLVED: Adopt new model described in the issue, continue working on it 17:09:19 Topic: [css-inline-3] line-height < 1 in a margin-box line layout model 17:09:33 github: https://github.com/w3c/csswg-drafts/issues/5178 17:09:59 fantasai: when we apply line height with positive half leading that's good 17:10:05 ... if we have negative half-leading 17:10:13 ... the size is less than the height of the font 17:10:21 ... line-height: .8 17:10:38 ... the ascent and descent of the font--you have to slice off the bottom part and take this as layout bounds 17:10:54 ... in the new model we're not applying line-height to inline boxes 17:11:11 ... this one doesn't get half leading, so it gets taller 17:11:27 ... but we still have to reduce the size of inline boxes when there's negative half leading 17:11:50 ... the proposal says we have to apply negative half leading... do we reduce the size of content box or margin box? 17:11:57 ... in the proposal we say margin box 17:12:03 ... what do people think about that? 17:12:14 Rossen_: is there a reason for it to be other than the margin box? 17:12:20 ... I think that makes sense 17:12:25 florian: yes, it makes sense 17:12:26 myles, the diagram is similar to slide 52 in the slide deck, fwiw 17:12:41 ... but if we would affect painting, it would be weird 17:12:47 ... so it should be margin box 17:12:56 Rossen_: any other opinions? If not, we can resolve. 17:13:00 ... any objections? 17:13:14 dbaron: not an objection 17:13:18 ... the idea is fine 17:13:37 ... what do numbers multiply by? Are they still what they used to mulitpyly by? 17:13:41 fantasai: that's a good question 17:13:50 myles: what's the argument to change? 17:13:56 fantasai: if you want fixed you can set fixed 17:14:00 myles: can you use px? 17:14:02 florian: yes 17:14:14 dbaron: but it's weird to do that because it inherits 17:14:33 fantasai: I would say we treat them the same as currently 17:14:44 ... youre trying to reduce size of line boxes by 205 17:14:50 s/205/20%/ 17:15:12 ... you want ascent/descent to be shrunk a bit, to get the affect of setting solid 17:15:26 dbaron: is the condition less than one, or what would make it less than the margin box 17:15:35 fantasai: A+D doesn't necessarily add up to one em 17:15:53 myles: that works even if line height is PX 17:15:55 fantasai: yes 17:16:16 Rossen_: are we ready to resolve? 17:16:18 fantasai: I think so 17:16:28 ... any objections? 17:17:07 Resolved: apply negative half leading to margin box edge 17:17:43 Topic: About the central baseline 17:17:52 github: https://github.com/w3c/csswg-drafts/issues/5177 17:18:00 fantasai: i raised an issue about central baseline definition 17:18:12 ... halfway between text top and text bottom, which are not defined 17:18:21 ... and it's the default baseline in vertical writing mode 17:18:26 ... which isn't interoperable, which is bad 17:18:40 ... we need a good metric for Vertical writing and CJK 17:18:51 ... which is halfway between ideographic top and ideographic bottom 17:19:04 ... we could just define to be exactly that 17:19:18 ... or create a new keyword for ideographic central 17:19:31 ... but I think we should make central the ideographic baseline 17:19:41 ... comments or questions? 17:19:59 florian: don't have a great sense of the fallback when ideographic baselines aren't there 17:20:15 AmeliaBR: use ascender and descender heights to define edge of em-box, and halfway between? 17:20:26 ... that gets messy because of different values of asc and desc 17:20:39 ... and there are different names for metrics 17:21:02 ... if we're using central alignment on a font not designed for it, and the font is badly broken, then you get bad results 17:21:14 florian: are there vertical languages that are set upright? 17:21:22 ... does ??? use it? 17:21:34 fantasai: ??? uses same as chinese 17:21:37 s/???/Yi/ 17:21:53 AmeliaBR: the OT fallback fallback for center on vertical axis is to assume glyphs use full em-height 17:22:07 ... you'll get weird results if glyphs are narrower 17:22:08 s/are there vertical languages that are set upright/are there vertical languages that are set upright and whose fonts don't have ideographic top/bottom metric/ 17:22:15 s/Resolved:/RESOLVED:/ 17:22:34 fantasai: the proposal is to define central baseline to be the ideographic baseline 17:22:47 ... and if that's missing fall back to half between ascent and descent 17:23:07 AmeliaBR: the CSS definition continue to use the concept of em-box 17:23:14 ... if not explicitly defined 17:23:43 wfm 17:23:49 fantasai: if the font has an explicit ideographic, use that. If not, use halfway between ideographic top and bottom. If that's missing, halfway between ascent and descent 17:23:54 Rossen_: any objections? 17:24:49 RESOLVED: Define the central baseline so if the font has an explicit ideographic central baseline, use that. If not, use halfway between ideographic top and bottom. If that's missing, halfway between ascent and descent 17:25:35 Topic: line-height: normal' definition should reflect reality of determining based on fonts 17:25:47 github: https://github.com/w3c/csswg-drafts/issues/1254 17:25:52 fantasai: lots of talk about what line-height: normal does 17:26:02 ... I went through the minutes, and incorporated into the spec 17:26:11 ... one question: how fonts own line gap metrics are handled 17:26:27 ... when they are there, we split the gap so half above and half below 17:26:38 ... I think it only affects the height of the line box 17:26:40 q+ 17:26:43 .... so I put that in the spec 17:26:49 ... I wanted to confirm that with the WG 17:26:56 ... that what is now in the spec is acceptable 17:27:20 myles: is this a question of researching of what browsers do? Make fonts with varying line gaps and see what happens? 17:27:36 florian: at least start with finding what it is 17:27:56 dbaron: my memory is that gecko's choice of whether to use the line gap metric is complex 17:28:14 florian: I agree that line gap does not affect height of content box 17:28:22 ... I didn't test vertical align 17:28:23 q- 17:28:44 myles: rather than asking us to remember what our browsers do, better to test the browsers? 17:28:54 ... I'm happy to make a bunch of fonts to help 17:28:54 s/complex/complex, and that what it affects is what number line-height: normal means/ 17:29:19 florian: we can split it up. we'll make fonts and test 17:29:35 Rossen_: how shall we resolve? try to match reality of current implementations? 17:29:51 fantasai: we can leave the issue open until we have definitive test results 17:30:02 ... I'll make sure that what dbaron said is allowed 17:30:09 ... the rest is already in the spec 17:30:19 ... if people want to review, that would be great 17:30:28 ... and I'll ask if I should publish a new WD? 17:30:32 q+ to talk about 90 minute meetings 17:30:39 Rossen_: a new WD would include edits with today's resolutions? 17:30:42 I don't think I mentioned using the line gap metric of a different font... 17:30:48 fantasai: yes, I'll make those edits before I publish 17:30:53 Rossen_: any thoughts? 17:30:56 q? 17:31:17 Rossen_: hearing no pushback 17:31:50 RESOLVED: publish updated working draft of CSS-Inline 17:32:05 myles: 90 minutes is too long for m 17:32:07 ...e 17:32:12 ... we made good progress 17:32:21 ... don't we usually just let the agenda overflow 17:32:29 ... I'd rather have lots of topics for the future 17:32:40 fantasai: I had things lined up this week, which was why 17:32:48 s/things lined up/deadlines/ 17:32:55 Rossen_: most people had similar sentiments, Myles 17:33:04 ... maybe we don't repeat this, unless at F2F 17:33:20 ... there's a thread on Private ML about upcoming F2F planning 17:33:25 ... thanks everyone 17:33:39 I also figured that the line sizing topic would take awhile and wanted to make sure we had the time to dig into it rather than skimming over it over the course a few calls 17:34:01 I think this helped 17:34:36 Topic: end 17:34:52 Zakim, end meeting 17:34:52 As of this point the attendees have been florian, fremy, dholbert, dael, Rossen_, alisonmaher, dauwhe, stantonm, AmeliaBR, fantasai, faceless2_, argyle, miriam, jfkthame, 17:34:55 ... castastrophe, rego, jensimmons, myles, oriol, bkardell_, tantek, bradk 17:34:55 RRSAgent, please draft minutes 17:34:55 I have made the request to generate https://www.w3.org/2020/06/17-css-minutes.html Zakim 17:34:57 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 17:35:02 Zakim has left #css 17:53:14 Karen has joined #css 18:59:33 Tavmjong has joined #css 19:03:16 futhark has joined #css 19:44:58 projector has joined #css 19:45:28 leaverou has joined #css 19:45:59 Rossen has joined #css 19:46:29 shans has joined #css 19:46:59 sylvaing has joined #css 19:52:21 futhark has joined #css 19:54:16 zcorpan has joined #css 20:52:39 NavidZ_ has joined #css 21:04:17 drousso_ has joined #css 21:04:31 oriol has joined #css 21:23:32 Karen has joined #css 21:34:31 foolip has joined #css 21:35:44 kereliuk has joined #css 21:37:29 fantasai: hey, sorry I missed today's call, but something came up at home... It hasn't been recorded right? I guess I'll read the minutes anyhow but :) 21:37:52 fantasai: (I've heard there was a presentation, which may not show up in the minutes) 21:38:11 Travis has joined #css 21:38:12 emilio: I drew some diagrams on the whiteboard 21:38:36 ah, dholbert made it sound much more professional ;) 21:38:40 lol 21:38:58 fantasai: I guess I'll just ask if I have any question :) 21:39:06 emilio: I'd recommend looking at the diagrams that dauwhe posted, and watching the video linked in issue 5168 21:39:34 emilio: What was drawn on the whiteboard was mostly very bad scribbles representing some of those diagrams :p 21:39:43 lol 21:40:04 fantasai: heh, great... I guess I have something to watch today to try to catch sleep (and then tomorrow if I actually catch it lol) 21:40:13 lol 21:42:31 majidvp has joined #css 21:43:46 futhark has joined #css 21:43:51 NavidZ_ has joined #css 21:53:52 yoichio has joined #css 21:57:45 dauwhe has joined #css 22:03:50 drott has joined #css 22:04:17 falken has joined #css 22:05:31 dauwhe has joined #css 22:08:57 gregwhitworth has joined #css 22:20:09 ankh___ has joined #css 23:03:38 Tavmjong has joined #css 23:07:02 dauwhe has joined #css 23:22:26 dauwhe has joined #css 23:28:22 futhark has joined #css 23:44:05 dauwhe has joined #css 23:54:53 dauwhe has joined #css