00:00:36 RRSAgent has joined #css 00:00:36 logging to https://www.w3.org/2022/01/06-css-irc 00:00:38 RRSAgent, make logs Public 00:00:39 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 00:00:51 PeterC has joined #css 00:01:23 alisonmaher has joined #css 00:01:28 present+ 00:01:29 present+ 00:01:32 dlibby has joined #css 00:01:45 ScribeNick: dael 00:01:48 present+ 00:01:52 present+ 00:02:02 present+ 00:02:30 present+ 00:02:51 dholbert has joined #css 00:03:01 present+ 00:03:06 present+ 00:03:16 present+ 00:03:18 present+ 00:03:21 astearns: While we wait, does anyone have changes for the agenda? 00:03:41 florian: Item 0 should have been happy new year :) 00:03:47 astearns: Fair. 00:04:00 astearns: We'll skip item 6. Delan wanted us to skip that one 00:04:28 astearns: I believe first was from fantasai. Are you on yet? 00:05:03 astearns: Happy new year everyone. Thank you for coming back after the break 00:05:35 astearns: On private list we have a backlog so we'll look for a longer form meeting. If anyone has preference for when please post to the private list 00:05:38 Topic: [css-flexbox] Flexbox alignment and fragmentation 00:05:40 Rossen_ has joined #css 00:05:47 present+ 00:05:47 github: https://github.com/w3c/csswg-drafts/issues/6812 00:06:01 alisonmaher: This is about handling alignment when fragmeneting. Issue also applies to grid and tables 00:06:16 present+ 00:06:26 alisonmaher: According to spec it suggest align per fragment. Flexbox is only that makes this suggestion. Can confuse impl and may imply flexbox is unique. 00:06:39 alisonmaher: Would it make sesne to change to suggest align prior and can ignore 00:07:13 alisonmaher: Advantage of ahead of time is it layout more similar to non-fragment. Consiquence is how to handle margins. Spec says truncate at soft break and they can affect alignments so may not want to truncate 00:07:19 alisonmaher: FF does not truncate 00:07:39 alisonmaher: prop: update to match FF for margins during fragmentation and add similar language in grid and tables 00:07:46 iank_: broadly supportive 00:08:16 iank_: When fragmenting, doing it globaly somewhat makes most sense when you look. Otherwise you can get things in unexpected columns and not aligning at the end 00:08:52 astearns: I'm not entirely convinced of the preference for stitching back together in way that looks more like unfragmented, but not against the change 00:09:12 q+ 00:09:16 astearns: If there is a use case for align per fragment is that a switch we can add, maybe like how we do box decoration breaks where an author can choose? 00:09:29 dino has joined #css 00:09:36 iank_: Potentially. I think for that case what we might do is treat everything as start aligned and do alignment then 00:10:03 iank_: one thing that should be said is this would match what impl do in reality. Blink at the moment b/c we're adding proper fragmentation and fixing bugs 00:10:25 iank_: Theoretically possible to haev a switch. Place where per fragment makes sense is content-alignment. But that's different 00:10:31 dholbert: Justify content? 00:10:51 iank_: No, talking about...what's the keyword...we don't have it, I think only FF does. Let me look it up 00:11:13 dholbert: first-basline and last-baseline? 00:11:28 iank_: Ignore my last comment. I'm confused. 00:11:30 ack florian 00:12:09 florian: Usually when it comes to things that relate to fragmentation print formatters have spent more time on this. prince at least supports both fragmentation and flexbox. Might be worth looking at what they do. If it's not what we're proposing we should think about it more 00:12:19 iank_: This is slightly larger than flexbox since it applies to grid and table 00:12:26 florian: I don't remember if they do grid. Might 00:12:35 iank_: For grid doesn't make a lot of sense to do by fragment 00:13:07 florian: I don't have an objection, but given it applies to things important to print formatters it's worth looking at what they do. We can make a revision and put a to do to look and revisit if needed 00:13:24 astearns: Is there a good person to tag? I would go to Dave Cramer but I'm not sure how much time he has for CSS 00:13:28 florian: That was my answer as well 00:13:58 GameMaker has joined #css 00:14:01 present_ 00:14:05 present+ 00:14:07 astearns: Maybe we can tag Dave and see if he can give us an idea of what Prince is doing. Somewhat convinced we should take the proposal since it's what FF is doing. If there is a difference we can think again 00:14:19 dholbert: FF supports the change. It feels like most coherent thing to do 00:14:31 iank_: That's what I came to as well. It falls out to make most sense 00:14:49 astearns: Prop 1: We will spec that grid, flex, and table fragmentation align globally before fragments are created 00:14:51 alisonmaher: Correct 00:15:01 astearns: Do we need anything about margins in that resolution? 00:15:04 alisonmaher: Sep 00:15:13 astearns: Concerns about that resolution? 00:15:22 astearns: Obj? 00:15:26 RESOLVED: We will spec that grid, flex, and table fragmentation align globally before fragments are created 00:15:44 alisonmaher: Margins want when handling alignment globally shouldn't truncate margins at soft breaks 00:16:02 astearns: Can we do that without causing any cycles in determining if a soft break 00:16:18 alisonmaher: I think FF already doesn't truncate margins in flexbox case so I think there's a prior for it 00:16:50 astearns: Okay. Interested in seeing test cases we can apply for this. Seems to me lots of weird edge cases for particular kinds of margins. I suspect not well tested 00:16:52 alisonmaher: Yeah 00:17:01 astearns: Anything more to discuss about margins? 00:17:22 dholbert: Additional point, when doing global alignment the thing aligned is the margin box which is why it makes sense to preserve the margins 00:17:48 astearns: when we are aligning globally we will not truncate margins at any break 00:17:55 alisonmaher: We could say it generally 00:18:16 astearns: Prop: we will not truncate margins at any break when aligning globally for fragmentation 00:18:20 RESOLVED: we will not truncate margins at any break when aligning globally for fragmentation 00:18:37 astearns: Blink is going through this and will be adding new fragmentation code. Test cases as you go? 00:18:39 alisonmaher: Yeah 00:19:00 astearns: alisonmaher would you ping Dave Cramer? 00:19:01 alisonmaher: Sure 00:19:29 Topic: [css-conditional-3] Setting .conditionText interop is terrible 00:19:44 TabAtkins: Wait for fantasai on this 00:20:01 Topic: [css-values-4] Validity of generic interpolation function mix() 00:20:12 github: https://github.com/w3c/csswg-drafts/issues/6700 00:20:25 TabAtkins: Making sure we agree what generic interpolation does and if it's valid 00:20:38 astearns: Only concern is last comment asked for fantasai to clarify 00:20:50 TabAtkins: True. But not relivent for this, I think. 00:21:29 TabAtkins: We have a couple of mixing functions lick color-mix and calc. These functions have a type. Color-mix is a color, valid whereever a color is. But generic interpolation function, currently called mix, I don't believe can be same 00:21:53 TabAtkins: It can interp things without describable types. Interp of a box shadow is only valid in box shadow. 00:22:32 TabAtkins: Prop is mix is only allowed as top-level value of a property. That's all it would be produced as by UA, but if authors use it they could not combine with other things. Can't mix 2 box shadows and then add inset. 00:22:45 q+ 00:22:52 TabAtkins: I believe that's all this is about, verifying that's what we want for the grammar of this function 00:22:59 TabAtkins: If no one disagrees we can resolve 00:23:00 ack smfr 00:23:21 smfr: Questions- if you have prop with comma sep values like backgrounds, can you use mix in the list or is the whole list a mix? 00:23:26 TabAtkins: Great question. Hmm. 00:24:08 TabAtkins: I think still the entire thing. Even in lists of comma sep we can have distinct syntaxes at a position like bg where only color in the last. We couldn't interp a mix with a color unless it's final. So would have to be the entire thing 00:24:26 smfr: High level, how does this interact with animations? Can I use it in keyframes? 00:25:01 TabAtkins: SHould be usable anywhere that accepts a value. Value is generatable by an animation so it should be a valid value. You can interp to this. Things you can do by hand should allow explicitly. 00:25:11 smfr: keyframe? only animatable properties? 00:25:44 TabAtkins: Yes, if prop wasn't animatable then mix wouldn't have a meaning. Great question and not in spec. I suspect should be properties that are not animatable mix isinvaid at parse time. 00:25:54 smfr: If you can spec in keyframes implies mix can nest 00:26:06 TabAtkins: because you can mix between and mixed value and something? 00:26:08 smfr: Yeah 00:26:27 TabAtkins: True. Good clarification. mix should be able to be an entire argument of the mix. You should be able to mix mixes 00:26:37 smfr: Shorthands vs longhands when mix is the enitre value? 00:27:17 TabAtkins: We had an answer. I believe it needs to be similar to variable in shorthands, but don't recall exactly. Whatever it was, we can't rely syntaxtically that something is a shorthand so whatever we define has to work well for shorthands. 00:27:34 TabAtkins: Mix should be allowed in a shorthand. Exact interp I can't answer but should be as reasonable as can make it 00:27:38 smfr: SOunds good 00:27:47 astearns: Looking for resolution to define mix as only top level 00:28:01 astearns: Issue also talks about adding another lower level value. punt that for now? 00:28:06 TabAtkins: Yeah, it's separate 00:28:17 astearns: But if we expect lower question is which gets the shorter name 00:29:12 TabAtkins: My arguement is the existing lower-level have longer names like color-mix. Completely usuable anywhere should get the shortest name. no way to be generic low-level because we need to know type to parse. Interp at the value level will be type specific. mix should have short names and others longer and more specific 00:29:16 astearns: Other questions or ideas? 00:29:48 astearns: Prop: The mix interpolation function will only be used for top-level values with various discussed caveats 00:29:57 TabAtkins: Sound also resolve on name 00:30:08 astearns: And mix is the name of the top level interpolation 00:30:11 astearns: Objections 00:30:25 RESOLVED: The mix interpolation function will only be used for top-level values with various discussed caveats. mix is the name of the top level interpolation 00:30:43 astearns: Since this issue discusses lower level, is that captured elsewhere or should we open another issue 00:30:53 TabAtkins: One talked about is numeric and that does have an issue for it 00:31:01 astearns: I'll see if I can find it and link it 00:31:12 Topic: [cssom][css-break] getComputedStyle and fragmentation 00:31:22 github: https://github.com/w3c/csswg-drafts/issues/6513 00:31:53 florian: A while ago looking at def of gCS and it does not mention fragmentation. problem b/c element frag gives multiple answer to value of property. What to do? 00:32:24 florian: GH suggestion which is roughly okay with commentors is other APIs are fragment aware so people who want per frag should use those. This API we should do simpliest with tweak for compat 00:33:07 florian: Simpliest is return first fragment. Might need to tweak based on historic impl. Assuming hoz writing mode, height of the block chrome returns sum, though FF returns first. Probably not compat porblem there, but might have it elsewhere 00:33:25 florian: Suggestion is doc that gCS returns based on first fragment and we document compat issues sep 00:34:12 florian: Suggestion from fremy to make it a little smarter and answer on last for other writing modes. I think I would suggest not taking the suggestion. This will not be smart enough to describe everything so you need frag away APIs 00:34:31 florian: If compat dictates smarter this could be one of the things, but would rather not if we can keep it simple 00:34:54 TabAtkins: I think I agree. Don't think we can get smarter without being complex. Going with simple answer of first frag is easier 00:35:13 iank_: Not wild about first fragment. Larger set of problems about client width and height and how they interact 00:35:50 q? 00:35:57 iank_: In a lot of libraries they compute to witdh and height and used interchangably. Someone using this naively they would get unexpected results when printing. If you sum as I suggest in the issue you get broadly expected 00:36:13 iank_: I don't expect a large compat issue, but it's a little unintuitive 00:36:50 florian: Can we say unless documented we go with first fragment but with block dimensions we sum up. And maybe for padding, border, margin we take last for inline-end and block-end. Maybe that's enough of an excpetion? 00:37:12 iank_: What properties return funcy used? width height padding border margin? 00:37:19 florian: More. Offsets as well 00:37:36 florian: width height margin padding, top left bottom right 00:37:38 q+ 00:38:08 florian: Another complication is we're baking selectors that let you style different fragments differntly and then any property could have a different answer. Not exposed, but might be coming 00:38:42 iank_: With that we would start not to return...you can't really...a lot will break if you set different margin-top per fragment. Skeptical we'll need to do something for that case 00:39:19 florian: Even if we don't get that. for margin-bottom return the first, last, depend on box-decoration-break? If compat dictates we should take that 00:39:53 iank_: Rathr then applying general rule would be good to go through cases individually and come up with answers. I suspect I agree with amrgina nd padding for first/last fragment but width and height we want different. 00:39:59 iank_: It would be better to do case by case 00:40:01 ack Rossen_ 00:40:58 Rossen_: I'm more closely aligned with iank_ then the simplicity. Generally I'm all for simplier and more definitive answer. I believe there will be unfortunate compat breakage we'll see for apps building pagination-ish presentations 00:42:12 q+ 00:42:12 Rossen_: I've seen a number of apps using multicol to drive book-like experiences. For them, back in the time this is why we into getClientRects and go down patch of fragment aware things. Zooming out, not being able ot know where a box starts which is what you will run into if you only give results on first frag which could give you a result under the 2nd, that would be unfortunate 00:42:24 Rossen_: I'm closer aligned with iank_ 's point 00:42:27 ack florian 00:42:58 florian: Strongly agree we need something that's fragment aware. But gCS isn't fragment aware. As to breaking interop, we don't have interop. 00:43:45 florian: Another thing I forgot to mention is we don't need to get to fancy APIs to get into troble. We could sum heights, but what to do with width when frag have different width? Or an inline that breaks 2 lines? Block that's across 2 pages? No answer in the spec 00:44:03 florian: We can go property by property as iank_ said. Having done that for height there's no interop 00:44:32 astearns: Not that we break interop but that we break compat. There are likely sites that rely on Blink's behavior. Risk breaking them if we spec differently 00:44:43 florian: But if it's engine specific should we also not change FF? 00:45:20 Rossen_: If they don't have bugs they're either not used for these presentations or they've coded to adapt. I want to udnerscore the point about compat vs interop. I'd be more concerned about compat at this point 00:45:53 astearns: If concerned about compat and there isn't anything that we can spec as safe, perhaps we explicitly say gCS is not frag aware, different enginres return different and we don't spec what to do 00:46:00 florian: Not terribly helpful 00:46:25 astearns: It's not. but going through what to do with every layout property with interesting frag when we can't spec something interop, is that a wild goose chase? 00:46:58 Rossen_: Sounds more academic than applicable. Do we have use cases for alignment? These properties have existed for quite some time so people work around it 00:47:23 Present+ 00:47:43 florian: Confsed how it can be true simultaniously that this is sufficently used that we can't change but unused that we don't have to answer. If people aren't using this spec simple or say undefined. If it is used would be good to haev a known behavior for interop 00:47:57 smfr: Might have legacy content on each browser relying on the behavior 00:48:39 Rossen_: epub viewers are built against 1 engine and for these apllications they have very specific code with very specific behavior for the engine. Whatever that engine does is what they'll get 00:48:51 florian: Not so sure. Paginators are frequent cross-engine. 00:49:13 iank_: Specific example, a lot of people run chrome in headless to generate pdfs. A lot of people doing that 00:49:39 iank_: To my previous point, only properties we'd use layout dependent is margin, padding, width, height, and the insets 00:49:53 florian: Also borders. Sizes don't change but box-decoration-break might or might not have 00:49:57 florian: But yes, it's those 00:50:54 q+ 00:51:04 iank_: I wonder if we can go through these and pick what is reasonable. for example, for the edge type things, border padding margin and insets I'll agree picking first or last will be pretty compat. not huge burden on engines to sum on block and take max on inline 00:51:17 iank_: I think blink and wk do that already. Would be interested to hear for gecko 00:51:53 florian: Not particuarly hard. But in viviostyle there is a measure of lazy rendering for a many 1000 book and having a blocking call that forces you to layout isn't great. Maybe no way around 00:52:04 iank_: I can come up with examples that will render incorrect due to that 00:52:19 florian: Yeah. For block maybe no way around. For inline maybe we can just do first? 00:52:47 iank_: Yeah. I'd like this consistent with client height. A bit of precedence with inline element fragmentation. might be wrong there 00:52:49 ack chrishtr 00:53:03 chrishtr: No strong opinion, but maybe take this offline for specific proposals? 00:53:18 chrishtr: There is #6588 on the agenda which we need for progress 00:53:34 astearns: Okay, will go back to GH on this issue and get a list of properties we want to consider fully 00:53:45 Topic: [cssom-view] Needs more details for offsetWidth and offsetHeight 00:53:53 github: https://github.com/w3c/csswg-drafts/issues/6588 00:54:16 chrishtr: Discussed Oct 6 and resolved that they should be computed out of principle css box 00:54:35 chrishtr: If you have an inline split into mult frag with a child that's block shoudl the balance of the block be included 00:54:53 chrishtr: No strong opinion in discussion. Weak opinion not to, but impl difficulty should be a factor 00:55:36 chrishtr: Enginers have been trying to simplify code and have found that including it would be simplier to impl and give same answer as getBoundingClientRect. Suggest include block box in the bounds 00:55:40 astearns: Make sense. 00:55:59 astearns: Prop: When an inline box is split by a block box, offsetWidth and Height will include dimensions of block box 00:56:01 astearns: Obj? 00:56:10 RESOLVED: When an inline box is split by a block box, offsetWidth and offsetHeight will include dimensions of block box 00:56:32 Topic: [css-contain-3] What happens to other @rules inside @container? 00:56:40 github: https://github.com/w3c/csswg-drafts/issues/6827 00:56:55 miriam: Dealt with a version of this problem before 00:57:09 miriam: Containers don't have a global resolution. Specific to elements and contexts 00:57:27 miriam: Need to know if allowed and what happens to have global @rules like property or fontface inside @container 00:57:52 miriam: On thread agreed for these rules we think @container should be treated as true for all cases like these to be consisten with previous decisions 00:58:06 astearns: No difference in having @fontface inside or outside a container 00:58:07 miriam: Right 00:58:11 astearns: reasonable to me 00:58:17 TabAtkins: yep, agreed 00:58:35 dbaron: At first glance seems surprising. Are there other things that work this way? 00:58:41 astearns: Talked about layer order previously 00:59:04 miriam: Yeah, layer order. I feel like also some name defining @rules, but that's this so maybe we didn't. I think there was previous art on this 00:59:32 TabAtkins: Ultimately they're always true or false, we can't make them dependant on the query. The always true is consistent. But we oculd say it's always false if that's more reasonable. 00:59:48 dbaron: Curious why it's not syntax errors and drop. That was one of Rune's options 00:59:56 astearns: Would you like more time to consider and consult? 01:00:20 dbaron: If nobody else thinks it makes sense okay resolving. My intuition is if we don't know how to process it shouldn't be allowed 01:00:33 astearns: We can process fine. Slightly less surprising the rules don't disappear 01:00:37 dbaron: Maybe. Okay 01:00:56 astearns: We are at time. Prop: Property and fontface rules always work in an @container rule 01:01:09 miriam: Prior are was for @layer where @layer has no effect on name defining rules 01:01:12 s/are/art 01:01:23 astearns: Anyone want to chew on this more? 01:01:31 RESOLVED: Property and fontface rules always work in an @container rule 01:01:34 topic: end 01:01:53 astearns: Thanks for calling in for the first meeting of the year. We'll talk for the hour next week and have a longer call later in the month 01:21:19 zakim, end meeting 01:21:19 As of this point the attendees have been dael, alisonmaher, dlibby, smfr, heycam, miriam, TYLin, dholbert, TabAtkins, chrishtr, Rossen_, jensimmons, GameMaker, dbaron 01:21:22 RRSAgent, please draft minutes v2 01:21:22 I have made the request to generate https://www.w3.org/2022/01/06-css-minutes.html Zakim 01:21:24 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 01:21:28 Zakim has left #css 02:08:55 Seirdy has joined #css 02:09:11 dino has joined #css 02:39:46 hi miriam, tks for responding. i napped right thru until after the meeting. Yes, basically have to dup all unlayered into layer, too. e.g. with no option to toggle high/low priority for unlayered, and no @supports. bad news when trying to give basic layout/font/appearance to unsupporting UAs, which can't be overriden in a @layer supporting UA. 02:46:29 would avoid having to play !important games, which would be tedious in short order. 03:35:22 plh has joined #css 07:35:10 plh has joined #css 09:24:16 vit has joined #css 09:37:08 plh has joined #css 12:16:54 plh has joined #css 12:20:36 antonp has joined #css 14:05:14 tantek has joined #css 14:21:31 projector has joined #css 14:22:01 leaverou has joined #css 14:22:31 Rossen has joined #css 14:23:02 shans has joined #css 14:23:32 sylvaing has joined #css 15:01:53 jensimmons has joined #css 17:29:01 plinss: https://drafts.csswg.org/css-color/ is broken today. 17:29:03 CSSWG_LogBot has joined #css 17:30:48 kicked 17:45:52 @aja it seems to me that a polyfill or pre-processor tool would be more useful for generating those layer fallbacks. Since @layer is already starting to roll out in Gecko, Webkit, and Blink - any support rule that we add would likely have _less support than layers themselves_. I did find our previous discussion on this, for reference: https://github.com/w3c/csswg-drafts/issues/4985#issuecomment-628103163. 17:45:53 CSSWG_LogBot has joined #css 17:46:26 We can always revisit if needed, so feel free to revive that thread if you want to propose a different path forward there. 17:51:05 Yeah, having an @supports that would let you *reproduce your entire CSS stack with significantly non-trivial modifications* isn't really worthwhile. 17:51:51 It's good for small things, where you just need to do something one of two ways and they involve more than a single property. 19:03:37 bkardell_ has joined #css 19:05:21 una has joined #css 19:19:16 miriam, yeah, read all that history last week. for me, and i suspect many others, having to use a polyfill or preprocessor would be a blocker...but okay for many while it's an early implementation and subject to change. getting @supports in the pipeline seems important for CSS-only use, though. IOW, separate tracks is fine, but not ideal...might reduce amount of early-ish author feedback. 19:23:46 I suppose having @else implemented might get the you same result (since @layer acts as a positive support query for itself) without requiring a new custom support syntax… 19:23:50 unrelated: nice seeing work on box-shadow and text-shadow longhands 19:43:59 dunno how tough adding another function '@supports at-rule(@layer) {}' like '@supports selector() {}' would be...and how extensible it might be for other things like new @font properties, @property, @component, etc. @supports already takes 'not' (though not interoperably, unfortunately). perhaps easier to add @else ? 19:45:43 will definitely take greater minds than mine :) 20:23:49 projector has joined #css 20:24:19 leaverou has joined #css 20:24:49 Rossen has joined #css 20:25:20 shans has joined #css 20:25:50 sylvaing has joined #css 21:46:10 CSSWG_LogBot has joined #css 23:03:20 CSSWG_LogBot has joined #css