16:15:42 RRSAgent has joined #css 16:15:47 logging to https://www.w3.org/2025/12/03-css-irc 16:15:47 Zakim has joined #css 16:16:09 TabAtkins: The only reason grid has different behavior for putting intrinsic in minmax is that there's no way to resolve it for repetition purposes 16:16:19 TabAtkins: so it does the only thing it can, using the fixed value 16:16:31 q+ 16:16:35 TabAtkins: not a desirable behavior, it's purely the only option, so we break consistency 16:16:55 TabAtkins: In masonry that's no longer needed, we can do consistent behavior - double intrinsic, double fixed, etc, always the larger of the two values 16:17:09 TabAtkins: Agree with Miriam, not the most important thing 16:17:18 TabAtkins: Good argument for consistency on this side 16:17:18 ntim has joined #css 16:17:18 ack fantasai 16:17:33 present+ 16:17:50 q? 16:17:59 q+ 16:18:18 fantasai: Track sizing and repetition is fairly complicated, authors have to learn how it works and what it's used for. Having the behavior differ subtly for the exact syntax between masonry and grid is going to cause confusion for authors switching between masonry and grid 16:19:07 q+ 16:19:19 fantasai: In terms of whats possible in masonry vs grid, TabAtkins point about intrinsic repetitions in masonry but we can't in grid, but we use the same property. We would like to see a way for intrinsic repetitions to work in grid. If that happens, masonry and grid could be the same behaviors. 16:19:21 ack miriam 16:19:22 bradk has joined #css 16:19:51 Miriam: I agree with Tab there's a consistency argument either way. Is larger-always-wins useful, why is that the one we want if there's a consistency argument either way? 16:20:33 JoshT has joined #css 16:20:33 dholbert has joined #css 16:20:33 celestepan has joined #css 16:20:33 ydaniv has joined #css 16:20:33 hoch has joined #css 16:20:33 djmarland has joined #css 16:20:33 flackr has joined #css 16:20:33 Kurt has joined #css 16:20:33 alisonmaher has joined #css 16:20:33 kbabbitt has joined #css 16:20:33 romain has joined #css 16:20:33 github-bot has joined #css 16:20:33 tusf has joined #css 16:20:33 jcraig has joined #css 16:20:33 florian has joined #css 16:20:33 cmp has joined #css 16:20:33 bts has joined #css 16:20:33 dbaron has joined #css 16:20:33 ondrejkonec has joined #css 16:20:33 keithamus has joined #css 16:20:33 jbroman has joined #css 16:20:33 foolip has joined #css 16:20:39 TabAkins: Because I think it's very strange to have a case where you start with max-content columns and realize some items are too small, you put a min on that column minmax(50, max-content), and suddenly all columns are 50px, ignoring max-content, drastic change 16:20:45 Miriam: It's not ignored, it's on the high end 16:21:20 q- 16:21:22 q+ 16:21:50 TabAtkins: If you use the high end max-content, 1000px, we use 1000px. May not be useful but it is consistent with masonry and grid in other cases. Unless we redefine entirely behavior, that shouldn't be a consideration. Thinking about the reverse case, which can't be done in grid. 16:23:31 TabAtkins: Any complaints that someone might have about minmax(auto, 1000) are the same complaints they will have with double-fixed in masonry and in grid. It's already a behavior shared in all other scenarios, thus not what we're trying to resolve right now. One case is where putting a small min, which dramatically changes behavior in a bad way, 16:23:31 just because we want a consistency in grid, which is an error case, but we just have fallback. 16:23:42 Fantasai: Is that an error case? 16:24:08 bradk has joined #css 16:24:19 TabAtkins: If you put a mixed intrinsic and fixed size in a repeater, because you cannot determine intrinsic size. We cannot use it to estimate track size. 16:24:33 Fantasai: I don't think that's an error case, it's just the behavior, it's useful 16:24:42 TabAtkins: The example Miriam gave? 16:25:13 q- 16:26:06 [@kurt, Zoom has pretty good automatic transcription. Looking at that might help with manual transcription if you get behind] 16:26:20 TabAtkins: In those cases, it doesn't seem like the intrinsic keyword is a meaningful limit - the repetitions you get are unlikely to run into the intrinsic keyword max - they want a fixed repetition, but there's a little leftover space, and that needs to expand out to fill the repeated columns, but that doesn't need any particular content 16:26:20 behavior. You could just as easily write that with an fr value instead of an intrinsic keyword and get the same layout. That would work the same in grid and masonry - fixed and flex instead of fixed and intrinsic. 16:26:53 q+ 16:27:29 ack astearns 16:27:41 astearns: I'm sympathetic to fantasai's argument to make it the same in grid and grid lanes and allow for better handling in both for these keywords, but wouldn't that likely require adding something to syntax to say "here we found a way to use intrinsic sizes, but because of backwards compat, you need this new functionality" 16:28:09 minmax(100px, 200px) minmax(100px, auto) minmax(auto, 200px) minmax(auto, auto) 16:28:30 bradk has joined #css 16:30:32 (I suspect Kurt might be behind...) 16:30:49 fantasai: we have these 4 patterns - the first 3 are valid and grid and are being used. The 4th is new in grid level 3. Current proposal is use heuristic for auto and use bigger size. We argue the 4th case should do the same heuristic and not just resolve to 1, which is what has been proposed. For consistency and for usefulness in grid, so make it 16:30:49 available in both. Existing syntaxes can't change in grid, can be different in masonry, but would be inconsistent. Already complicated, so learning that there is this difference is a burden on authors. But we might want to do what TabAtkins is advocating for, as well as additional things. In first case, we take the max, not very useful, might want 16:30:49 minimum, might want track to grow to limit, and not have extra space, which doesn't seem useful. 16:31:26 minmaxbasis(min, max, basis for repetition) 16:31:31 fantasai: To enable that, or other behaviors, we want to add some new syntax to do that, and I think there is room, we should investigate. One possibility is min-max-basis, which would give min, max, basis for repitition 16:31:48 fantasai: say "use minimum, use max, use combination", room to experiment 16:31:59 repeat(auto-fit from 15em, minmax(whatever, whatever)) 16:32:10 minmax(100px, 200px) minmax(100px, auto) minmax(auto, 200px) minmax(auto, auto) 16:32:19 ack lea 16:32:23 fantasai: could be useful for authors, but fundamentally, if we want this to be a system that's understandable, it should be consistent between grid and grid lanes for all 4 syntaxes 16:33:53 - Consistency TAG principle https://www.w3.org/TR/design-principles/#consistency 16:34:01 q+ 16:34:39 Don't we also have a "but don't overvalue consistency with legacy behavior if better solutions exist now" policy? 16:35:15 lea: I'm not sure if I have enough background, but a high level requirement. I don't thinks witchning from masonry to grid is important, nice to have, but I don't see authors regularly switching. However, mental model is least surprise, what to expect when you use a syntax. I don't think he way minmax works is intuitive, hard to explain how it 16:35:15 works. Given that authors have an existing mental model, hesitant to change, even if we can do better. Especially because we put a lot fo work into the current model. Break precedent only if you're very certain you have a much better solution. Breaking precedent is an ergo problem, two different mental models. I tend to agree with fantasai. If we 16:35:15 ant a different behavior, we should have a different syntax in grid. 16:35:39 "There is often a tension between API ergonomics and consistency, when existing precedent is of poor usability. In some cases it makes sense to break consistency to improve usability, but the improvement should be very significant to justify this." -- https://www.w3.org/TR/design-principles/#consistency 16:36:59 lea: I was thining, what could that look like, new syntax for both masonry and grid, some kind of switch that grid has access too, but default in masonry, but are the use cases around irregular grids, or all cols/rows having the same params, could introduce new property - could have grid-column-min-width to be bikeshedded, could be value 16:36:59 independently of masonry. Multicol has this really nice syntax, can set columns and width and browser figures it out. Could set property in grid, and get best of both worlds. 16:37:16 ack fantasai 16:37:16 fantasai, you wanted to discuss additions to syntax 16:37:19 ack miriam 16:37:36 minmax(100px, min-content) minmax(100px, max-content) 16:38:25 miriam: seems like the one example you keep getting TabAtkins, makes sense, but feels somewhat contrived. Switch min-content for max-content, you probably want the other thing. I don't understand building around one use case when the other behavior is more useful. Overall, I would like to see more control. You might want either thing, so you should 16:38:25 add a control to have either thing. Should look into having grid-lanes and grid handle it either way. 16:38:58 to clarify, miriam, is your example "i want it to be min-content, but not get larger than 100px"? 16:39:33 astearns: summarizing, we have a bunch of solutions for both grid and grid-lanes in some future way and keeping limitations today. Tab is looking at a better solution tailored for grid-lanes. Would you be willing to resolve on consistency between grid and grid-lanes now, or hold on to making grid-lanes work for these cases 16:39:49 TabAtkins: I think it's the wrong behavior, but am open to a new control in the future 16:40:06 resolution: Keep consistency between grid and grid-lanes, work on a solution for both layout systems 16:40:39 RESOLVED: Keep consistency between grid and grid-lanes, work on a solution for both layout systems 16:41:03 github-bot, take up https://github.com/w3c/csswg-drafts/issues/12803 16:41:03 Topic: [css-grid-3][masonry] item-flow row vs. column in masonry layouts 16:41:03 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12803 16:41:47 dgrogan has joined #css 16:41:50 fantasai: There are a bunch of things interacting in this issue, but one thing we all seem to agree on is the initial value of the control should be a keyword called normal that switches between waterfall and brick based on wither you set grid-template-rows or columns 16:41:57 fantasai: I think we're all on board with that idea 16:42:01 q+ 16:42:08 ack alisonmaher 16:42:43 almaher: I had a separate proposal with a directionality wouldn't have a normal value, but auto-flow would have a default of normal. Not sure if that falls under the same resolution. 16:42:54 Ooh, I also didn't see all the discussion that happened yesterday afternoon 16:43:04 astearns: If we need an initial value that's neither row nor col it would be named normal 16:44:06 alisonmaher: my proposal is for a single source of truth - grid-lanes-orientation that would take either row or column. Could set either row or column and take whichever property is specified. Implied ordering of items in each lane as defined in masonry. 16:45:01 fantasai: I don't think that's incompatible with what I'm proposing, We're both saying there is a property that is a source of truth. That source of truth would have an initial value, that we'll call normal to not conflict with auto that computes to either row or column depending on what you set. 16:45:16 astearns: the difference is that there is no source of truth 16:45:31 fantasai: the difference is you don't need to set a separate property - we can infer if you set the template 16:45:34 s/no source of truth/the source of truth doesn’t have a normal value/ 16:45:46 alisonmaher: in your proposal, there isn't a single source of truth, there are many that can override each other 16:45:51 Yeah, there's no overriding. 16:46:09 This is a pretty normal way we handle defaulting. 16:46:18 (see my last comment on the issue) 16:46:32 fantasai: If you set that property to something other to normal, then it automatically checks. That is intuitive for authors - they don't need to think of another property. If they don't set it, they get the thing they ask for, regardless of templates properties. 16:46:46 alisonmaher: are you saying that grid-auto-flow is the source of truth? 16:47:08 fantasai: Separate proposal, doesn't matter, there is a property, initial value is normal and will compute to rows or columns 16:47:54 alisonmaher: with that proposal, you can't have a masonry to have a row definition of non, allowed in masonry and not grid. If grid auto flow is normal, we need to look at grid. If both are set to none, we use columns, we can't get a definition set to non. 16:48:09 fantasai: If you set it we can determine. Issue is only if you don't set it. 16:48:23 alisonmaher: In that definition you can't have that definition for rows 16:48:48 TabAtkins: you have to set yourself to rows, because we can't infer it. You can achieve it with no template if you set row in direction determining property. 16:49:03 alisonmaher: I though if you set on later it would override the others, but sounds like that's not an issue 16:49:22 +1 16:50:10 PROPOSED: Whatever property controls the orientation of grid-lanes, its initial value is 'normal' and it resolves to waterfall or brick layout depending on whether grid-template-columns or grid-template-rows was set (respectively), defaulting to waterfall if both or neither are set. 16:50:37 RESOLVED: Whatever property controls the orientation of grid-lanes, its initial value is 'normal' and it resolves to waterfall or brick layout depending on whether grid-template-columns or grid-template-rows was set (respectively), defaulting to waterfall if both or neither are set. 16:51:27 bradk has joined #css 16:52:07 q+ 16:52:19 ack TabAtkins 16:52:22 fantasai: We're advocating for reusing grid-auto-flow. We don't see a need for a new control. 16:53:43 q+ 16:53:50 ack miriam 16:54:16 TabAtkins: Storng for not using grid-auto-flow. We are using grid-template, but not other properties because they are not necessarily the same. In this case, they are very different. Specifically directionality. If we use grid-auto-flow, we are using wrong keywords for direction. We have extensions to grid-auto-flow to match flex (col-reverse, 16:54:16 etc), and those keywords don't work in masonry, not the right concepts. Trying to overly reuse grid is a disservice to authors. Better to get a similar that works for grid-lanes but not trying to serve multiple concepts. 16:54:26 q+ 16:55:04 (I'm totally fine with -direction or -orientation 16:55:07 ) 16:55:15 miriam: I prefer grid-auto-flow for consistency. I don't like it for grid either, but I learned it, and the same model works in both. I don't think grid-lanes is special. If we do come up with something for grid-lanes, it shouldn't be grid-flow, that would be confusing. 16:55:22 ack alisonmaher 16:56:08 I don't think we need a grid-lanes shorthand 16:56:26 alisonmaher: +1 to miriam, if we do have grid-lanes, orientation or direction makes this clearer. I also agree with tab to not use grid-auto-flow. Current proposal can set grid-lanes-rows which is the same as grid-auto-flow columns. Having same properties to set different things would be inconsistent. Shorthand would use opposite keyword, which is 16:56:26 a problem. 16:56:29 Rossen5 has joined #css 16:56:39 q+ 16:56:39 astearns: two routes, two options for each 16:56:40 Alison is referencing https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3597842524 16:56:42 +1 to having a grid-lanes specific thing, +1 to call it -direction or -orientation, not -flow 16:57:16 +1 to grid-lanes specific, and avoiding the problematic word "flow" 16:57:18 +1 to having grid-lanes specific 16:57:18 astearns: is it possible to discuss shorthand without making a decision without deciding on source of truth, or do we need source of truth first? 16:57:26 SebastianZ has joined #css 16:57:37 TabAtkins: they are tied, shorthand needs to express direction, which layout do you mean? It's the same question. 16:57:41 bradk has joined #css 16:58:00 astrearns: other question, is there any difference between competing sources of truth on how syntax extensions for reversing stuff? 16:58:09 TabAtkins: yes, on the keyword side as well 16:58:29 fantasai: 3 syntaxes proposed, need to discuss and make a chart 16:58:34 TabAtkins: agreed 16:59:03 I left my opinions on the issue, I prefer re-using grid-auto-flow 16:59:21 kyerebo has joined #css 16:59:41 PaulG has joined #css 16:59:44 astearns: More opinions in irc for a separate property, not going to resolve today. Re-use auto-flow or new orientation property, not flow. Take it back to the issue and write out proposals in both syntaxes. Maybe have a github poll once there's a clear breakout of options, another grid-lanes breakout in 2 weeks. Opinions? 16:59:51 astearns: let's do that 17:00:16 present+ 17:00:18 present+ 17:00:18 present+ 17:00:22 jbreiland has joined #css 17:00:30 fantasai has changed the topic to: https://lists.w3.org/Archives/Public/www-style/2025Dec/0003.html 17:01:38 present+ 17:01:43 present+ 17:01:43 schenney has joined #css 17:02:00 smfr has joined #css 17:02:31 masonf has joined #css 17:03:48 Penny has joined #css 17:04:06 topic:foo 17:04:43 Present+ 17:04:47 present+ 17:05:41 Present+ 17:06:01 ScribeNick: TabAtkins 17:06:25 javierct has joined #css 17:06:51 Topic: F2F Dates 17:06:58 POLL: https://lists.w3.org/Archives/Member/w3c-css-wg/2025OctDec/0156.html 17:07:18 fantasai: Polling for dates for Spring and Summer 17:07:31 fantasai: Spring hosted by Moz in Berlin, Summer by Microsoft in Seattle 17:07:54 github-bot, take up https://github.com/w3c/csswg-drafts/issues/6900 17:07:54 Topic: Republishing Tasks Permathread 17:07:54 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900 17:07:57 jfkthame has joined #css 17:08:06 bradk has joined #css 17:08:13 Rossen: 6 more drafts that need republishing 17:08:30 Rossen: first CSS Tables 3 17:08:54 SebastianZ: last time we discussed Table it didn't have an editor, now it has one assigned (Keith) 17:08:59 SebastianZ: so maybe we can resolve on publishing now 17:09:09 +1 now we have an editor 17:09:18 +1 17:09:53 RESOLVED: Republish WD of Tables 3 17:10:04 SebastianZ: next is Borders 4, this is my spec 17:10:17 SebastianZ: there were a bunch of new features added and changes made, so it's time to repub 17:10:22 +1 17:10:35 +1 17:10:37 SebastianZ: last pub was earlier this year (FPWD), want another WD 17:11:01 fantasai: if your edits all have WG resolutions you can publish without asking, fyi 17:11:10 RESOLVED: Republish Borders 4 WD 17:11:26 SebastianZ: Shadow Parts was last published in 2018. i've updated Changes section and added wpt coverage 17:11:34 +1 17:11:53 JoshT has joined #css 17:12:02 Rossen: any objections? 17:12:14 RESOLVED: Repub WD of Shadow Parts 1 17:12:25 Rossen: then UI 3 and 4 17:12:37 SebastianZ: Maybe shoudl go with UI 4 first, i think it's easier 17:12:58 SebastianZ: lots of changes and major features since last pub, many already implemented 17:13:02 q- 17:13:04 SebastianZ: so i thin kit's fine to repub 17:13:28 fantasai: i think as long as Florian is ready to publish and does the publishing, i'm okay with it. i'll defer to him. 17:13:44 Rossen: let's resolve to publish and action Florian for it 17:13:56 RESOLVED: Repub UI 4 as WD 17:14:05 Rossen: now 3 17:14:26 ChrisL: Wasn't clear to me why it needs repub, it's just editorial changes and it's a lot of work to update an old spec like that 17:14:40 s/old spec/old Rec/ 17:14:40 SebastianZ: tha'ts fine for me. i updated the changes list from the Rec, there's a few clarifications but they're not huge changes 17:14:51 https://drafts.csswg.org/css-ui-3/#changes-2018-06-21 17:15:20 Rossen: I agree with Chris that it's not a lot of benefit, but is a lot of work... 17:15:24 fantasai: if it's just editorial we can just republish 17:15:26 Rossen: is it? 17:15:31 fantasai: there's some minor non-editorial 17:15:37 fantasai: think we can defer to Florian 17:16:00 SebastianZ: last is Rachel publishing Animation Worklet 17:16:09 SebastianZ: been on the list for a year or so, dont' know the status 17:16:50 flackr: there's an experimental impl in Chromium but nobody else has looked at it, and we're not planning on shipping yet 17:16:57 SebastianZ: Rob's an editor 17:17:10 flackr: i don't think there's been any recent work on it. for now i'd consider it a non-active spec 17:17:49 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10674 17:17:50 Topic: [css-env][css-values] UAs inconsistent in how OS font settings affect the default font-size `medium` 17:17:50 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10674 17:18:34 present+ 17:18:40 present+ 17:18:40 fantasai: where are we at with the font-size stuff? did we resolve on it? 17:18:41 bradk has joined #css 17:19:00 ???: dgrogan at Google has drafted a PR to update the spec with our resolutions, just needs merging 17:19:11 s/???/JoshT/ 17:19:23 JoshT: i think elika's issue was around non-uniform scaling 17:19:38 JoshT: body-size text we want to respect the OS pref, but large text like headings, should that scale at the same rate 17:20:06 fantasai: one idea i had is that, right now, the meta tag opts us into changing the computed value of 'medium' to match the OS's paragraph text size 17:20:15 fantasai: I think that ends up scaling all the other sizes uniformly 17:20:38 fantasai: but we could define that th eother keywords (large, small, x-large, etc) also adopt the OS's preferred scaling factors, even if those aren't uniform with the medium scale factor 17:20:54 fantasai: in most cases authors set those sizes explicitly anyway as a multiple of their base size 17:21:06 fantasai: but this would make the OS's text scale available to the author to compute against 17:21:37 fantasai: so that's my suggestion, 'medium' uses the OS's paragraph size, but allow the other keywords to map to other OS sizes, even if they're not uniform 17:21:43 q? 17:21:47 ack fantasai 17:22:06 JoshT: there's already anothe rissue for that. i'd support it. 17:22:21 JoshT: but i'd highlihgt that authors ar emostly just using rem or px units to size text, so it'll probably be tiny impact 17:22:38 fantasai: yeah it wouldn't have much impact on existing pages, which is a good thing. too much breakage when people opt in 17:22:43 q+ 17:22:56 fantasai: but it makes the information available to authors so they *can* use the info and scale accordingly 17:23:10 fantasai: without us having to create a whole new system 17:23:16 scribe+ 17:23:19 ack TabAtkins 17:23:30 TabAtkins: When you say authors can respond, how do you see them doing that? 17:23:40 TabAtkins: How would you set a heading to large x 1.2? 17:23:57 fantasai: large *is* large x 1.2 17:24:05 fantasai: these keywords would compute to... they're not a scale factor 17:24:21 TabAtkins: You said authors could respond to these sizes, you mean they can use it? 17:24:26 TabAtkins: Do you mean they could modify them? 17:24:35 TabAtkins: That would only be possible em on a child 17:25:04 fantasai: you should be able to use them in calc() too 17:25:05 fantasai: They compute to length values, should be able to use them in calc() 17:25:11 TabAtkins: Oh, that's a new feature 17:25:43 TabAtkins: now is any of this relevant to the issue at hand? 17:25:59 fantasai: In calc() or in the interpolation functions 17:26:04 fantasai: yeah allowing these in calc() or in interpolate() would solve this 17:26:31 JoshT: these are currently absolute font-szie keywords, onlya vailable in font-size property 17:26:36 JoshT: woudl this mean they're usable anywhere? 17:26:55 fantasai: interesting, i'd say no to begin with. if you need font-based sizing you'll just set font-size, then use ems 17:26:56 q+ to wonder if there is impact on font-size descriptot 17:27:20 JoshT: would it even be possible? 17:27:23 ack ChrisL 17:27:23 ChrisL, you wanted to wonder if there is impact on font-size descriptot 17:27:32 q+ 17:27:38 fantasai: no, would need some new calc-keywords since "medium" can mean other things 17:27:45 ChrisL: does this affect font-size descriptor? 17:27:51 fantasai: does it even take keywords? 17:27:57 fantasai: don't think it does 17:28:44 https://drafts.csswg.org/css-fonts-5/#font-size-desc 17:28:47 ack dgrogan 17:29:01 dgrogan: point of order - we ahve a separate issue for this topic 17:29:12 dgrogan: which of these issues are we discussing? 17:29:32 Ah, I found the issue https://github.com/w3c/csswg-drafts/issues/12475 17:29:40 ack dbaron 17:29:56 dbaron: i'm nervous about compat with some of this... hard to follow what's being proposed tho 17:30:10 fantasai: this is only if you opt into the meta tag 17:30:15 q+ 17:30:25 ack dgrogan 17:30:39 dgrogan: so we could do what elika is proposing 17:30:48 dgrogan: could also let authors opt into a uniform scale explicitly 17:30:59 dgrogan: with the current 'scale' keyword in the meta 17:31:18 dgrogan: note that the uniform scale is the only thing authors have requested 17:31:31 dgrogan: we could have another keyword for the non-uniform scale, but we haven't seen requests for that yet 17:31:40 dgrogan: like "scale non-uniform" 17:32:03 fantasai: what benefit would it bring to the authors to have the non-uniform scale? if they want uniform they can just use ems based on the default font size 17:32:08 q+ 17:32:14 ack fantasai 17:32:15 s/non-uniform/uniform/ 17:32:34 dgrogan: i see what you're saying. making it non-uniform would still let you get uniform 17:32:46 fantasai: yeah, and they'd get that by default by just using standard existing authoring practices 17:33:29 JoshT: I have some thoughts on this but I can avoid solutionizing while we resolve on the keywords 17:34:29 PROPOSED: When opting into user-preferred font-sizing, the UA tweaks not only medium, but also the other absolute font-size keywords may be adjusted non-uniformly to match the user's preferred text scale 17:35:01 JoshT: looks good, but q. haven't discussed by how much they'll scale. is that editors discretion or UA? 17:35:17 fantasai: the editor will ahve to figure out how to describe it, but UA will have to figure out what info they have available. 17:36:06 fantasai: [describes a scenario about how to map OS scales to the UA scale, especially when their might be different scale amounts] 17:36:19 fantasai: complicated to map the scales together but i think we can leave that to UA discretion 17:36:25 fantasai: with some suggestions on how to do it 17:37:04 RESOLVED: When opting into user-preferred font-sizing, the UA tweaks not only medium, but also the other absolute font-size keywords may be adjusted non-uniformly to match the user's preferred text scale 17:37:40 github: https://github.com/w3c/csswg-drafts/issues/12475 17:38:02 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10674 17:38:02 Topic: [css-env][css-values] UAs inconsistent in how OS font settings affect the default font-size `medium` 17:38:02 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10674 17:38:40 Kurt has joined #css 17:38:55 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10372 17:38:55 Topic: [css-color] Mitigating fingerprinting for AccentColor/AccentColorText 17:38:55 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10372 17:39:29 kyerebo 17:39:40 scribe+ 17:40:15 kyerebo: Recap, we previously brought up issue of fingerprinting for AccentColor and AccentColorText when using the system colors 17:40:30 kyerebo: Initially thought we could gate on installing the web app, but [problems] 17:40:42 q+ 17:40:42 kyerebo: Since then we investigated tainting 17:40:55 kyerebo: This solution definitely works, it can apply to getComputedStyle(), color-mix(), color extraction with if(), etc. 17:41:06 kyerebo: We already have tainting with cross-origin canvas etc. 17:41:16 kyerebo: We think this protects the users well enough, and want to move forward with it 17:41:16 q+ 17:41:18 q+ 17:41:26 (I'm probably just going to +1 what Lea is gonna say) 17:41:36 kyerebo: I do want to summarize, in GH issue, Lea proposed splitting out AccentColor keywords so that authors can avoid the tainting if desired 17:41:50 kyerebo: Also discussion about may vs should, so that UAs can make decisions of tradeoffs 17:42:04 ack lea 17:42:25 lea: I think we should prioritize tainting only when needed, not whenever AccentColor is used 17:42:38 lea: Basically authors should be able to escape any tainting by setting accent-color to a fixed color 17:42:52 lea: As long as OS accent color is not used, should not be tainting. 17:43:08 lea: Either we only taint the auto value, or we have a separate OSAccentColor keyword and that one gets tainted 17:43:13 lea: I don't have a preference between the two 17:43:35 lea: Separate color keyword does enable some additional use cases, e.g. can use OS-default hue ... 17:43:43 lea: Important bit is not to have tainting unless we actually need it 17:44:08 lea: Wrt may or should or must, I'm not sure there's consensus that this is a significant fingerprinting issue 17:44:20 lea: and tainting has a lot of complexity 17:44:24 ack TabAtkins 17:44:30 lea: So each UA should be able to choose, so prefer to use MAY or SHOULD 17:44:33 TabAtkins: +1 to what lea said 17:44:46 TabAtkins: tainting should be from use of OS color, not AccentColor itself (which could be a manually set color) 17:44:58 TabAtkins: I like proposal of adding an explicit color for OS Accent Color 17:45:09 TabAtkins: Because still useful to be able to tweak that color and use it as an accent color 17:45:27 TabAtkins: So support adding another color like OSAccentColor which is what carries the taint 17:45:39 TabAtkins: and AccentColor just becomes value of 'accent-color' value 17:45:43 ack emilio 17:46:02 TabAtkins: just like currentColor and 'color' 17:46:10 emilio: Why are we doing this for AccentColor and not [missed]? 17:46:25 emilio: I think I agree with only tainting the OS values, but also I think we should treat all the system colors consistently. 17:46:31 s/[missed]?/HighlightColor?/ 17:46:34 emilio: I don't see why AccentColor is special, other than authors want to use it a bit more 17:46:50 q+ 17:46:52 emilio: It would be nice to also use, e.g. system selection colors without exposing to authors 17:47:05 emilio: Also, what is the effect of tainting? If it's mixed, what do you return? 17:47:13 emilio: would be nice to see details of what is proposed 17:47:19 emilio: But I would prefer to treat all system colors consistently 17:47:43 q+ 17:47:52 kyerebo: Privacy review from chromium folks was that accentcolor is increased because highlightcolor etc is gated on accessibility features 17:47:57 kyerebo: Might not be true for other systems 17:47:58 ack kyerebo 17:48:10 kyerebo: In our tainting implementation, we use a spoofed blue color 17:48:21 kyerebo: Spoofing of color is a resolution already in the spec, so this makes sense to me 17:48:38 kyerebo: but we could also do something like ???? 17:48:46 ack emilio 17:49:06 emilio: Seems basically same as highlight, except chrome spoofs highlight by default but doesn't want to spoof accentcolor. But they're the same. 17:49:24 emilio: Main issue with tainting, as of right now we resolved that system colors resolve to an actual color, and that's how they interact with light/dark etc. 17:49:31 q+ 17:49:39 emilio: Spoofing seems appropriate... 17:49:56 emilio: returning a keyword would mean that you have to maintain it at computed value time, which won't get the expected behavior for light-dar() 17:50:03 emilio: but does seem like a fair bit of complexity 17:50:09 emilio: but if we apply consistently to all system colors, seems ok 17:50:24 emilio: I think it'd be really weird to only apply to AccentColor and AccentColorText 17:50:38 emilio: at the very least apply to AccentColorText, but also apply to all system colors 17:50:42 ack lea 17:50:56 lea: Assuming what spoofing means, it's like treat it like a predefined color like blue 17:51:12 lea: Then authors will try to do things and get different values on the page 17:51:17 q+ 17:51:26 I agree that users will be confused by mixing the colors and getting the wrong result 17:51:32 lea: I would be ok with not using the OS color, or only use it if you do certain things like install the app 17:51:50 lea: I also think taintining is not a great solution. It causes all kinds of problems, we should not choose it lightly. 17:52:18 lea: Personally I also don't mind if we don't do anything here, but recognize it's an issue from others' perspectives 17:52:23 q+ 17:52:30 ack emilio 17:52:43 [what is tainting] 17:53:00 TabAtkins: if you read the tainted value, we pretend the value was something else than it was 17:53:11 lea: Hm... can we pick a value in the spec, rather than making it OS-dependent? 17:53:18 ChrisL: It looks like 3 options 17:53:19 ack ChrisL 17:53:27 Yes, it needs to be a value in the spec; if it's OS-dependent, then it's fingerprinting too obviously ^_^ 17:53:57 ChrisL: 1) Don't do anything special. This exposes some fingerprinting, but everything is simple to implement. 17:54:10 qq+ to reply to Chris 17:54:18 ChrisL: 2) Do all this tainting, so people get unexpected values. They create tints etc and it all goes wrong and they can't understand why. 17:54:47 ChrisL: 3) Use keywords and stuff, so color-mix() maintains these as independent channels. This also adds tons of complexity to values. 17:55:03 emilio: It would also inherit the keyword, which means the foreground color changes with color-scheme 17:55:13 ack lea 17:55:14 lea, you wanted to react to ChrisL to reply to Chris 17:55:30 lea: My understanding of the tainting is that you only get the tainted value if you try to read it. Creating tints etc will work. 17:55:43 ChrisL: Ah, didn't understand. Thought it meant "use the value". 17:56:03 lea: That said, not sure it would work in every case. Right now you can exfiltrate color components using if() and style and registered color properties 17:56:15 lea: Then you would end up tracking all kinds of other properties... seems hellish to implement. 17:56:39 Rossen5: Ok, kyerebo, what are you advocating for here? 17:57:07 kyerebo: Yes, tainting as we talk about is it's available to use for color mixing and rendering, but any attempted reads using getComputedStyle() etc would return a fake color 17:57:13 kyerebo: Option 3 doesn't work for reasons emilio said 17:57:30 kyerebo: Option 1, there's definitely a fingerprinting vector here but there's argument that it's small enough or already existing system colors that do this 17:57:35 q+ 17:57:39 kyerebo: Option 2, color is available to use but reads are blocked 17:57:57 kyerebo: I'm advocating for option 2, because we did a privacy review and it was found to be a significant fingerprinting vector 17:58:05 Rossen5: This is also going to match highlightcolor? 17:58:19 kyerebo: Specifically for accent-color when using OS color 17:58:29 ack emilio 17:58:52 and in the future this will be even easier, via `color-extract()` 17:58:54 emilio: lea brought up really good point that can propagate color to non-color properties, so it's a lot harder than using fake color when querying 17:59:09 emilio: because then you need to track a lot more things 17:59:19 q? 17:59:20 q+ 17:59:22 emilio: If we do tainting, I'd like to see deep detailed explanation of what it's supposed to do 17:59:33 emilio: And color should be fixed, independent of platform, just like some other system colors 17:59:49 emilio: And also we shouldn't special-case accentColor 17:59:52 q+ 18:00:16 ack lea 18:00:31 Rossen5: Seems we're out of time, let's take back to the issue and then continue next week. 18:00:42 ack kyerebo 18:00:49 present+ 18:01:02 ack fantasai 18:01:04 present+ 18:01:09 present+ 18:01:17 Topic: End 18:01:23 I have made the request to generate https://www.w3.org/2025/12/03-css-minutes.html fantasai 18:01:27 Zakim, end call 18:01:27 I don't understand 'end call', Rossen5 18:01:35 Zakim, end meeting 18:01:35 As of this point the attendees have been ntim, SebastianZ, PaulG, kyerebo, djmarland, jbreiland, dbaron, bramus, ChrisL, lea, flackr, smfr, JoshT, jfkthame 18:01:38 RRSAgent, please draft minutes v2 18:01:39 I have made the request to generate https://www.w3.org/2025/12/03-css-minutes.html Zakim 18:01:44 I am happy to have been of service, Rossen5; please remember to excuse RRSAgent. Goodbye 18:01:44 Zakim has left #css