16:59:46 RRSAgent has joined #css 16:59:46 logging to https://www.w3.org/2021/01/13-css-irc 16:59:48 present+ 16:59:49 RRSAgent, make logs Public 16:59:50 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:59:52 present+ 16:59:55 can we get updated topic? 16:59:57 Rossen_ has changed the topic to: Agenda for Jan 13 at: https://lists.w3.org/Archives/Public/www-style/2021Jan/0003.html 16:59:59 present+ 17:00:01 thanks rossen ^_^ 17:00:05 present+ 17:00:05 ScribeNick: dael 17:00:47 una has joined #css 17:00:48 present+ GameMaker, jfkthame, argyle 17:00:54 present+ 17:01:02 present+ 17:01:05 present+ 17:01:08 present+ 17:01:15 present+ 17:01:18 Rossen_: Hey everybody. Let's give it another minute and then we'll get going 17:01:19 alisonmaher has joined #css 17:01:28 present+ 17:01:29 becky has joined #css 17:01:30 present+ 17:01:38 present+ 17:01:47 present+ 17:02:20 Rossen_: Let's get started 17:02:36 Rossen_: We have a full agenda. As usual I wanted to ask if people have any extra agenda items 17:03:00 Rossen_: Only reminder to give is about the upcoming F2F in February. 17:03:20 Rossen_: We have started to add the milestones to open issues. Feel free to mark agenda+ F2F for anything you want for the F2F. 17:03:27 Rossen_: Other details are in the private list 17:03:33 Topic: [css-cascade-5] Rename @layers to@layer 17:03:44 github: https://github.com/w3c/csswg-drafts/issues/5855 17:03:55 Rossen_: fantasai anything to add? 17:03:58 fantasai: Nope 17:04:09 oriol has joined #css 17:04:14 Seems fine 17:04:16 Rossen_: Any feedback or objections to renaming @layers to @layer? 17:04:18 I'm in favor 17:04:21 q? 17:04:23 tantek has joined #css 17:04:24 jensimmons has joined #css 17:04:27 present+ 17:04:29 in favor 17:04:32 Rossen_: Hearing no objects and seeing IRC support 17:04:33 present+ 17:04:39 RESOLVED: rename @layers to @layer 17:04:47 Topic: [selectors] Define how "legacy aliases" work on selectors. 17:04:50 jarhar has joined #css 17:04:50 Rossen_: Is emilio on? 17:05:18 present+ 17:05:20 present+ 17:05:23 myles has joined #css 17:05:25 [waiting for emilio to join] 17:05:36 github: https://github.com/w3c/csswg-drafts/issues/5847 17:05:38 present+ 17:06:08 emilio: Have a couple places where we define a selector where for legacy reason can be impl as alias but no definion of that. 17:06:09 present+ myles 17:06:10 IanPouncey has joined #css 17:06:18 emilio: Came up as I did compat work on other pseudo classes. 17:06:35 emilio: Compat can change what needs to be done but seems as if we should have guidance on how this should work 17:07:02 emilio: afaict two options are keep zeroizing the non-standard or convert them at parse time 17:07:14 smfr has joined #css 17:07:24 emilio: Some inconsistencies in Blink. Gecko should always turn it intot he stanrdard at parse time. I think that's what we do for properties in general 17:07:38 dholbert has joined #css 17:07:42 present+ 17:07:44 Rossen_: Prop is align more closely with converting at parse time 17:07:48 present+ 17:07:55 Rossen_: Questions or should we resolve on that? 17:08:01 Rossen_: I'll take silence as no 17:08:09 Rossen_: No comments or objections? 17:08:28 Rossen_: I see support in GH from TabAtkins 17:08:34 present+ chrisL 17:08:38 RESOLVED: convert at parse time 17:08:45 Topic: [math] [css-fonts] Solution to mixing text and math fonts in a document 17:08:54 Rossen_: Do we have folks to discuss these MathML issues? 17:09:15 Rossen_: fantasai you added this to agenda a while back 17:09:22 github: https://github.com/w3c/csswg-drafts/issues/5534 17:09:34 Rossen_: Silence I will take as not ready. 17:09:37 github: none 17:09:45 bradk has joined #css 17:09:47 Rossen_: We'll backlog at this point and remove agenda+ 17:10:04 Topic: [css-display] math/inline-math 17:10:12 github: https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-745563829 17:10:30 Rossen_: Is this something we can resolve now and move forward and if anyone has issues we can reopen 17:11:04 fantasai: Mats prop that display:math outside of MathML should make element behave as an em row. I agree with Mats but Fred thinks more complex to impl. Mats had impl and didn't think it was complicated 17:11:15 Rossen_: Who was push back on complexity? 17:11:19 fantasai: Fred 17:11:39 https://github.com/w3c/csswg-drafts/issues/5385 17:11:44 emilio: Also issue of display:math doing magical things depending on which element. Is there a different issue on that? That's the other concern Mats had 17:11:57 fantasai: Should be a different issue on that one 17:12:15 https://github.com/w3c/csswg-drafts/issues/5385#issuecomment-700070423 17:12:16 emilio: I don't [missed] in order to discuss right now 17:12:23 Rossen_: Doesn't sound like we're ready to discuss 17:12:44 s/[missed]/mind filing it, no need to discuss right now 17:12:47 fantasai: I can't present Fred's PoV. I can point you on the comments. I agree with Mats so could represent that. 17:12:56 Rossen_: Let's push this on back to the backlog as well 17:13:04 Rossen_: Perhaps these can be F2F topics 17:13:24 fantasai: You need to schedule them when the people you want to show up will show up. It's been end of agenda so no one knows to call in 17:13:33 astearns: I pinged everyone involved and didn't get a response 17:13:41 Rossen_: Likewise. It's not for lack of trying 17:13:52 Rossen_: There are going backburner and those that care can bring them back 17:14:00 Topic: [css-pseudo-4] painting of the cursor and the caret with highlight pseudos 17:14:08 github: https://github.com/w3c/csswg-drafts/issues/4100 17:14:36 present+ 17:14:57 q+ 17:14:58 fantasai: florian asked hwat happened with multi highlights and different caret values. Which one wins. top or top non-auto. Top most non-auto makes more sense I think but I don't know. Is anyone planning to impl these properties? 17:15:33 Sorry, I need to drop 17:15:35 Rossen_: Regardless of plan to impl we should be able to define expected behavior. If top-most non-auto makes most sense we can resolve and when people impl if it's not the right choice we can discuss again then 17:16:15 florian: Alternative could be if no one thinks this is good to impl we could drop from list of elements that apply to this psedo element. These were added b/c not layout effecting. But if there's no interest we could drop them. 17:16:27 Rossen_: CHoices are drop it or top-most non-auto 17:16:37 q? 17:16:59 GameMaker: I wasn't on the call but I recall reading notes about issues with this and grammar and auto-spell check b/c loading resources could be a security issue 17:17:17 ack GameMaker 17:17:34 GameMaker: Maybe didn't understand discussion, but thinking that could be a reason to drop. In my impl I haven't looked at doing cursor or caret. Definitely would be more complicated to do. I'm in favor of just dropping cursor and caret 17:17:44 +1 to dropping. seems to add complexity for theoretical reasons 17:17:48 Rossen_: Anyone want to keep those? 17:18:06 florian: Not a strong want but it seems security only applied to one of the two. Caret color won't load resources 17:18:17 fantasai: But if no one wants to impl and there's no strong usecase we should drop 17:18:25 I'd be in favor of only reconsidering them if an implementor felt compelled to try implementing it (for whatever reason) 17:18:27 Rossen_: Objections to dropping caret-color and cursor? 17:18:36 RESOLVED: drop caret-color and cursor 17:18:57 bradk has joined #css 17:19:03 Topic: [css-sizing-4][css-contain-2] Revisiting auto-sizing when size-containment applies 17:19:11 github: https://github.com/w3c/csswg-drafts/issues/5668 17:19:41 present+ myles 17:19:50 IanPouncey has joined #css 17:20:13 vmpstr: A little background. We have content-visibility:auto Way it works is when element goes offscreen we add size containment and when it's on screen we remove. Can change the scrollbar size which is undesired. Added contraint-intrinsic-size to manage this. Works great as a placeholder b/c gives some size even when size containment applies. 17:20:54 vmpstr: Problem is it's hard to know the right size so scrollbar can still jump. When element is on screen as it rolls offscreen browser knows size that would cause scrollbar not to jump. There is a value it oculd take. Broswer knows but it's not exposed 17:21:02 vmpstr: I think script can get an estimate 17:21:36 vmpstr: Prop is add an auto qualification to contain-intrinsic-size which is when size containment is first applied and when content has been previously rendered remember that size and use it as the value. Else use placeholder 17:21:51 vmpstr: Daniel and Christian raised some points that it adds dependency on sequence of steps. 17:21:55 q+ 17:22:08 q+ 17:22:14 vmpstr: Wanted to bring to group. Hoping there's a solution that doesn't involve script. Maybe not this exact proposal, but this is what I have 17:23:09 TabAtkins: Point about non-determinism about exactly when size is recorded, while technically true it's a cost we eaten with animations. Style depends on exactly when it started so you know how far in animation you are. Since we've eaten that cost for animations I don't see why not here unless we think that was unavoidably broken 17:23:17 TabAtkins: We should think about htis the same as animation start 17:23:23 ack TabAtkins 17:23:27 ack smfr 17:23:29 bradk_ has joined #css 17:23:43 smfr's idea makes sense to me as well 17:23:48 it's what you'd get if you did this by hand anyway 17:23:58 smfr: Slightly different prop is spec this exactly same as resizeObserver. Timing is well defined. Write the spec so you get the same behavior as if you registered a resize on it and that's the same size as you'd get with snapshot 17:24:28 vmpstr: Good idea. Question is when do we snapshot. If you add size containment and change another style I guess you first process size containment and snapshot at that time? 17:25:00 smfr: I think you would use size from the most recent event loop steps where your resize observer would have fired and given an answer. Might be loop before a style change that effects containment 17:25:08 smfr: That's last thing you saw on screen 17:25:10 vmpstr: Makes sense 17:25:31 chrishtr: resizeObserver is when content-visbility content is unskipped, right? 17:25:46 vmpstr: On the contents of the element. On the element itself the observer would still fire 17:26:12 chrishtr: So a polyfill would put it on the element and when it fires set contain intrinsic size on that. And smfr proposal is do that without any script 17:26:32 vmpstr: Pretty much. I've seen a polyfill that does that. I'm not sure what to do with padding and margins. 17:26:43 chrishtr: ResizeObserver allow syou to observe different boxes 17:26:46 vmpstr: Then yeah 17:27:07 chrishtr: What if it was independent of content visibility. It restricts to the c-i-s property 17:27:31 vmpstr: Content visibility was motivation. Proposal is change to contain intrsintic-size to save off the value 17:27:39 chrishtr: Only do when size containment wasn't present 17:27:53 vmpstr: Right. And just snapshot at the time size containment starts being applied 17:27:54 q? 17:28:16 chrishtr: So if size containment isn't present that size is automatically reflected into contain-intrincis-size used value 17:28:27 bradk has joined #css 17:28:39 Rossen_: Hearing alignment on prop from smfr to align with resizeObserver. Are we happy with that and then will work on additional details in the issue? 17:28:40 q+sounds good to me 17:29:03 Rossen_: Objections to align the behavior of auto sizing for size-containment with that of resizeObserver 17:29:09 RESOLVED: align the behavior of auto sizing for size-containment with that of resizeObserver 17:29:23 Topic: [css-contain-2] Proposal: content-visibility: hidden-matchable 17:29:31 github: https://github.com/w3c/csswg-drafts/issues/5595 17:29:56 Rossen_: This issue can take a lot of time. Let's try to spend no more than 10 minutes on this. 17:30:39 jarhar: Hello everyone. Proposed content-visibility: hidden-matchable property. I added responses on GH to the questions from last time. Wanted to know if there are additional issues and if responses on GH suffice 17:30:45 bradk has joined #css 17:31:01 ack fantasai 17:31:14 fantasai: Once concern is if the control should be in css or in markup. Might be good to ask TAG about that. 17:31:31 fantasai: Details about this the main question is what operations can and can't trigger matching 17:32:05 +1 to fantasai's concern, "matchability" feels like an expression of more semantically relevant content and thus may belong more in markup rather than in styling. 17:32:10 smfr: I think chris's last comment is a good summary of my discomfort. I think TAG feedback would be good. There are features in UAs that vary and this prop has impact on those features. TAG level discussion would be great 17:32:31 s/Details about this the main question is/Other than that, main question is defining details of/ 17:32:36 Rossen_: I'm scrolling through open issues. I see the match event open from jarhar. Is there another active one with TAG? 17:32:44 jarhar: I believe I do have a TAG review open. 17:32:49 https://github.com/w3ctag/design-reviews/issues/511 17:32:56 jarhar: Issue #511 on TAG 17:33:12 Rossen_: I believe that's scheduled to discuss during TAG F2F in a couple weeks 17:33:27 chrishtr: and the concern from smfr has not been yet discussed in TAG correct? 17:33:32 jarhar: Not that I know of 17:33:57 Rossen_: We have this issue crosslinked to TAG review. As the review with TAG we'll have the CSS issue as well for more context 17:34:08 agreed with the reader-mode and screenreader semantics concerns comments in the issue 17:34:10 Rossen_: What I'm hearing right now is a pause on this issue until we have TAG review 17:34:14 Rossen_: Then bring it back here 17:34:34 Rossen_: Also heard concerns from Sam. That's the summary. Is that fair? 17:35:03 chrishtr: smfr you said you have discomfort. I guess not swayed by our arguemnts. But if TAG doesn't think it's a big problem you're okay? 17:35:44 smfr: If TAG is okay I'm okay. For example I got pinged by devs about what are a11y for hidden-matchable. There is ambig around a11y and reader mode. Prefer to resolve but understand why it exists 17:35:53 chrishtr: It's potential for dev confusion? 17:36:11 smfr: Dev and user. They ctrl f in reader mode but spotlight doesn't find it and that's confusing 17:36:16 chrishtr: So we'll take it to TAG 17:36:37 +1 smfr 17:36:37 chrishtr: Your comments, fantasai, are good to consider. We shoudl work that out once we have consensus on smfr's issue 17:36:43 We definitely don't want to create new CSS where the a11y best-practice is confusing and unknown. There should be calrity. 17:36:43 q? 17:36:44 *clarity 17:36:50 Rossen_: Cool. With that let's move forward 17:36:57 Topic: [css-pseudo-4] Fine-tuning ::first-letter punctuation pattern matching 17:36:59 +1 jensimmons. agreed that's a good general methodology 17:37:05 github: https://github.com/w3c/csswg-drafts/issues/5830 17:37:50 fantasai: Problems riased in terms of matching ::first-letter. Example in an issue a " b". When we added ability to include whitespace we chose to include word spaces 17:38:23 fantasai: Problem is we aren't considering what's on other side of punct. If spec only used to separate makes sense, but not always. We're picking up punct that should be attached to word following. That's a problem. 17:38:32 bradk has joined #css 17:38:52 fantasai: I think exclude word and no-break spaces on following side of letter. Maybe leading side but definitely following 17:38:58 Rossen_: Feedback on this one? 17:39:25 Rossen_: No feedback on it, I guess 17:39:38 +1 reasoning makes sense 17:39:40 fantasai: Objections to makeing word and no break spaces not included? 17:40:08 bradk has joined #css 17:40:11 jfkthame: No objection but thinking it should be same both before and after letter since that's less confusing. If they want a word space they need to use a different character no matter what 17:40:32 fantasai: Happy to exclude from both sides for consistency. word space isn't the correct character to use typographically anyway 17:41:06 Rossen_: Prop: Exclude word break and no break spaces on either side of the letter 17:41:08 Rossen_: Objections? 17:41:17 RESOLVED: Exclude word break and no break spaces on either side of the letter 17:42:21 fantasai: There are several classes of punct. One we don't want to include is opening punct after first letter. first-letter then { doens't make sense to include. In european lang there's spaces so it doens't matter much. For other lang there is no such thing and we're trying to get first letter. WE have opening punct class and that thosuld be excluded 17:42:47 fantasai: Two ambig classes that are common where I don't know how to handle cleanly. Least we can do is exclude the opening punct 17:42:56 Rossen_: Any feedback? 17:43:13 +1 on excluding opening puncts 17:43:16 bradk: Sounds reasonable 17:44:25 fantasai: Similar case with dashes. Not quite sure the conventions for dash after first letter. I suspect we want to exclude on following side, but I'm not entirely familiar. On leading side long dashes mark quotations. Not sure on following. Inclenation is also exclude dashes from following punctuation 17:44:31 I don’t have opinion about dashes 17:44:47 Rossen_: One resolution here? 17:44:49 fantasai: Sure 17:45:19 fantasai: Prop: Exclude dashes and opening punct (ps and pd in unicode) from following 17:45:33 RESOLVED: Exclude dashes and opening punctuation (ps and pd in unicode) from following 17:45:45 fantasai: I think that's if for now on this issue. Will need to come back, I think 17:45:53 Topic: [css-pseudo] ::first-letter should include currency 17:46:01 github: https://github.com/w3c/csswg-drafts/issues/5099 17:46:08 Rossen_: Has a test case in it 17:46:23 fantasai: Prop is we include symbols along with letters and numbers when looking for first-letter 17:46:43 fantasai: Makes sense and we should do it. Otherwise if you start paragraph with a symbol there isn't a first-letter. Blink and WK do this 17:46:49 Rossen_: Any reasons why we shouldn't do it? 17:46:49 should we include # also in case you start your paragraph with a hashtag? 17:46:56 +1 17:47:04 Rossen_: Obj to inlcude symbols when looking for first-letter? 17:47:17 RESOLVED: include symbols when looking for first-letter 17:47:37 Topic: [css-pseudo] ::first-line and line-height 17:47:44 github: https://github.com/w3c/csswg-drafts/issues/2282 17:48:16 fantasai: Is ::first-line about to effect root inline elemnt fragment. Then an issue about if line-height can be changed about first-line. Same question. 17:48:45 fantasai: Seems to me letter it effect makes sense. Prop: root inline fragment on the first line is inside the ::first-line and therefore is effected by changes in size 17:49:23 oriol: Clarify, it's not jsust being able to change line-height, but also set smaller then line-height in the block container or is block container the min value 17:49:38 Rossen_: Currently block container is the min and the prop here allow it to be smaller 17:49:53 oriol: Depends on impl. In FF block cotnainer is a min but in chromium you can reduce to smaller 17:49:55 q? 17:50:15 Rossen_: Which are we prop to change to? chromium or FF? 17:50:28 oriol: I think fantasai proposed chromium 17:50:36 Rossen_: So ability to set sizes smaller than block container 17:50:43 Rossen_: Additional comments or feedback? 17:51:09 RESOLVED: Align with chromium behavior for ::first-line and line-height 17:51:16 Topic: [css-pseudo] Multi-line ::first-letter 17:51:23 github: https://github.com/w3c/csswg-drafts/issues/2254 17:51:51 oriol: Problem is theoretically first-letter should be in first-line. If block container is narrow enough it can happen that first-letter will span multiple lines. 17:52:02 oriol: I had a proposal to try to define how this should behave. 17:52:07 oriol: Some parts to this proposal 17:52:17 bradk has joined #css 17:52:36 oriol: First would be to standardize what FF, old Edge, and WK do which is that if you don't have a typographic letter unit then the first-letter is allowed to match the punct. 17:52:51 oriol: If you have both punct and letter you incldue both. If you don't it's allowed to only have punct. 17:53:12 oriol: Second would be if first-letter could span multi-line we restrict it to first-line so it can inherit. 17:53:27 oriol: Browser that does both parts of this proposal is FF 17:53:55 Rossen_: Feedback? Any reason why we shouldn't adopt FF behavior? 17:54:32 Rossen_: Objections to adopt the FF behavior which allows us to...want to make sure we have right resolution 17:54:58 fantasai: Summary: first-letter speduo element is closed at the end of the line even if the content that would otherwise be part of it is wrapped to the next line 17:54:59 +1 that's a good summary fantasai 17:55:02 Rossen_: Objections? 17:55:20 RESOLVED: ::first-letter pseudo element is closed at the end of the line even if the content that would otherwise be part of it is wrapped to the next line 17:55:24 Topic: end 17:55:43 Rossen_: That's the end of the agenda. We can break 5 minutes early unless there's any other topics for discussion 17:55:56 Rossen_: Going once, going twice...let's get 5 minutes back 17:56:03 Rossen_: Thanks everyone, we'll chat next week 17:56:14 Zakim, end meeting 17:56:14 As of this point the attendees have been dlibby, vmpstr, dael, Rossen_, GameMaker, jfkthame, argyle, una, fantasai, miriam, cbiesinger, Morgan, alisonmaher, TYLin, florian, 17:56:17 ... leaverou, chrishtr, jensimmons, castastrophe, tantek, oriol, myles, dholbert, smfr, chrisL, plinss 17:56:17 RRSAgent, please draft minutes v2 17:56:17 I have made the request to generate https://www.w3.org/2021/01/13-css-minutes.html Zakim 17:56:19 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 17:56:23 Zakim has left #css 17:56:35 present + 17:56:41 Doh! 17:56:56 Don't worry, Dael will catch it :) 17:57:08 :) 17:57:14 RRSAgent, make minutes public 17:57:14 I'm logging. I don't understand 'make minutes public', tantek. Try /msg RRSAgent help 17:58:50 RRSAgent, halp 17:58:50 I'm logging. I don't understand 'halp', tantek. Try /msg RRSAgent help 18:00:37 From now on, I’m pronouncing it “halp”. 18:01:13 ... it has better ring to it 18:16:20 zcorpan has joined #css 18:18:12 zcorpan_ has joined #css 18:26:48 dholbert has joined #css 19:08:54 zcorpan has joined #css 19:09:29 zcorpan has joined #css 19:24:19 dholbert has joined #css 19:26:07 TabAtkins, do you mind if I merge https://github.com/w3c/csswg-drafts/pull/5848 ? It looks like the "merge pull request" button is available to me and it has one approval, but I don't want to tread on toes (& am unsure about process) since neither Chris nor I are editors of that spec. 19:26:49 dholbert: I merged it, but yeah, always feel free to merge typos and obvious things like that, it's fine. 19:26:56 (Tho "tho" wasn't a typo, but eh.) 19:27:55 TabAtkins, Thanks! Yup, I didn't realize that the spelling was intentional at first. 19:33:33 jamesn has joined #css 19:38:14 zcorpan has joined #css 19:42:31 fantasai, do you have a few minutes for a question about some sort-of-ancient css-paged-media stuff? 19:42:50 sure 19:43:38 fantasai, thanks! So I'm looking at the 'vertical-align' values that are provided in the table in https://drafts.csswg.org/css-page/#margin-text-alignment , which basically says that headers and footers should be vertically centered in the margin area 19:44:33 fantasai, ...but AFAICT no browser actually does that, for their default printed-page headers & footers. 19:45:06 ah, ok, I think I see what's happening 19:45:09 fantasai, (addressing one thing that confused me: there's a note a bit further up saying that "vertical-align" must behave in the same way that it behaves on cells) 19:45:26 It's basically saying, treat it like align-content, not like inline layout 19:45:38 right 19:45:40 I wonder if that shouldn't be handled more like align-self instead though 19:45:53 so that part's fine, but I'm wondering if centering is actually what we want the spec to require here 19:46:19 what would you suggest? 19:46:20 because AFAICT all browsers actually just place the headers at a fixed offset from the edge of the page 19:46:37 hmm 19:46:38 (or from the edge of the unwritable area) 19:46:43 Interesting 19:46:51 I think we'd have to check what the print implementations do 19:46:59 e.g. Antenna House / PrinceXML / etc. 19:47:08 They're the ones most likely to be sensitive to compat in this area 19:48:11 (my context here is that I'm changing how this works in Firefox, and I'm wondering what to change it to :) ) 19:48:17 :) 19:48:31 Yeah, feel free to open an issue 19:48:44 But if we want to define anything here, we've got to consider the various CSS to PDF implementations 19:49:11 I think wrt web content, we probably have a bit more flexibility than they do 19:49:13 (right now we draw page headers/footers to their extreme printable location, which is fine in some cases but bad if you're doing e.g. 4 pages-per-sheet and you're printing to PDF which has no unwritable area; it makes us render headers/footers smooshed together as in https://bugzilla.mozilla.org/attachment.cgi?id=9180351 ) 19:49:44 lol 19:49:47 (hence, I'm considering adding a bit of buffer, but ultimately it'd be great to have spec alignment) 19:49:58 sure 19:50:36 I'm not sure switching out the alignment rules would solve that particular problem though, isn't that info printed into the corner boxes? 19:51:07 so the spec says we should use `vertical-align:middle` there, which would at least solve the vertical-smooshing 19:51:28 horizontal smooshing might still be hosed though, even if we followed the spec 19:52:08 well, you can always apply a UA style sheet to the margin boxes to give them some margin :) 19:52:34 but yeah, I think margin box layout is a bit... inconsistently interpreted across specs and implementations 19:52:49 so I think there's some investigation that has to be done there before we do anything to the spec 19:53:16 makes sense. Thanks! 19:55:35 If you want to poke around, I think PrinceXML, Antenna House, PDFReactor, and Vivliostyle might be ones to check. 19:59:06 zcorpan has joined #css 19:59:42 dholbert, Murakami-san and faceless2 are also good people to chat with about this 20:08:47 Filed: https://github.com/w3c/csswg-drafts/issues/5870 21:19:50 zhengxu has joined #css 22:34:02 zhengxu has joined #css 22:39:42 zhengxu_ has joined #css 22:45:35 zhengxu has joined #css 22:49:55 zhengxu_ has joined #css 22:59:49 atrigent has joined #css 23:13:50 zhengxu has joined #css