17:02:52 RRSAgent has joined #css 17:02:56 logging to https://www.w3.org/2025/02/26-css-irc 17:02:56 RRSAgent, make logs Public 17:02:57 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 17:03:03 gfaujdar has joined #css 17:03:11 ScribeNick: bramus 17:03:15 present+ 17:03:19 present+ 17:03:38 present+ 17:03:41 Topic: Misc 17:03:42 castastrophe has joined #css 17:03:50 present+ 17:03:52 Rossen3: Any changes to the agenda? 17:04:07 Rossen3: gonna skip the first issue 17:04:12 jfkthame has joined #css 17:04:18 Rossen3: the reading flow one. got request to skip bc some ppl not ready 17:04:29 dholbert has joined #css 17:04:29 Rossen3: one was removed, the other one will be skipped 17:04:31 present+ 17:04:33 Rossen3: any other changes? 17:04:43 present+ 17:04:47 astearns: future agenda things 17:04:49 https://github.com/w3c/csswg-drafts/issues/11775 17:04:49 present+ 17:04:59 … next week starting off with overall issue from ChrisL about font privacy 17:05:07 … people from Brave will be joining 17:05:15 … talking about how are going to solve font fingerprinting 17:05:20 present+ 17:05:37 uhhhhh who request skipping the reading flow items 17:05:50 … have a good problem about the problems for privacy and lack of access for local fonts and bunch of differnet issues about possible solutions but have not gotten people volunteering to work on implementing and trying out these 17:06:07 … would like to get to this next week: some commitment to working on these things to get past the formal objection 17:06:15 https://github.com/orgs/w3c/projects/113/views/1 17:06:28 astearns: second thing is we have this project (link) that has a numbe rof issues in flight for scope 17:06:36 … and scope is part of this years interop, so we should proably finish up 17:06:44 … ptal a the items in the inteh progress section 17:06:53 … most likely will have a breakout session 17:07:20 chrishtr: want to come back to the agenda 17:07:32 … who requested to remove the reading flow issues? 17:07:39 Rossen3: a member, doesnt matter 17:08:05 TabAtkins: we were discussing these already last week, werid that it gets pushed out 17:08:23 Rossen3: we respect the request of any member of the wg if they want to move bv they need more time 17:08:40 TabAtkins: bizarre that this is secret 17:08:57 Rossen3: if the person wanted to request this publicly then they would have done so 17:09:14 TabAtkins: in general, we are not comfortable with things getting pushed away for secret reasons 17:09:23 astearns: the reason is not secret, they needed more time 17:09:37 TabAtkins: but nobody knows who it was, which is bizarre 17:09:53 Rossen3: this has happened before 17:10:13 astearns: one thing we can do to make this better to post to the private list about it 17:10:22 … instead of sharing it on top of the meeting 17:10:26 TabAtkins: yes, please 17:10:28 +1 to that suggestion 17:10:40 chrishtr: that’d be great, thank you. 17:10:58 github-bot, take up https://github.com/w3c/csswg-drafts/issues/6245 17:10:58 Topic: Interpolate values between breakpoints 17:10:58 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6245. 17:11:43 TabAtkins: elika and i were looking over this and there is a generic request to interpolate values based on some othe rprogeress value 17:11:51 … can be done by hand with calc, but does not work for all values 17:11:56 … or there are complex ways to interpolate 17:12:09 … seem slike a reasonable thing, that if you can do atransition, you can get the value for it too 17:12:22 … upon review of the use-case, what we were tyring in the spec was not good enough 17:12:27 … currently not implemented, so can start over 17:12:32 … new proposal 17:12:36 q+ 17:12:40 … two notions of interpolation 17:12:46 Writeup is at https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2661545284 17:12:48 … 1. mixing of two values 17:13:03 … 2. interpolate values in series, more like linear() for timing or gradients 17:13:06 are the existing spec'd functions the progress() functions? 17:13:14 … both are nearly identical, but when you reach 3 values they differ a lot 17:13:21 … can model either with the other, but frustrating and weird 17:13:32 … prop to introduce mix and map 17:13:34 weinig: https://drafts.csswg.org/css-values-5/ 17:13:38 … mix = … 17:13:51 … syntax proposal in the issue 17:13:52 q+ 17:13:57 … thoughts, ideas, …? 17:14:07 https://github.com/w3c/csswg-drafts/issues/6245#issuecomment-2685663483 17:14:07 ack lea 17:14:10 lea: posted my thoughts on this link here 17:14:25 … when i started writing that i was not too crazy about introducing mor efunctions 17:14:35 … wanted to overload the exsting mixing functions 17:14:50 … but while writing my feedback it would make sens to have a new function (if it has a good name) 17:15:02 … maps typically help you transform 1 value into another 17:15:08 … (example) 17:15:14 … several requests had to add mapping to css 17:15:31 … even though sth like calc-map() or whater-map() it overloads the concept and now mapping is 2 diff things 17:15:40 … also confusing to be using an established concept in a diffefernt way 17:15:44 … interpolate is long and technical 17:15:56 … brainstormed a bit (see table in comment) 17:16:07 … leaning towards the name scale which gives a nice color-scale 17:16:10 … and calc-scale 17:16:13 … not ideal for images 17:16:22 … also huge +1 for solving this use case 17:16:30 … is major in design systems and tokens 17:16:42 … so yeah 17:17:02 TabAtkins: not attached to the name, we chose map bc interpolate was bad for your reasons and its also short like mix 17:17:06 +1 17:17:07 … scale seems appropriate 17:17:18 … having a hwole family of related fns the worry 17:17:19 We weren't particular about the name, just needed one. 17:17:23 a little worried about our existing scale property 17:17:40 ack weinig 17:17:42 weinig: which of the css-values=5 fns is this replacing? 17:17:51 TabAtkins: the mix functions, not the pgoress ones which are inputs to these 17:17:55 weinig: got it 17:18:07 … other suggestion: blend 17:18:14 … bc that is often the result 17:18:21 … proble with scale is that we already have scale() 17:18:30 TabAtkins: only obj to blend is that it is a close synonym to mix 17:18:36 +1 to TabAtkins . Also `blend` sounds related to blend modes 17:18:39 … the better we can help authors remember which is which is good 17:18:42 lea: +1 17:18:50 … and also bend sound related to blending modes 17:19:01 TabAtkins: prolly cant avoid some semantic overlap 17:19:06 Rossen3: sounds like we are converging? 17:19:13 fantasai: yes, want to go over what it is 17:19:37 q+ 17:19:52 … the fn takes a bunch of top level params and what th eprogrsss is within the scale and a list of stops similar to linear-gradient(0 with an interpolation option between the stops (easing fn for example) 17:20:27 … and then the top level options are a source for the progress, also giving you an option of transofmring that source thorugh an easing function, and an option saying each step gets its own easing 17:20:33 … that is the top level 17:20:48 … and then the stops have a syntax where it is `stop: value` and you interpolate between th stops 17:20:50 color: color-map(media-progress(width, 0px, 2000px), 17:20:50 0%: red, 17:20:51 100%: blue); 17:21:01 color: color-map(media(width), 17:21:01 0px: red, 17:21:02 2000px: blue); 17:21:02 fantasai: also introducing new fns 17:21:12 … percentages, pull the value out directly 17:21:25 … pull out the start and end values, package them up together and put m in a variable 17:21:33 … so the progress functions are worth keeping for that reason 17:21:38 … Qs? 17:21:46 ack lea 17:21:52 lea: dont quite understand by vs each 17:22:05 … its a good design goal to be compatible with gradients 17:22:22 … it could even b ea design goal that everyting in side color-scale is a valid gradient 17:22:28 … good for rease and debugging 17:22:51 … the syntax with colons of positions adn values. not sure the reduction with the rest of CSS is warranted by the usability adv 17:22:53 … seems small 17:23:11 … breaking compat is a good thing if it gives you a significant advantage, not sure that is the case here 17:23:21 … suggestion to stick to existing syntax 17:23:30 … (missed: gradients) 17:23:41 … where you can percentages 17:24:05 animating-timing-function vs animation-easing 17:24:16 fantasai: diff between by and each is wehther you are applying easing between two stops or to the entiry of the progress value. Animations have this distinction. Can ease the entire timilne or in between keyframes. 17:24:34 … have the ability to put easing between any two stops, or the whole thing upfront 17:24:37 s/(missed: gradients)/we would need to make it mandatory that the stop position comes after the value in the calc version, as otherwise there would be disambiguation problems/ 17:24:43 … that is the difference 17:24:55 estelle has joined #css 17:24:57 … about the colon in the stop syntax: that is bc of the parsing ambiguity 17:25:04 … cant know the reeturn value upfront 17:25:18 … other optino is to align with if() and use semicolons 17:25:21 … not sure though 17:25:23 q+ to ask about multiple positions, also use cases for each 17:25:34 TabAtkins: there are certain value types make it ambigious to read or actually ambiguious 17:25:42 … e.g. calcs() sometimes hard to read 17:25:52 … not obvious to a human sometimes 17:26:00 … more problematic is the generic map() that can do entire property values 17:26:03 … no way to know where the value ends 17:26:21 … so have to either put the percentages in a distinguished place (like now) or only require 1 17:26:32 … would not allow us to do 1 or 2 stops 17:26:53 … bc those fns have parsing difficulties if you try to mix things in, we decided to carry that through the whole family of functions 17:27:07 … making most of map fns look similar to ?? but hten some not , looks worse 17:27:10 ack lea 17:27:10 lea, you wanted to ask about multiple positions, also use cases for each 17:27:16 s/??/mix functions/ 17:27:29 lea: agree that constiency with eachother is more imporatnt than consistency with the rest of CSS 17:27:32 1 + 2px +3px 17:27:45 … not sure about the color … hard to read or disambiguation issue? 17:27:57 … for the generic no amount of syntax would work other than putting it first 17:28:10 fantasai: (missed) progress values. can have a stripe 17:28:26 lea: is the generic fn actually ahppening? remember we had one for mix but then had to drop it 17:28:51 TabAtkins: multiway interpolation is trickier but if its just for map you are only interpolating two values at a time – we already know how to do that 17:29:10 lea: this wont solve issue with generic, but at least fo rothers we coul dintroduce an at-keyword 17:29:14 … like red at 50% 17:29:18 … very readable 17:29:25 TabAtkins: but unfrotunately does not extend 17:29:35 … not the best, happy to discuss precise syntax more 17:29:43 … looking for objections about the general approach 17:29:53 Rossen3: so now are gonna stick with the map? 17:30:02 fantasai: no, I meant `at 50%` 17:30:04 q? 17:30:24 @ 50% might be kinda nice though :) 17:30:41 It avoids any parsing issues since @ is not otherwise valid 17:30:43 can we have a proposed resolution? 17:30:49 TabAtkins: lets switch over to scale and continue discussing 17:31:00 lea: do we have a proposed resolution? take on work? 17:31:16 TabAtkins: yes: accept the approach we have outlined in the issue changing the map naming for scale and continue iterating on the design in the spec 17:31:18 PROPOSED RESOLUTION: Accept the general approach, change map naming to scale for now, iterate on syntax later 17:31:20 Rossen3: sounds reasonable 17:31:30 weinig: will the keyframes part remain as well? 17:31:38 TabAtkins: that is the plan, but also up for discussion 17:31:45 weinig: I think you should keep them 17:32:13 fantasai: Qs for syntax were about the separator keywords by vs each and the name of the function 17:32:15 Huge +1000 to solving this problem, this is huge. Some doubts about each (do we have use cases for it?) but we can sort out later 17:32:36 lea: +1, like I said in IRC 17:32:50 … its low level, but lack of being able to do this keeps cropping up all the time 17:33:01 fantasai: yes, need to thank scott for filing this and following up on it 17:33:12 Rossen3: Objections? 17:33:24 … none, so we are resolved. 17:33:30 RESOLVED: Accept the general approach, change map naming to scale for now, iterate on syntax later 17:33:53 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11408 17:33:53 Topic: [css2][css-tables] Do collapsed tracks also shrink the table wrapper box or only the table grid box? 17:33:53 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11408. 17:34:37 … first you layout the table without collapse, and then remove th ecollapsed tracks 17:35:21 … this is about collapsing of rows and cols 17:35:43 … typically it is ht eparent formatting context that decides th esize of a box, but here it is like the table and this can confus the parent FC 17:35:53 … was investigating what browsers do 17:35:58 … only checked gecko and blink 17:36:07 https://github.com/w3c/csswg-drafts/issues/11408#issuecomment-2563995794 17:36:09 q+ 17:36:15 … there is a table in this comment I linked to 17:36:28 … some shrink or do not shrink 17:36:51 … ?? they dont collapse which I think is right. would otherwise be bad if table is inside an inline-block 17:37:14 … when actually deciding final size of the table ther eare diferences 17:37:29 … gecko has wrapper table box and ?? box, and blink only has single box. 17:37:41 … in the inline axis gecko does not shrink the table wrapper box, only the table grid box 17:37:51 … this has nice properties lik avoiding conflicts with PFC 17:38:08 … some slightlly surprinsg things like cnetering with auto margins it only cneters the wrapper so could be off center 17:38:23 … blink has a single box and tries to shrink “both” things 17:38:37 …but it does not shrink in a flex row bc it could conflict with flex sizing algo I think 17:38:52 … what does it mean if the table is suddenly shrinking? 17:39:16 … does not shrhink for tables that have flex items in a row or if the table is abspos 17:39:24 … otherwise it behaves a if table wrapper shrinks 17:39:38 … for table grid gecko ??? it shrinks except for flex rows and abspos boxes 17:39:55 … things that are more itneresting in the block axis: both try to shrink as much as possible 17:40:08 … but in flex columns no browsers shrinks the intrinsic block contributions 17:40:32 … for final size of the tbl wrapper blocks gecko ???, blink doe snot shirnk the wrapper but doe shrink the grid 17:40:38 … not sure whatis going on. 17:40:46 … I like gecko’s inline-axis behavior 17:40:52 … not sure about the block 17:41:11 … like that a box can decide to if inline size conficts with PFC it can shrink 17:41:19 … there are several things to discuss here 17:41:36 ack iank_ 17:42:03 iank_: 1 thing I dislike is that when we set a height 100px on a table it will shrink both ??? seems like a ?? on the wrapper box side 17:42:16 … if we end up with resolution that keeps the wrapper box at 100px tha twould b egood 17:42:31 … some complexity … if all ?? size up to the inner grid box 17:42:34 … not sure what to do there 17:43:14 fantasai: for the margin case I wonder we could prolly compensate for that by either having the auto margins also do sth to the tabl egrid box or just saying authors should use the alignment properties to align both boxes 17:43:29 s/should/can/ 17:43:34 ack fantasai 17:43:34 fantasai, you wanted to comment on alignment 17:43:45 iank_: oriol, can you say why you don tlike affecting th eintrinsic contributions? 17:43:52 https://github.com/w3c/csswg-drafts/issues/11408#issuecomment-2653101446 17:43:55 oriol: see this link 17:44:24 … if you have a table that is inside an inline-block and the table has 2 cols, one of which is collapsed, and each coll has a cell with min-content size of 50 and max content of 100 17:44:36 … if you dont take collpased tracks into account the of the tbl is 200px 17:44:48 … if we decided to change this, it could be 200 but removing 1 col, so 100px 17:45:07 … problem is that when we lay out table for real, we only have 100px of avialbe space to give both cols 17:45:16 … so each would be 50px instead of 100px 17:45:37 … what will happen is that we end up with 1 col of 50px and its not the ideal size 17:45:40 iank_: makes sense 17:46:06 … making intrinsic block contributions match inline contributions would be the right way to go there for consistency 17:46:20 … and we likely are not constrained too much bc webkit doe snot have this feature yeat 17:46:31 … might need to think a bit more about the wrapper and grid box sizes 17:46:39 … the way that they work could be funky 17:47:14 Rossen3: Oriol, where do you want to take this? 17:47:25 … the issue or try for a resolution? 17:47:37 oriol: if Ian wants to think more about it, we can bring back to the issue 17:47:55 … this even belongs to CSS2, so a bit weird that we have this 17:48:00 … but can bring back to the issue 17:48:18 iank_: if you (oriol) write down possible solutions, that would be helpful 17:48:23 … what you think is the best 17:48:30 … I can also propose something 17:48:37 Rossen3: So let’s take it back to the issue 17:48:51 … perhaps we can have a proposed resolution by the next time 17:48:59 github-bot, take up https://github.com/w3c/csswg-drafts/issues/10881 17:48:59 Topic: [css2][css-tables] Does `overflow` apply to table-wrapper or table-grid? css-tables contradicts CSSWG resolution 17:48:59 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10881. 17:49:16 oriol: this is conflict regarding what box overflow applies to 17:49:29 … spec says that by default properties that you set on a table element apply to the grid not the wrapper 17:49:56 … and then for overflow it originally was not defined in CSS2 but then it was added in an errate that the overflow applies to the box not the wrapper 17:50:13 … thatwas a resolution but only part of it got in CSS2 17:50:26 … but then in CSS3 that became the opposite 17:50:37 … so we should decide if it applies to the box or the wrapper 17:50:49 … elika is of the opinion that is more useful on the grid 17:51:00 … I tested if you use contain: paint it applies to the wrapper 17:51:08 … so would be Ok to apply to the grid 17:51:31 … reason tables-3 says it applies to the wrapper it is bc of overflow … which that applies to the wrapper 17:51:51 … so need to decide if it applies to the grid, affects transform style sof the grid or the wrapper, should it apply to the same box? 17:51:57 … not that familiar with transforms 17:52:06 Rossen3: Comments? 17:52:17 dholbert: we got a bug filed on this a while back in firefox 17:52:23 … spec maybe aligns with what gecko is doing 17:52:30 q+ 17:52:35 … i did file bugs in chromium and webkit, but dont know the progress of those 17:52:42 … this is about the overflow applying 17:52:47 … IIRC the spec says wrapper 17:52:53 ack iank_ 17:53:16 iank_: preference to apply to the wrapper making all of the ?? and transform style props to aply to the wrapper 17:53:17 q+ 17:53:21 … like clip and clip-path 17:53:26 … just for consistency 17:53:36 … suspect it is like … debatable which is most useful 17:53:57 … if someone wants to clip inthe wrapper, then we allow clipping on the sectino elements which make that possible 17:54:05 … so I would like to keep everything on the wrapper 17:54:26 emilio: main diff here is wehter caption and so on get clippped 17:54:43 … as an author I expec thte ?? behavior that what scrolls decides the content of the table 17:54:54 … otherwise bottom captions become useless in scrollable tables 17:55:04 ack emilio 17:55:11 … would be odd to push ??? to the bottom of the scrollable table 17:55:23 iank_: you cant scroll right? 17:55:24 oriol: values other than visible or hidden 17:55:37 iank_: overflow: scroll on a table does not do anything right now 17:55:43 … like overflow hidden is treated as clip 17:55:56 … so therefore preference to keep everything on the wrapper 17:56:09 emilio: other thing we could do is apply to both, but could have observable difference 17:56:18 … in that case no strong preference though 17:56:29 … the caption thing still applies though right? 17:56:37 … I guess not, bc you clip outside of the captions vs inside 17:56:38 iank_: yes 17:57:07 fantasai: same thought as emilio: if we could make it scrollable obvs thing would be to scroll the table itself. 17:57:11 i don't think we'll be able to make scrolling work from a compat point of view. 17:57:22 ack fantasai 17:57:49 bramus: people want that, along with sticky headers 17:58:15 fantasai: if we want to do that eventually, would taking a decision to do it on the wrapper cause a problem? 17:58:27 iank_: tables and overflow:scroll have been around for long enough 17:58:37 … they cant really be made scrollable bc of style constraints 17:58:56 … if you set `height` it does not add … intrinsic block sizes override that 17:59:10 fantasai: there is the ?? algo to make that work 17:59:19 iank_: not an easy path to make tables scrollable 17:59:23 s/there is the ??in that case we'd need a new table-layout algo/ 17:59:24 … substantial rework to how they work 17:59:43 iank_: what was your point about sticky headers? 18:00:14 … we have sticky top rows, but stikcy cols is a different problem 18:00:20 Rossen3: we are at time 18:00:31 … not sure we can resolve right now, I think? 18:00:39 … table scrolling will take up more time 18:00:48 … seems like an interop nightmare 18:00:57 iank_: dont think we need to make tables scrollable int he near term 18:01:04 … could back ourselves in a corner 18:01:16 … if we ever make them scrollable, then we can change things 18:01:23 … sticking on the wrapper 18:01:30 fantasai: (missed) 18:01:41 iank_: putting it on the wrapper does not paint it into a corner 18:01:47 s/it/us 18:01:53 s/(missed)/as you note, we'd need an opt into a different algorithm 18:02:14 Rossen3: So can we decide on that? 18:02:21 iank_: if no-one objects, then yes 18:02:23 s/into a different algorithm/into a different algorithm, so we could use that as a switch for overflow as well/ 18:02:31 PROPOSED RESOLUTION: overflow applies to the wrapper box 18:02:32 PROPOSED: overflow applies to wrapper box 18:02:35 Rossen3: objections? 18:02:43 RESOLVED: overflow applies to the wrapper box 18:02:48 topic: none 18:03:05 Rossen3: next weeek we’ll start with the overflow issues 18:03:21 JoshT has joined #css 18:04:08 JoshT has joined #css 18:04:47 JoshT has joined #css 18:07:03 tantek has joined #css 18:07:10 Zakim, end meeting 18:07:10 As of this point the attendees have been kizu, flackr, oriol, kbabbitt, schenney, weinig, bramus, alisonmaher, lea, rachelandrew, JoshT, gfaujdar, chrishtr, castastrophe, miriam, 18:07:13 ... emilio, jfkthame, dholbert, keithamus 18:07:13 RRSAgent, please draft minutes v2 18:07:14 I have made the request to generate https://www.w3.org/2025/02/26-css-minutes.html Zakim 18:07:21 I am happy to have been of service, Rossen3; please remember to excuse RRSAgent. Goodbye 18:07:21 Zakim has left #css 19:01:37 Penny has joined #css 20:00:06 astearns has changed the topic to: HDR agenda: https://lists.w3.org/Archives/Public/www-style/2025Feb/0016.html 20:00:12 zakim, start meeting 20:00:19 Zakim has joined #css 20:00:24 zakim, start meeting 20:00:24 RRSAgent, make logs Public 20:00:25 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 20:03:17 pal has joined #css 20:04:10 smfr has joined #css 20:06:18 present+ 20:06:19 present+ 20:06:22 present+ 20:07:35 present+ 20:08:44 https://github.com/w3c/csswg-drafts/issues/11711 20:08:53 Said has joined #css 20:10:21 astearns: Will send an update on ChrisL's fingerprinting summary later this week 20:11:00 weinig: for https://github.com/w3c/csswg-drafts/issues/11711 someone from blink is needed for discussion because it would require chrome changes 20:11:08 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11678 20:11:08 Topic: [css-color-hdr] How should checking for percentages summing to 0 work in dynamic-range-limit-mix() when calc() is used? 20:11:08 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11678. 20:11:49 weinig: issue is that the spec for dynamic color mix has rules applied at parse time that check if value is zero 20:12:14 if all percentages add up to zero, they are invalid, but calc() may not know if it's invalid yet 20:13:09 options: either define at calc time what do in that scenario, mark as invalid at computed style time, or have it behave as if all percentages are the same; evenly divided 20:14:16 someone brought up the a concern with 50 high 50 low example, nothing constrained, you'd get 33/33/33 (not sure if I scribed that correctly) 20:14:48 currently we even split it, but worth considering when animating the ramps to zero 20:15:19 ChrisL: people will ramp it for animation so we should ensure it's not jarring 20:15:37 weinig: no current test for that.... but yes, should fix that 20:16:02 propose if all zero, treat as all at 33% 20:16:09 ChrisL: sounds reasonable 20:17:07 proposal: remove the sentence in spec that says if sum is zero, treat as invalid 20:17:39 weining: i can take on an item to work up the correct prose for that change to splitting the percentage 20:18:19 s/treat as invalid/treat as invalid; possibly add new prose about splitting the percentage, and update tests/ 20:18:47 astearns: no objections resolved... 20:19:03 rrsagent, make minutes 20:19:05 I have made the request to generate https://www.w3.org/2025/02/26-css-minutes.html jcraig 20:19:31 RESOLVED: remove the sentence in spec that says if sum is zero, treat as invalid; possibly add new prose about splitting the percentage, and update tests 20:19:50 github-bot, take up https://github.com/w3c/csswg-drafts/issues/11307 20:19:50 Topic: [css-color-hdr] How should multiple layered elements with different `dynamic-range-limit` values behave? 20:19:50 OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11307. 20:20:38 weinig: for multiple layered elements, need more added to clarifying the model underlying what this property actually does 20:20:54 uses tone map example 20:21:46 s/map example/map compositing example to explain compositor controlling whether this is additional headroom/ 20:22:23 ChrisL: we have a brief section on compositing... would be good to get better text 20:22:48