15:55:40 RRSAgent has joined #css 15:55:40 logging to https://www.w3.org/2021/05/12-css-irc 15:55:43 RRSAgent, make logs Public 15:55:44 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:55:44 jfkthame has joined #css 15:57:18 present+ 15:57:22 ScribeNick: dael 15:58:28 present+ 15:59:25 tantek has joined #css 15:59:44 oriol has joined #css 15:59:52 present+ 16:00:05 futhark has joined #css 16:00:12 Rossen_ has joined #css 16:00:23 present+ 16:00:43 present+ 16:00:56 dholbert has joined #css 16:00:58 present+ 16:01:01 present+ 16:01:13 present+ 16:01:14 bkardell_ has joined #css 16:01:16 astearns: Thanks everyone who called in on time. I see about half the usual number of people so we'll wait a couple minutes for more people to join 16:01:35 present+ 16:01:53 present+ 16:02:27 present+ 16:02:55 present+ 16:02:58 present+ 16:03:17 present+ 16:03:17 GameMaker has joined #css 16:03:22 Regrets I will be unable to attend today 16:03:32 smfr has joined #css 16:03:33 astearns: We're 3 minutes after. I think we should get going. leaverou_ is running a bit late so item 3 may push down a bit. Other changes? 16:03:37 present+ 16:03:39 Topic: [css-multicol] Definition of adjacent spanners, when to create column boxes 16:03:51 github: https://github.com/w3c/csswg-drafts/issues/6265 16:03:53 present+ 16:04:00 rachelandrew: Couple of linked issue with out of flow items 16:04:19 rachelandrew: I think example is straightforward. Got adjacent spanners that come directly after. margins collapse is in spec 16:04:37 bradk has joined #css 16:04:46 rachelandrew: If you have abspos item inbetween which is taken out of flow we don't have interop. Gecko is not margin collapsing. Keeping abspos item separating. Blink and Safari do collapse 16:04:57 rachelandrew: Morton brought up b/c new fragementation engine doesn't 16:05:17 rachelandrew: What happens if we have out of flow item between 2 column spanners. Happy with margins not collapsing or want them to collapse 16:05:25 present+ 16:05:26 present+ 16:05:28 yes 16:05:30 astearns: if you have non-spanning elements sep by out of flow do margins collapse? 16:05:38 rachelandrew: um...I'd have to test. Not sure 16:05:44 fantasai: They do collapse 16:05:45 rachelandrew: Cool 16:06:04 dholbert: I posted test case on GH showing they do in the simplified scenario 16:06:38 fantasai: I think this is a little...worth pointing out if you have abspos content contained by a block-level box and you remove the boxes it gets trapped and creates columns. 16:07:00 fantasai: If abspos is directly contained by multicol I don't see that is should cause creation of margin 16:07:12 rachelandrew: That's what I thought. It would mean Gecko changing what they're doing 16:07:22 s/and you remove the boxes/ 16:07:25 s/and you remove the boxes// 16:07:31 astearns: fantasai you suggest in case where abspos is contianed by siblining it's different? 16:07:38 q+ 16:07:43 sanketj has joined #css 16:08:10 ack TYLin 16:08:13 fantasai: If there's an abspos position:releative element it creats column boxes and abspos can cause a height. But it's the block box causing the columns. When it's directly contained no reason to create columns and therefore not effect margins 16:08:28 s/abspos/abspos inside it/ 16:08:42 TYLin: Reason why FF is not collapsing margin is b/c when it's out of flow it still leaves placeholder which triggers column box to be created so there is a gap between the adjacent 16:08:58 fantasai: But margin collapsing rules generally ignore abspos leements. So no reason why that should be happening 16:08:59 TYLin: Agree 16:09:23 dholbert: Create the column box to create placeholder. If say abspos placeholder don't get a box that would fix it 16:09:31 fantasai: placeholders only exist in tables. 16:09:49 dholbert: Yeah. Abspos elements don't cause creation of column box. I think that's what you're proposing. 16:09:51 s/tables/table box generation, as far as the specs are concerned. They're otherwise an implementation artifact/ 16:09:57 astearns: Sounds like FF is willing to change 16:10:09 astearns: It was said Morton brought this up b/c new generation matched FF 16:10:14 bradk has joined #css 16:10:25 rachelandrew: I don't think it was a concious choice but was impl details. I'm assuming they're happy to go back. We can ask 16:10:44 iank: I didn't get to talk with Morton before meeting. I think we'd be fine with that 16:11:04 s/Morton/Morten/ 16:11:05 astearns: prop: Confirm that abspos eleemtns do not create column boxes and this adjacent spanners sep by abspos will collapse margins 16:11:13 fantasai: It hink it's no change 16:11:21 astearns: Clarifications and some tests, I suspect 16:11:34 fantasai: [missed] amrgin collapsing eslewehre might. Need tests 16:11:51 iank_: Don't know if that's correct about don't create column boxes. Might conflict with next issue 16:12:09 iank_: And that issue is basically does column balancing apply when you've only got abspos in multicol 16:12:40 fantasai: Not in conflict b/c columns not being created by abspos in the next issue. Box with position:relative creates it. It might be 0 height and can't see, but it's causing creation of column row 16:13:02 iank_: I guess this sort of gets at...need to think about it 16:13:08 s/[missed]/if we call this out in the spec, that implies that/ 16:13:20 astearns: Why don't we resolve adjacent spanners sep by abspos elements will collapse margins 16:13:20 s/Need tests/Need tests, but no change to spec/ 16:13:43 astearns: Abspos elements not creating column boxes is probably implied. But we can go with just margin collapsing for now 16:13:49 iank_: Re-read next, I was wrong 16:14:05 astearns: Back to orginal proposal. "Confirm that abspos elemetns do not create column boxes and this adjacent spanners sep by abspos will collapse margins" 16:14:11 RESOLVED: Confirm that abspos elemetns do not create column boxes and this adjacent spanners sep by abspos will collapse margins 16:14:17 Topic: [css-multicol] Should contained out-of-flow descendants affect column balancing? 16:14:23 github: https://github.com/w3c/csswg-drafts/issues/6279 16:14:50 rachelandrew: This is another one about out of flow elements. Out of flow position box doesn't normally effect ancestor size. It is happening in multicol 16:15:06 bmathwig has joined #css 16:15:15 rachelandrew: We have interop,e veryone does same thing. It is different to have things behave with out of flow. Are we happy to have multicol behave different or do we want to change that 16:15:33 astearns: We have interop but not based on spec text? 16:15:36 rachelandrew: I think that's right 16:16:20 fantasai: I think we do have a use case that people use multicol to emulate pages. That would want us to do same as paginated which is generate more pages and take up space. given we have interop and one reason to do it my suggestion would be to put what they're doing in spec 16:16:30 astearns: Any opinions on the other side? 16:16:36 astearns: Or just generally against 16:16:40 +1 for current behavior 16:16:42 bradk has joined #css 16:16:53 astearns: Prop: Add the current interop situation to the spec 16:16:59 astearns: Objections? 16:17:05 RESOLVED: Add the current interop situation to the spec 16:17:14 Topic: publication 16:17:19 fantasai: multicol should be in CR 16:17:32 rachelandrew: Working through wide review. I've got a11y. I think privacy is going to review 16:17:40 fantasai: I see security and tag....requested and not linked? 16:17:45 rachelandrew: I was going to do those today 16:17:55 fantasai: Great. Hopefully will transition in a few months 16:18:09 iank_: FYI we will probably follow some more issues in a few months given what we're working on 16:18:15 rachelandrew: Cool. I'll try and keep up 16:18:18 astearns: Thanks rachelandrew 16:18:26 Topic: [css-contain] Remove "at-risk" for style containment 16:18:34 github: https://github.com/w3c/csswg-drafts/issues/6272 16:18:47 bradk has joined #css 16:19:03 chrishtr: I think there's a use case now which people agree is important. Have improved definition with respect to HTML. 16:19:15 chrishtr: Spec says HTML ordinals are impl via css counters. 16:19:21 chrishtr: I think we're in good shape to remove those lines 16:19:39 florian: I wouldn't be surprised if when another browser impl there's something we overlooked, but don't need label anymore. 16:19:40 chris has joined #css 16:19:42 chrishtr: Agreed 16:19:47 rrsagent, here 16:19:47 See https://www.w3.org/2021/05/12-css-irc#T16-19-47 16:19:52 florian: Have some amount of tests. Want to put it back on track 16:19:56 CSSWG_LogBot has joined #css 16:20:01 present+ 16:20:04 dbaron has joined #css 16:20:08 astearns: When last discussed I think one impl was against implementing? 16:20:11 Present+ 16:20:18 chrishtr: Previously emilio but I think all issues have been addressed 16:20:42 dino has joined #css 16:21:07 emilio: I don't object. My concern with style containment is it wasn't clear it was useful and interacted with lists, but since lists are now in terms of counters...still style containment doesn't allow style system optimization but it is needed for use case described 16:21:40 astearns: Process-wise I would like to see a second impl started. once we put at-risk it's easy to leave until we're sure it's going to happen. I'm not absolutely sure, but it's low risk to take off if we have to put back on 16:21:47 astearns: Prop: Remove at-risk label for style containment 16:21:52 RESOLVED: Remove at-risk label for style containment 16:21:56 dbaron[m] has joined #css 16:22:00 Topic: [css-contain-3] Need style containment for container queries 16:22:06 github: https://github.com/w3c/csswg-drafts/issues/6213 16:22:07 plinss has joined #css 16:22:42 Present+ 16:22:52 rune: Brought up in connection with container queries. Counter in a container with cont/ queries the counter changes there can effect counter after and effect layout. In particular with flexbox, but other types too. Creates circularity without style containment 16:23:05 present+ 16:23:08 florian: I think you've proven the circularity. Can break with style containment. I'm in favor 16:23:30 florian: Only concent I have is circularity is real, but not something you'd expect authors to typically do 16:23:33 rune: probably not 16:23:56 florian: Suspecting this is a rare weird thing to do. Wondering if always apply style containment is more downsides then another way to cut the loop 16:23:57 present+ 16:24:01 present+ 16:24:24 rune: If you have a counter which is used per container having style containment on the container means you can't increment across multi components 16:24:51 astearns: Motivation for solving circularity in another way is if there is a use case for not having a style containment on container queries for a non-counter related reason. Don't know if there is one 16:25:18 rune: If you don't have style containment can have hard to get interop in this edge case. Number of ways layout will effect result 16:25:33 florian: I think I withdraw suggestion for alternatives. Problem is real and your solution is the obvious 16:25:59 rune: If you have style cotnainment on container you can increment. Just not inside the container. If you have orphans with the container it will work 16:26:10 astearns: miriam are you okay req. style containment on continaer queries? 16:26:18 miriam: Yeah. A little downside but not very big 16:26:30 astearns: Prop: Style containment will be required in order to establish a queriable container 16:26:39 RESOLVED: Style containment will be required in order to establish a queryable container 16:26:46 Topic: [css-color-4] Consider removing lab(...) and lch(...) syntax and using color(lab ...) and color(lch ...) only 16:26:51 q+ 16:26:53 github: https://github.com/w3c/csswg-drafts/issues/5887 16:27:08 leaverou_: I did not open this so not sure I should present. I could. 16:27:13 chris: I'm happy to present 16:27:14 ack chris 16:27:28 chris: Basically issue is we have 2 ways to express lab 16:27:40 chris: Have to be kept separate in the impl. Keep track of which used. Do we need 2? 16:28:06 q+ 16:28:09 chris: Can delete either. People like lab b/c brief. Only added lab to color b/c sure why not when smfr asked. Since Apple is now asking to remove easiest to remove 16:28:35 +1 to smfr's reasoning for color() 16:28:47 q+ 16:28:48 +1 16:29:01 smfr: Talked to Sam. Didn't come to agreement. Don't htink we're arbiters of CSS. Rational to add it is wanted color function to be superset or union of all ways to desc colors. Where there is a color function with a color space where that space could be used in first arg 16:29:17 smfr: Someone uses tooling doing all their colors with color funt and want roundtrip with 10bit 16:29:26 smfr: Okay if we remove, but for completeness it makes sense to have 16:30:12 ack leaverou_ 16:30:15 chris: Understand argument. Would be nice. As someone pointed out we missed with devicecmyk and lch. That was different a while ago but if we wanted to do this need to add lch into the color function so you would need to say this param is a hue. Doable but complex 16:30:15 q+ 16:30:40 leaverou_: Opposed to dropping. nice readable syntax. could instead drop distinction and allow browsers to store color lab and lab function as the same thing. 16:31:09 leaverou_: Usefult o keep distinction for srgb colors. But spec by color isn't legacy and for lab it's the same colors. If it's complex for impl no reason to stor ehte syntax 16:31:40 leaverou_: Agree with smfr there's value in color desc all colors. Allows lib to serialize whatever color w/o special case. Nice to have, not a huge need. Nice if possible. Good to add lch and every other color we support 16:32:01 leaverou_: Might even be value in normalizing coord in a 0-1 range and then color can generic spec any color supported 16:32:03 ack TabAtkins 16:32:11 angles in [0..1] eww no 16:33:02 TabAtkins: on the idea of unifying everything into color with lch and hsl, color only ccepts numbers and not angles. I'm not familar with math, but I don't htink color space ever has angle would would be special casing angle to the pre-defined ones. Feels odd to dup the work to color. Poss, but awk 16:33:37 TabAtkins: on leaverou_ side I would rather a single way to represent rather then 2 ways to rep with 1 serialization. I could be okay, but don't like alaising to a different value then spec and since we don't have legacy need we shouldn't invent one 16:33:48 ack argyle 16:33:51 TabAtkins: Support keeping lab and lch functions and if nec drop lab from color 16:33:54 i am? 16:34:07 np =) 16:34:09 ack florian 16:34:31 florian: Wondering, if we drop the keywords for simplification we're left with one double? Or is color with srgb keyword is that different behavior? 16:34:38 chris: It is. Higher precision requirement 16:34:45 leaverou_: Interpolates differently as well 16:34:46 florian: Thank you 16:35:18 astearns: Seems like things have gone somewhat afield. The question of if we have lab and lch in color function or just lab? 16:35:20 chris: Just lab 16:35:53 smfr: To defend Sam's point he would prefer not to have color(labl) and lab() so prefer to drop one. My preference is weak so willing to drop color(lab) 16:36:03 chris: Can you explain why tracking which method used? Seralization? 16:36:05 smfr: Yep 16:36:15 leaverou_: If they were parse time aliases would have same problem? 16:36:20 emilio: No, but then need to decide one 16:36:38 astearns: And then arbitrarily changing how things spec in style sheet for impl-only reason 16:37:16 astearns: My uninformed opinion, I kind of agree with smfr that it would be nice to have color spec any colora t all, but sounds like problems with colors that use angle. Unclear if we could get to a superset colorf unction. 16:37:31 astearns: Sounds like a slight reason to drop lab from color. no strong opinion 16:37:32 agree with what alan just said 16:37:39 chris: My preference too. Can see both arguments 16:37:46 smfr: Can live with dropping lab from color 16:37:53 +1 16:37:53 astearns: Prop: Drop lab from color() 16:38:00 astearns: Anyone arguing against? 16:38:09 astearns: Objections? 16:38:15 RESOLVED: Drop lab from color() 16:38:29 Thanks for the explanation @smfr helpful 16:38:53 leaverou_: Question, I always assumed if we want to add new color spaces we first add in color function and if we see huge usage we might add as separate color functions 16:39:11 +1 leaverou_ 16:39:12 leaverou_: Means in future might have color color formats spec by both color() and own function. Wouldn't that cause same problem? 16:39:15 astearns: it would 16:39:31 It would, but no clash as the custom one use dashed-ident 16:39:44 astearns: but I think argument there is this is for authors. Huge usage is worth extra effort on impl side. Maybe we wouldn't get to that decision unless usage is off the charts 16:39:56 I see 16:39:59 leaverou_: chris, not talking custom color spaces, talking about new predefined 16:40:33 astearns: I can see if at some point we figure out how to put angle spec colors into color funct we can revist color function being a strict superset and re-add lab 16:40:45 astearns: I don't know we have a strong precident for colors in future 16:41:01 leaverou_: Can have angle in color. Current grammar doesn't allow, but not reason not to 16:41:05 The current grammar allows hue angles to omit a unit 16:41:23 TabAtkins: Id on't think we can do custom colors spaces with angle so would have to special case predefined which is weird 16:41:24 leaverou_: It does 16:41:35 +1 to "ew" 16:41:38 fantasai: Could predfine at 360deg 16:41:49 s/predefine at/define as 100% of 16:41:52 chris: Ew. Can drop unit ID right now so can say 40 for 40deg 16:41:54 1 is pretty convenient to use with display-p3 tho, i know i'm hitting max without knowing what the max number is 16:41:55 astearns: Is there an issue? 16:41:58 chris: No 16:42:00 astearns: Should be? 16:42:13 TabAtkins: No reason to yet. No color which can be spec uses an angle yet 16:42:17 chris: I bleive that's correct 16:42:27 astearns: leaverou_ should we revisit the resolution or move on? 16:42:30 leaverou_: okay 16:42:33 Topic: [css-contain] What is the migration path for Container Queries? 16:42:41 github: https://github.com/w3c/csswg-drafts/issues/6175 16:43:04 miriam: Talked a couple weeks ago. confusion on intent. Going for @supports should always treat unknowns as unsupported 16:43:12 miriam: Allows new funt and testin work backward compat 16:43:35 miriam: 2 resolutions. 1) any unknown supports eval as unsupported 2) add container funt for testing support of specific container conditions 16:43:53 florian: When you say treat unknown as unsupported at top level, you mean immediately? 16:43:56 miriam: Yeah 16:44:06 miriam: Being able to negate it and have it return true is essential here 16:44:15 TabAtkins: Good with this 16:44:25 astearns: Changing behavior for all supports rules? 16:44:31 miriam: Right now not interop on this 16:44:37 miriam: Chart in the thread of current handling 16:44:40 astearns: Thanks 16:44:55 TabAtkins: Spec is unclear. Does not define. Was intended to be different, but Nina convinced me this is better 16:45:09 florian: Didn't we have prop for unified syntax for combo of media and supprot queries? 16:45:23 TabAtkins: That's my when/else proposal. We'll deal with that when it comes up 16:45:32 florian: Okay. Might be a problem, but not as important as containers 16:45:53 astearns: Prop: Unknown at-supports evaluate to false and add that to spec for all supports rules 16:46:10 florian: For this use case it's right. Will it always be or should we specialize to supports query for containers? 16:46:37 miriam: I can't see situation for other behavior. Any new type of check we add to at-supports to determine if supported need it previously returning false 16:46:58 florian: Add new feature and query together, yes. Support syntax for things that predeated abaility to detect then no. 16:47:20 TabAtkins: I think consider future longer then past. A supports query moving forward that you don't understand is for a new feature you don't understand 16:47:40 astearns: A bit concerned we haven't run across this lack of interop. Are people not using not was supports? 16:47:47 miriam: Ran into this with selector 16:47:55 florian: With selectors, do we not want opposite behavior? 16:48:09 astearns: In this case opposite as @supports nad @supports not eval to unknown 16:48:25 florian: An unknown stays unknown until top at which point it becomes false 16:48:32 miriam: Why would we want that? 16:48:35 +1 to miriam 16:48:52 TabAtkins: Same as a feature. If you don't understand enough to evaluate you don't understand to use. 16:49:02 florian: Okay. Maybe I'm not thinking correctly. Defer to TabAtkins 16:49:17 astearns: Prop: Have unknown @supports expressions evaliate to false for all @support rules 16:49:27 RESOLVED: Have unknown @supports expressions evaluate to false for all @support rules 16:49:41 astearns: Do we also need to resolve for the @supports for specific features 16:49:56 miriam: Looking for a container function in @supports that accepts container query query conditionals 16:50:05 astearns: Is it the full syntax? Or a subset? 16:50:16 miriam: I think it should accept any...hmmm 16:50:36 miriam: Maybe it should be one query at a time and you can string together multiples of the function 16:50:42 miriam: Accepts single conditional 16:51:09 astearns: Had not thought threw this. Possibel we'll have new things you can add to funct over time such that an instance may or not eval based on state of impl? 16:51:19 miriam: I expect we will add additional feature queries over time 16:51:32 astearns: That seems to me argument to string together multiples. Maybe. maybe not 16:51:50 miriam: Makes sense and makes simpliest case simplier. @container and a singe query. Makes sense to me 16:51:53 astearns: Other opinions? 16:52:15 astearns: Prop: Create a container function that can test if @supports checks for a particular container query 16:52:18 astearns: Objections? 16:52:26 RESOLVED: Create a container function that can test if @supports checks for a particular container query 16:52:37 astearns: I expect once this is specced we'll have more questions 16:52:55 Topic: ?? 16:53:17 florian: We should find a dedicated call to hash out scrollbar-gutter. Suspect start with a side discussion 16:53:23 astearns: Will you organize florian? 16:53:25 +1 on side chat 16:53:28 florian: If others are interested 16:53:31 I am interested 16:53:47 astearns: Why don't you try organizing on private list. If we get enough people we can open a public meeting on this 16:53:49 florian: Works for me 16:53:51 Topic: [css-overflow] scrollbar-gutter should not do anything for non-scrollable boxes 16:53:58 Topic: [css-images] Consider making -webkit-image-set a parse-time alias to image-set 16:54:06 github: https://github.com/w3c/csswg-drafts/issues/6285 16:54:30 emilio: There's enough usage in the wild of -webkit-image-set it's worth supporting 16:55:00 emilio: Chromium engineers skeptical of getting rid of prefix. I think alias the 2 functions is easiest. webkit does some aliasing. -webkit-image-set serialized as unprefixed 16:55:22 emilio: I think right now wk limits the syntax for -webkit-image-set but they could just support whole thing. I think that's easiest way to spec it 16:55:42 TabAtkins: So long as it's reasonable to Chrome and WK people to accept full set I'm happy to put this in spec 16:55:48 smfr: Fine with that 16:55:56 rune: Without looking it much detail, sounds good 16:56:05 astearns: Prop: Make -webkit-image-set a parse time alias to image-set 16:56:08 astearns: Objections? 16:56:20 RESOLVED: Make -webkit-image-set a parse time alias to image-set 16:56:36 astearns: foolip mentions might be a problem with accepting full syntax, but can check 16:56:47 emilio: I think it's pretyt unlikely that [missed] but we can check 16:57:01 astearns: Might be possibility. Usage would be tiny and not sure side effect is awful 16:57:04 Topic: end 16:57:10 astearns: Thanks everybody for calling in 16:57:42 zakim, end meeting 16:57:42 As of this point the attendees have been dael, rachelandrew, Morgan, futhark, TYLin, miriam, dholbert, oriol, jfkthame, gregwhitworth, chrishtr, cbiesinger, hober, bkardell_, smfr, 16:57:45 ... GameMaker, faceless, emilio, chris, dbaron, dbaron[m], bradk, leaverou_, argyle 16:57:45 RRSAgent, please draft minutes v2 16:57:45 I have made the request to generate https://www.w3.org/2021/05/12-css-minutes.html Zakim 16:57:47 I am happy to have been of service, astearns; please remember to excuse RRSAgent. Goodbye 16:57:52 Zakim has left #css 16:57:57 bradk has joined #css 16:58:25 aja has joined #css 17:54:19 jensimmo_ has joined #css 19:40:54 neeke has joined #css 22:04:24 dauwhe has joined #css 22:36:02 dauwhe has joined #css 22:59:39 dauwhe has joined #css 23:01:43 dauwhe has joined #css