15:55:54 RRSAgent has joined #css 15:55:54 logging to https://www.w3.org/2021/07/21-css-irc 15:55:56 RRSAgent, make logs Public 15:55:57 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 15:56:35 dholbert has joined #css 15:57:59 present+ 15:58:44 dholbert_ has joined #css 15:58:45 present+ 15:59:03 present+ 15:59:47 present+ 16:00:06 Rossen: we'll give it couple of mins and start at :02 16:00:14 jfkthame has joined #css 16:00:16 present+ 16:00:31 present+ 16:00:33 present+ 16:00:41 present+ 16:00:41 present+ 16:00:45 present+ 16:01:00 present+ 16:01:05 present+ 16:01:42 alisonmaher has joined #css 16:01:48 present+ 16:01:49 dholbert_: it happens to all of us 16:01:58 present+ 16:02:04 sanketj has joined #css 16:02:09 IanPouncey has joined #css 16:02:16 present+ 16:02:37 lea has joined #css 16:02:41 ScribeNick: fantasai 16:02:58 chris has joined #css 16:03:18 present+ 16:03:24 present+ 16:03:32 present+ 16:03:32 https://wiki.csswg.org/planning/virtual-july-2021 16:03:38 emeyer has joined #css 16:03:42 Rossen_: Reminder about the vF2F 16:04:06 present+ 16:04:09 Rossen_: Please add yourself to the wiki 16:04:19 Rossen_: and add items for agenda 16:04:30 Rossen_: Any changes to agenda? 16:04:45 lea: Reminder that Color API breakout is right after this call 16:05:11 bkardell_ has joined #css 16:05:13 smfr has joined #css 16:05:23 Topic: Republishing 16:05:23 present+ 16:05:33 Rossen_: css-fonts-4 and css-fonts-5 16:05:35 GameMaker has joined #css 16:05:36 present+ 16:05:40 present+ 16:05:41 github: https://github.com/w3c/csswg-drafts/issues/6462 16:06:00 Rossen_: I looked over changes, seems fine 16:06:04 Rossen_: Any objections? 16:06:14 RESOLVED: Republish CSS Fonts L4 and L5 16:06:35 Rossen_: Next is updated WD for CSSOM 16:06:39 note some broken link issues that need to be fixed before publication https://github.com/w3c/csswg-drafts/issues/6463 16:07:00 Rossen_: some PR merged recently 16:07:11 Rossen_: emilio, chris any thing holding back? 16:07:18 present+ 16:07:19 chris: Some broken links, don't know what to replace with 16:07:36 github: https://github.com/w3c/csswg-drafts/issues/6446 16:08:01 emilio and chris will look into it 16:08:12 Rossen_: Any objections to republishing? 16:08:22 RESOLVED: Republish CSSOM 16:08:30 rrsagent, here 16:08:30 See https://www.w3.org/2021/07/21-css-irc#T16-08-30 16:08:33 Topic: Highlight API 16:09:08 dholbert has joined #css 16:09:14 Topic: Multiple Document Highlights 16:09:18 github: https://github.com/w3c/csswg-drafts/issues/6417 16:09:50 sanketj: Issue is Highlight API doesn't cases where multiple highlight trees and multiple documents interact 16:10:03 sanketj: e.g. in same-origin iframes, ranges can be passed back and forth 16:10:18 sanketj: Should we be allowed to have highlight covering ranges in different windows? 16:10:26 sanketj: Can a single highlight cross documents? 16:10:36 sanketj: Could reject these cases by throwing 16:10:42 sanketj: I would propose something different 16:10:50 sanketj: I have a 3-part proposal 16:10:50 Dan Clark is talking, not sanketj 16:11:00 sanketj: 1st, should allow highlight to contain ranges from multiple trees 16:11:08 sanketj: 2nd, allow highlight to be added to multiple registries 16:11:26 sanketj: might mean tracking multiple highlight registries for each highlight 16:11:38 sanketj: When a highlight registry painting, will only paint highlights associated with that document 16:11:48 s/sanketj/dandclark/g 16:11:58 sanketj: If it finds a range in another window/iframe, it does not reach over there and paint there. Only paints within its own document 16:12:04 q? 16:12:05 sanketj: Wanted to get people's thoughts on this proposal 16:12:06 q+ 16:12:32 smfr: proposal seems to be the most complex version of the solution, allowing highlights to involve multiple documents and allowing them to live in multiple registries 16:12:39 q+ 16:12:41 bradk has joined #css 16:12:46 smfr: What's the reason to avoid the simpler solution, of restricting to single document and single registry 16:12:59 sanketj: Philosophical whether to reject early or to be more permissive 16:13:14 sanketj: If I create a highlight but don't give it any ranges, is it associated with that document? 16:13:17 sanketj: ... 16:13:28 sanketj: Do I need to do comparison whether new ranges in another document? 16:13:36 sanketj: Some interesting cases there I don't know how to work through 16:13:45 q+ 16:13:45 sanketj: We could say something like highlight is associated with document that created it 16:13:53 sanketj: and registry associated with that document 16:14:00 sanketj: and if try to insert range from another document, throws 16:14:01 present+ 16:14:01 fantasai, stop associating all this with sanketj, it's dandclark 16:14:06 smfr: That would be my preference for the first version 16:14:06 ack smfr 16:14:24 s/sanketj/dandclark/g 16:14:44 ack sanketj 16:14:46 sanketj: Seems fine, pref for first version 16:14:59 sanketj: Need to define which exception to throw 16:15:16 sanketj: different documents, multiple registries, and multiple ranges to single highlight, need to define exception for each of those 16:15:27 sanketj: might be simpler to allow those cases and don't paint the ranges in different document 16:15:35 (sorry, no mic) Strongly prefer associating it with the creator document and throwing on mismatches. There's precedent for this w/ constructable sheets, FontFace, etc 16:15:47 s/first version/first version. If necessary could add these abilities later./ 16:15:57 Agree with emilio - we already have a decent precedent to only allow same-document usage. 16:16:14 Rossen_: Any other comments/feedback? 16:16:23 I also agree et. all with throwing 16:16:48 sanketj: If we are throwing, do we want just one exception or separate exceptions for each case? Seem like slightly different operations 16:16:55 TabAtkins: I think they all boil down to same category 16:17:00 TabAtkins: using something in a wrong context 16:17:22 Rossen_: if this proposed path forward works for you, suggest go back to GH and work out the details in terms of exceptions 16:17:28 Rossen_: once all happy, come back and we can resolve 16:17:35 dlibby has joined #css 16:17:35 Rossen_: unless you feel strongly on resolving this path forward now 16:17:50 dandclark: Sounds good, thanks 16:18:05 jensimmons has joined #css 16:18:19 Rossen_: proposal is that we associate with creator document and throw on mismatches 16:18:22 SGTM 16:18:22 Rossen_: any objections? 16:18:28 +1 to resolution 16:18:49 RESOLVED: highlights associated with creator document. Throw on mismatches when registering ranges/etc. 16:18:56 present+ 16:19:05 q 16:19:07 Topic: highlights and default values for styles 16:19:10 ack emilio 16:19:18 github: https://github.com/w3c/csswg-drafts/issues/6417 16:19:56 github: https://github.com/w3c/csswg-drafts/issues/6375 16:20:33 dandclark: CSS Pseudo specifies default values for certain native highlights. Should there be any defaults for custom highlights? 16:20:48 dandclark: Since these are author-defined highlight, don't think should define any styles in UA styles 16:20:51 dandclark: also no way to do this 16:21:10 dandclark: Seems better to let it just inherit from originating element 16:21:26 dandclark: Might want to make explicit that UA should not give default styles 16:21:36 s/dandclark/sanketj 16:21:38 fantasai: I agree with this 16:22:00 s/dandclark/sanketj 16:22:01 s/dandclark/sanketj 16:22:03 s/dandclark/sanketj 16:22:25 fantasai: Doesn't make any sense for UA to add default styles to custom highlights 16:22:29 Rossen_: Any objections? 16:22:40 RESOLVED: UA does not add any default styles to custom highlights 16:23:03 Topic: Compressible Elements with Aspect Ratio 16:23:08 github: https://github.com/w3c/csswg-drafts/issues/6341 16:23:42 TabAtkins: Forgot to discuss this last week... 16:23:50 iank_: I won't be around next week 16:23:53 github: none 16:24:24 Rossen_: Anything urgent? 16:24:34 iank_: patch waiting in my queue is all 16:24:51 TabAtkins: I just haven't had a chance to think through it. Though you're probably right anyway 16:25:00 Topic: Order property definition 16:25:10 github: https://github.com/w3c/csswg-drafts/issues/5865 16:25:30 TabAtkins: Brought up that the definition of order only mentions flex items, but also applies to other layout modes (grid at least) 16:25:40 TabAtkins: so we should be generalizing this property, but then where should it live? 16:25:47 TabAtkins: We think Display is the most appropriate place for it 16:25:57 +1 for display 16:25:58 TabAtkins: Would like resolution to move it to Display, unless someone has a better idea 16:26:14 Rossen_: Feedback or other opinions? 16:26:16 smfr: Seems fine 16:26:18 Display or maybe position sounds good 16:26:25 Rossen_: objections? 16:26:31 RESOLVED: Move order property to Display module 16:26:57 Topic: Indefiniteness when sizing grid track inside flex item 16:27:00 github: https://github.com/w3c/csswg-drafts/issues/4852 16:27:22 oriol: Case where we don't have interop between FF and Chrome 16:27:34 oriol: When have column flex container which has for example height set to some value bigger than the content 16:27:43 oriol: This flex item has a flex that causes it to expand 16:27:47 oriol: and this flex item is also a grid container 16:27:53 oriol: which contains an auto row 16:28:04 oriol: usually auto rows, if you have free space at end of track sizing, they are expanded to cover this extra space 16:28:15 oriol: specifically for the case where we set the height property, we have interop 16:28:27 oriol: but instead of setting height on flex container you set min-height, in Chrome the auto height doesn't grow 16:28:48 oriol: At first I was confused and thought Chrome was right, but actually after some feedback from iank_ I think it's actually Firefox which follows the spec 16:28:59 oriol: iank_ also said that he's willing to change Chrome to adapt to what FF is doing 16:29:13 oriol: So I guess we can close this no change, agreeing that Firefox is the right behavior 16:29:54 Rossen_: comments/objections? 16:29:56 iank_: ... 16:30:03 fantasai: I think authors would be happy with this resolution 16:30:21 RESOLVED: close no change, firefox is correct 16:30:52 Topic: Does definite flex-basis always cause main size definite? 16:30:59 github: https://github.com/w3c/csswg-drafts/issues/4311 16:31:13 TabAtkins: There's an example in the issue 16:31:24 TabAtkins: Column flexbox with a flexible child 16:31:34 TabAtkins: child has a definite height, but it is flexible so can become larger or smaller 16:31:44 TabAtkins: Flex item has a child with a percentage height 16:33:25 my phone hung up, one sec 16:33:42 OKAY I CAN'T MAKE A CALL ANY MORE 16:33:46 welp 16:34:04 fantasai: Spec says this case is indefinite, and percentage won't resolve 16:34:12 fantasai: But implementations do resolve 16:34:20 fantasai: so should we change the spec to match implementations? 16:34:53 iank_: I think all of the implementations are following the spec here 16:34:59 iank_: in that they are not resolving ... 16:35:05 cbiesinger: Not true 16:35:13 cbiesinger: Testcase is red, which means it is resolving 16:35:26 cbiesinger: Interesting thing here is that the percentage would resolve outside a flexbox 16:35:38 cbiesinger: it doesn't resolve if you put it inside the flexbox (per spec) 16:35:42 cbiesinger: I doubt authors expect that 16:36:46 fantasai: Originaly definiteness was identifying cases where percentages are very simple to calculate 16:36:55 fantasai: and we restricted percentage resolution to these cases 16:37:04 fantasai: but authors would be happier to resolve more often 16:37:12 fantasai: so if implementers are already doing it, might as well match the spec 16:37:21 iank_: this seems fine to me 16:37:51 fantasai: does mean that concept of definiteness is more complicated 16:38:18 cbiesinger: Want to mention, in Chrome we only take into account the width/height property, not the flex-basis. But that's probably a Chrome bug 16:38:29 Rossen_: Do we know if this is safe to change? 16:38:30 q+ 16:38:47 fantasai: Planning to match spec to implementations, so shouldn't have any concerns 16:38:54 q+ 16:38:58 ack jensimmons 16:39:11 jensimmons: Seems folks doing a good job of raising flex bugs and addressing them 16:39:24 jensimmons: Would love to ask if filing bugs against WebKit as well, seems our implementation is same as Chrome 16:39:31 iank_: No bug required here, spec is aligning ot implementations 16:39:35 jensimmons: on this issue, but not last one 16:40:06 cbiesinger: should be a wpt test also 16:40:18 Rossen_: WPT tests should raise to webkit 16:40:18 no 16:40:28 ack jensimmons 16:40:32 ack dholbert 16:40:47 dholbert: Wanted to clarify what the proposed change is here. Are we making the spec match implementations in this case? 16:41:08 I think change is: definite flex-basis makes the size definite, even if the item is flexible 16:41:10 Present+ 16:41:40 dholbert: I think that doesn't match what we do 16:41:49 dholbert: It might be that this case is triggering a more subtle situation 16:42:09 fantasai: That's interesting, we should investigate 16:42:18 dholbert: I think intent of our behavior is to match the spec 16:42:36 dholbert: We do check if flex item is flexible when testing for flexible flex-basis, to see if we want to make item definite 16:42:51 cbiesinger: I feel like you and I had a discussion about this years ago and you were going to match our behavior 16:43:00 dholbert: We fixed a number of bugs in last 6 months also 16:43:06 dholbert: so maybe previously did something more esoteric 16:43:13 bradk has joined #css 16:43:39 fantasai, rossen: maybe need to go back to GH to figure out 16:43:57 q? 16:44:10 Topic: single-color scrollbar-color 16:44:16 github: https://github.com/w3c/csswg-drafts/issues/5651 16:45:22 sorry, was muted 16:45:30 fantasai: so one thing discussed is whether scrollbar-color should accept a single color, auto-generating the second color from the first 16:45:54 fantasai: another is around allowing 'auto' as a keyword in the two-value syntax, explicitly triggering auto-generation of the other color 16:46:06 fantasai: We put it on the agenda to ask if there was interest in allowing this 16:46:13 I'd prefer not to add this unless there's strong author demand for it 16:46:23 q? 16:46:25 Not opposed per se but... 16:46:30 q+ 16:46:58 lea: I think there should be some defined algorithm for UA to generate other color 16:47:17 lea: reasonable for authors to define which color they want to alter, and UA to define other color 16:47:35 lea: Would prefer that option rather than specifying only one color and having magic other color 16:47:58 TabAtkins: ... 16:48:08 lea: Should be possible to specify one color 16:48:21 smfr: Wanted emilio to clarify, want single color to be invalid? 16:48:32 s/.../note that the spec currently requires two colors, so we'd first have to agree to allow only one color before the rest becomes relevant/ 16:48:34 emilio: So far, Firefox requires 2 colors, and I haven't seen anyone particularly complain about that 16:48:52 smfr: I'm not opposed to a single color, but some ambiguity around whether lightening or darkening to generate the other color 16:48:56 smfr: esp with dark mode 16:49:02 smfr: might need to specify somehow 16:49:03 q+ 16:49:14 I'm on the side of "just have the author provide both" (aka no spec change), I think 16:49:26 ack smfr 16:49:49 lea: wrt dark mode and whether UA darkens or lightens 16:49:55 lea: that has to depend on the color as well 16:50:07 lea: defined which direction to go, then what do you do when author specifies black? 16:50:20 smfr: That's my point, there has to be a defined threshold where UA flips lightening vs darkening 16:50:31 smfr: maybe dark mode is not relevant, mayb authors provide different colors 16:50:39 q+ 16:50:59 ack lea 16:51:00 lea: I think we're discussing minutiae of specifying a single color 16:51:06 lea: but there's no consensus on whether this is desirable 16:51:32 emilio: Same issue that smfr mentions is already a thing with accent-color 16:51:44 emilio: Scrollbar-color already needs to synthesize other colors, e.g. for :hover effects 16:51:57 emilio: If there's a strong desire to auto-generate track color... I'd rather not 16:52:12 emilio: Authors might get what they want in some browsers and something different in other browser 16:52:29 smfr: Ideal way to specify would be to just use color-5 functions 16:52:35 smfr: Similar to ridge/groove 16:52:36 Yeah, unlike accent-color, this is a place where we absolutely know where and how each color is going to be used. Auto-generating colors would be purely a convenience, not a necessity like in accent-color. 16:52:48 s/groove/groove situation 16:53:23 fantasai: main question is, do we want to do this or do we want to defer 16:53:30 Rossen_: what's the consensus? 16:53:39 smfr: I think it's nice to have, but fine to defer to scrollbars-2 16:53:42 emilio: same 16:54:02 Rossen_: proposed to defer to l2, any objections? 16:54:07 RESOLVED: Defer to L2 16:54:27 Rossen_: Encourage folks to engage on the issue and continue discussion there 16:54:33 Topic: stick scrolbars 16:54:43 github: https://github.com/w3c/csswg-drafts/issues/2252 16:54:57 Rossen_: Asking if possible to have position:sticky horizontal scrollbar 16:55:26 fantasai: this issue is a clear case of an unofrutnatue user situation 16:55:47 fantasai: Very large code block, with overflow:scroll so you can scroll horizontally, but it's also tall enough that the horizontal scrollbar is off the screen 16:56:06 fantasai: Person trying to read has to scroll down to reach the scrollbar, scroll horizontally, then scroll up to see the content 16:56:10 fantasai: Which is a very bad UX 16:56:20 fantasai: So wondering if there's a way to make a horizontal scrollbar stay "above the fold" 16:56:35 fantasai: florian and i discussed this; you can't just position:sticky the scrollbar (it doesn't exist) 16:56:41 fantasai: Maybe we can do something else 16:56:45 q+ 16:56:53 fantasai: Or maybe it's just quality-of-implementation, and browsers could handle this themselves 16:57:30 smfr: seems only case for ... 16:57:36 TabAtkins: No, if the box is tall enough, this is a problem 16:57:48 smfr: That's 2 separate scrollers right? document scroller and inner scroll container 16:57:56 TabAtkins: right, but document scroller isn't caausing it 16:58:07 TabAtkins: the problem is the inner scroller is too tall to be visible within outer scroller 16:58:13 smfr: I understand the problem 16:58:20 smfr: quality of implementation seems difficult 16:58:37 bradk has joined #css 16:58:43 smfr: UA wouldn't know whether to add sticky scrollbar, might obscure some other content 16:59:03 smfr: Other solution might involve... 16:59:07 smfr: need to think about it 16:59:43 Rossen_: maybe continue conversation back in issue, come back to it next week or afterwards 17:00:36 ε-present+ 17:00:53 Topic: end 17:01:05 Zakim, end meeting 17:01:05 As of this point the attendees have been castastrophe, argyle, Morgan, Rossen_, dandclark, emilio, rachelandrew, plinss, dholbert_, cbiesinger, jfkthame, TYLin, alisonmaher, oriol, 17:01:08 ... sanketj, chris, lea, fantasai, miriam, smfr, bkardell_, GameMaker, chrishtr, bradk, dlibby, dbaron[m] 17:01:08 RRSAgent, please draft minutes v2 17:01:08 I have made the request to generate https://www.w3.org/2021/07/21-css-minutes.html Zakim 17:01:10 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 17:01:14 Zakim has left #css 17:02:29 chris has changed the topic to: Color breakout 17:02:54 can the zoom link get shared here? i just tested 2 i had and neither seemed correct 17:02:56 zoom 17:03:08 I tried to join the color meeting, but zoom said the meeting was being recorded and by joining i would be consenting to it, so I had to hang up. 17:03:34 hober: are you not allowed to join recorded Zoom meetings? Should we not record? 17:03:35 (as a matter of policy, I do not consent) 17:04:00 I would like to join the call and can't so long as it's being recorded. 17:04:34 the recording has been stopped 17:04:37 thanks! 17:04:42 I see no action items 17:05:07 RRSAgent has joined #css 17:05:07 logging to https://www.w3.org/2021/07/21-css-irc 17:05:34 TabAtkins: we are waiting for you :) 17:06:27 yup, was getting coffee, one sec 17:06:51 Rossen__ has joined #css 17:09:00 i keep joining an empty color group meeting 17:09:05 cant find whatever is latest 17:09:18 It would be helpful if dial-in information was sent to the list 17:10:56 Topic: Color API discussion 17:11:00 github: https://github.com/w3c/css-houdini-drafts/issues/1047 17:11:58 scribenick: fantasai 17:12:08 present+ 17:12:17 present+ 17:12:19 present+ 17:12:28 present+ 17:12:29 present+ 17:12:34 Rossen_: Do we have a list of issues to resolve on? 17:12:40 lea: Chris and I prepared some slides 17:12:54 lea: since last time we discussed was confusing 17:13:01 lea: Tab, feel free to interject 17:13:10 Rossen_: Do we have something we want to resolve? 17:13:23 pal has joined #css 17:13:29 lea: I think it's, do we want to have a separate color API, or do we want to use the CSS color value api for everything in the Web platform 17:13:42 lea: Where should work be done, do we have one or two APIs 17:13:59 The readme has some more overview stuff: https://github.com/LeaVerou/color-api/blob/main/README.md 17:14:15 Rossen_: Motivation kicking off these things was, we had another review of color-related things with the TAG 17:14:25 Rossen_: at the time it was very apparent that we have more and more color discussion 17:14:55 Rossen_: they all seem to circle around whether we use color functionality vs type of color vs who is responsible for converting things, who is responsible for caring whether a particular type is safe to take from HTML to Canvas and still making sense 17:15:01 Rossen_: Hey, can we take a step back and define 17:15:14 Rossen_: First, there's a lot of science and calculations going into color and defining the functionality of color 17:15:24 Rossen_: having one place where this is made available to platform would be great 17:15:37 Rossen_: Then, if we have this functionality and it is well encapuslated with good APIs, how do we create a type of this and where does it go? 17:15:44 Rossen_: Is it a CSS value, is it an object, etc. 17:15:56 Rossen_: I'm hoping that here we'll at least arrive and all agree that well, we need all of this stuff 17:16:00 Rossen_: and also figure out where it all goes 17:16:17 lea: Current situation in Web platform is basically passing around strings, so I think we all agree it needs to be improved and become object-oriented 17:16:43 chris: worse actually, it was originall srgb, and now trying to pass around wider-gamut colors as srgb strings 17:17:01 Rossen_: let's start with functionality first 17:17:13 Rossen_: Chris and lea did a bunch of work to define functionality of color conversion 17:17:17 Rossen_: and different color spaces 17:17:23 Rossen_: one of the major functional requirements from this effort 17:17:29 Rossen_: where is this work currently? 17:17:33 lea: Can i switch to the slides? 17:18:14 florian: Can you send a copy to www-archive? 17:18:27 [slide 2] 17:18:45 lea: Colors need to be used as input and output for various APIs (canvas, cssom, input type=color, etc.) 17:18:53 lea: also authors themselves want to do things with colors 17:19:07 lea: and do many different kinds of color calculations 17:19:12 lea: ideally color API would cover all this 17:19:30 pierre: Who wants to do this? I think most authors don't want to do this. 17:19:42 pal: Likely to be doing wrong, even with API 17:19:46 pal: so want to establish who wants this 17:19:49 s/pierre/pal/ 17:20:02 lea: some requirements that Chris and I think important for such API 17:20:13 lea: It should be color-space agnostic, not privilege e.g. sRGB 17:20:18 lea: It should be compatible with HDR 17:20:24 lea: It needs to be extensible 17:20:36 lea: a native API is less extensible than a library, but good ot add extensibility 17:20:43 lea: And API should follow layered design 17:20:47 lea: so usable by non-experts 17:20:51 lea: but also useful for experts 17:21:05 chris: This is difference between color library we wrote, and color API for the platform 17:21:13 chris: our library had everything we could think of that could be useful 17:21:24 chris: tries to do everything out of the box 17:21:32 chris: but for color API, should be core set, that you can extend if needed 17:21:50 lea: Whole debate started a few months ago because there was a proposal by Canvas to accept and produce CSSColorValue objects 17:22:06 lea: This is an abstract CSSColorValue that inherits from CSSStyleValue 17:22:12 lea: part of typed OM 17:22:22 lea: Multiple subclasses that correspond to specific CSS syntactic constructs 17:22:28 lea: e.g. CSSRGB that corresponds to rgb() 17:22:32 lea: CSSHSL 17:22:37 lea: CSSColor that's a color() function 17:22:46 lea: each has different API shapes, getters for each argument 17:22:51 lea: also different constructors 17:23:02 lea: e.g. accepting red/green/blue positional arguments for rgb 17:23:08 lea: There's a color space conversion function 17:23:13 lea: it's an early-stage spec, no impls yet 17:23:21 lea: Advantage of using it everywhere is there would be only one object 17:23:29 lea: and good integration with CSS out of the box 17:23:49 lea: downsides revolve around the issue that CSS Color Value is designed to represent syntactic constructs 17:23:52 lea: not actual color points 17:23:59 lea: e.g. there are two variants for rgb 17:24:07 lea: one for rgb() fucntion, one for color() function 17:24:12 lea: you get diferent objects for these 17:24:21 lea: also it's not a string, but csskeywordvalue 17:24:32 lea: and coordinates are values, so need to do color.r.value to read the value 17:24:40 lea: because this is all for represnting parsed syntax 17:24:54 lea: these are not issues that can be solved by iterating on the API design 17:25:00 lea: although it has improved a lot since original 17:25:09 lea: because it is exiting for syntactic purpsose 17:25:21 lea: if we make it easier to use for color points, it will become more difficult for the uses it was designed for 17:25:37 lea: Stepping back, chris and I designed a library for color 17:25:50 lea: There was CSS meeting where we resolved to learn from this work and design a color API 17:25:58 lea: We drafted a spec [links here] 17:26:14 lea: ... 17:26:30 lea: API has improved quite a lot, even this week, since Tab sent us some very nice feedback 17:26:46 lea: Review the design 17:26:49 [slide 10] 17:26:51 https://docs.google.com/presentation/d/1Pkcxwdej2nWqYr0F6dYHpxcMaUMb11w_YmbZmcUV6Gc/edit?usp=sharing 17:26:54 links are in the slides which will be sent after the call 17:27:02 lea: ... 17:27:08 lea: Color spaces represented by colorspace object 17:27:17 lea: color.alpha is a number 17:27:21 CSS Color Value draft: https://drafts.css-houdini.org/css-typed-om/#colorvalue-objects 17:27:24 https://projects.verou.me/color-api/ 17:27:25 lea: right now all mutable, but that's under discussion 17:27:36 lea: Color spaces are represented by ColorSpace objects 17:27:39 Draft explainer: https://github.com/LeaVerou/color-api 17:27:44 Color Object draft: https://projects.verou.me/color-api/ 17:27:47 lea: registried in ColroSpace.register() or can be anonymous 17:27:54 lea: would be nice to make happen 17:28:03 lea: but difficult to design API to not be less usable for common case 17:28:14 lea: color spaces are represnted by ID so don't have to look up objects 17:28:27 lea: color spaces declare their white point, coords, gamut, and conversion code to/from existing space 17:28:36 lea: so you delcare your base, and provide functions to base and from base 17:28:45 lea: this could create a tree of conversions, but in practice it's one or two hops 17:28:54 lea: e.g. hsl has base of srgb, but srgb would have a base of xyz 17:29:13 lea: I originaly designed to have an ICC profile, but that would make everything async 17:29:27 lea: so have a separate API that returns a promise to load profile 17:29:35 lea: once registered, cannot unregister color profile 17:29:41 [slide 12] 17:29:50 lea: have getters to get coordinates 17:30:00 lea: and set functions to maniuplate in any color space, which can be relative 17:30:08 lea: can be provided by object literal as well 17:30:19 lea: Gamut mapping is optional. Every is lossless by default 17:30:25 lea: shoudl be able to roundtrip without losses 17:30:31 chris: This is needed for ??? e.g. WebGPU 17:30:45 chris: if you set up canvas in P3, things might be out of gamut, but need to calculate 17:30:52 chris: can always ask to put in gamut if you want 17:31:02 lea: There are functions for toGamut mapping 17:31:14 lea: by default use LCH chroma, but can be any coordiante in any coordinate space 17:31:21 lea: unsure what to do with nonsensical 17:31:31 [slide 14] 17:31:41 lea: How do declare polar color space? 17:31:46 lea: What is a color space? 17:32:08 lea: various representations of srgb are all in the same color space, but treated differently... 17:32:21 lea: should there be some API level distinction between that and different color spaces? 17:32:24 lea: ... 17:32:32 lea: But there are some benefits to mutability as well 17:32:36 lea: also how to do HDR tone mapping? 17:32:47 lea: and what would be interaction between Color API and CSS 17:32:54 lea: would registered color spaces become available to CSS? 17:33:09 lea: do color spaces declared via @color-profile become registered ColorSpace objects once profile loads? 17:33:27 Rossen_: Thanks for clarifying discussion here and providing a lot of synthesized ifno 17:33:37 Rossen_: There's a lot of density 17:33:37 q+ 17:33:41 Why/who really needs this? Is CSSColorValue of Color object the right way for exposure? 17:33:52 Rossen_: The two primary questions that I took away from the discussion and overview are 17:34:00 Rossen_: challenge by pal, do we really need this? 17:34:05 Rossen_: that's one we can cover quickly 17:34:23 Rossen_: other one is, if we can walk away from this discussion with defining if CSS Color Value or Color Object is the right way to move forward 17:34:30 Rossen_: details can be worked through in GH issues 17:35:05 TabAtkins: Earlier I was a pretty big proponent of doing this all in CSS Typed OM space 17:35:12 TabAtkins: after more thought and seeing this proposal 17:35:29 TabAtkins: I am convinced that, while we have some open issues that I think those are solvable 17:35:36 TabAtkins: I think this would present a substantially more usable API to people 17:35:42 TabAtkins: than trying to do it all within TypedOM 17:36:02 TabAtkins: And as Lea said, means don't have to contort TypedOM to fit use cases 17:36:14 TabAtkins: I've done a bunch of work with color, would have loved to have an API like this 17:36:29 Rossen_: One question, does this render CSS Color Value out of the conversation? 17:36:33 Lea's slides: https://lists.w3.org/Archives/Public/www-archive/2021Jul/att-0004/Towards_a_Color_API_for_the_Web_Platform.pdf 17:36:38 TabAtkins: We still need to represent color values in CSS via TypedOM 17:36:48 TabAtkins: there's just less pressure to do convenience methods in TypedOM 17:37:10 TabAtkins: Some things like converting between functions might still do, but don't have to worry about extensibility to author color spaces. Can leave that to Color API 17:37:19 ack florian 17:37:24 florian: To me the motivation for this makes complete sense 17:37:31 florian: but if have both, will they step on each others toes? 17:37:47 q+ 17:37:53 florian: There's other parts of platform also that consume colors, and we'll need to define what kind of colors they consume. Will it be one kind, both? Do we need conversion functions? 17:38:13 florian: If every API consumes both and have conversion functiosn.. should one be a library of the other? 17:38:29 TabAtkins: What is the preferred shape for color-consuming functions is a key question 17:38:49 TabAtkins: wrt conversions, already define how to create one from the other 17:38:58 TabAtkins: but whether we end up preferring one for APIs like eydropper or whatever 17:39:07 TabAtkins: or say that APIs should handle both, is something need to still answer 17:39:12 TabAtkins: make sure TAG is aware of this question 17:39:24 s/for ???/for non colormanaged APIs/ 17:39:29 TabAtkins: If we only do one, I suspect color api is the one we want to do 17:39:34 TabAtkins: but might want to accept both 17:39:49 chris: Also point out that while we think of CSS as main consumer, there's also Canvas 17:39:57 chris: which has some color spaces not in CSS 17:40:06 q? 17:40:10 lea: Also .... 17:40:24 lea: You can't always derive specific numbers for a CSS color, e.g. can have a calc() expression 17:40:38 florian: Can it be resolved down to a single value? 17:40:38 sRGB-linear and rec2020-linear are the two I am thinking of here 17:40:48 lea: What if you have a number that's viewport units divided by pixels? 17:41:00 TabAtkins: and if you use 'em' it's element-specific context 17:41:10 florian: So you'd need to throw if try to convert and it needs a context but doesn't have one 17:41:27 q? 17:41:29 q+ 17:41:38 q? 17:41:41 Zakim has joined #css 17:42:18 plinss: Wrt API used in other places in the platform, don't have to solve here, can take to TAG 17:42:27 plinss: My take is any input probably fine, but output must be Color API 17:42:36 plinss: I'm glad to see both these APIs being developed 17:42:51 plinss: What I really want is one object that really focuses on doing color right, and one object that does CSS right 17:42:55 plinss: overlap, later 17:43:10 plinss: I'm fine with one set of classes if it would be good fit for both uses, but I don't think this is the case 17:43:13 plinss: ... 17:43:19 plinss: color object should be underlying object for doing the work 17:43:47 ack smfr 17:43:54 my audio is broken 17:43:56 will type 17:44:19 first comment: 17:44:20 yes 17:44:22 can hear 17:44:34 1. should color objects be immutable? 17:44:49 must less ambiguity about what happens when live color obejcts change 17:44:57 maybe design the api initially with immutable colors 17:45:11 mutability brings lots of complexity 17:45:23 TabAtkins: what do you mean? 17:45:35 i will try to call back in 17:45:35 lea: you get a reference to a color object, use it, and someone else changes it, what happens 17:45:48 ??: might be useful actually 17:45:51 ???: does it animate or what? 17:46:08 (lost the link) 17:46:23 pal: meta question, a lot of this stuff sounds cool and fun, but I'd like to better undertand the target applications and users 17:46:27 pal: otherwise black hole 17:46:47 chris: ... 17:47:11 chris: Risk is we get shipping subsets that are useful only for this or that which is shipping 17:47:27 pal: Question of mutable vs immutable, how can we answer the question without understanding the use cases? 17:47:39 Rossen__: So question is, is this behind the Color API itself or CSS Color 17:47:46 Rossen__: I think we have a pretty good answer 17:47:53 Rossen__: once this is answered then we can go after your question 17:48:23 rossen, please suggest a resolution because as you said we are close 17:48:28 smfr: If color objects are long-lived and assign them to different things [cut] 17:49:13 TabAtkins: API that bends a color, or ... hold a reference to that color 17:49:21 TabAtkins: automatically changes the color used 17:49:29 TabAtkins: we very specifically didn't do that for TypedOM 17:49:35 TabAtkins: and I expect we would conclude the same here 17:50:27 s/bends/vends/ 17:50:36 [smfr continues to have audio problems; fantasai suggests dialing in by phone, possibly using the dial-in code in the video app audio options menu] 17:51:06 Rossen__: What I'm hearing is the Color object in the way that was proposed by Lea and Chris in that spec and explainer is the preferred path forward 17:51:17 Rossen__: Anyone objecting to that path forward? 17:51:38 florian: is the use case question about should we have this at all or about design? 17:51:49 Rossen__: ok let's take that resolution 17:52:09 RESOLVED: Add Color API for representing color points, separate from CSSColorValue to represent CSS color values 17:52:36 Rossen__: Next question is do we actually need this 17:52:55 pal: That's not my question. My question is who are the users? what are the use cases being targetted? 17:53:11 florian: Do you question that there are any? or that if we don't understand the users, we can't do it right? 17:53:15 pal: The latter 17:53:20 pal: There's many color spaces 17:53:24 pal: there's a complete zoo of this stuff 17:53:31 pal: NxN issue 17:53:34 chris: No, it's not 17:53:45 pal: to convert from any space to any other space 17:53:53 TabAtkins: That's what the interconnect space is for 17:53:59 pal: [gives some complicated example] 17:54:06 pal: How can you go through a connecter space? 17:54:07 q+ 17:54:18 pal: Lke REC709 are defined from camera, so optical to electrical transfer function 17:54:21 pal: but inverse is not defined 17:54:25 pal: depends on context 17:54:27 pal: not just only math 17:54:33 pal: all I'm asking is what are the use cases? 17:54:38 pal: what are we trying to do? 17:55:00 Rossen__: one obvious use case is to ahve an actual object so we don't pass strings which are typeless and lose meaning from one object to the other 17:55:05 image referred vs scene referred is what Pierre is refering to here, I think 17:55:09 Rossen__: I hope we all agree that this is neede for user point of view and perf 17:55:11 pal: no question there 17:55:20 There are some taks at the Color workshop about this by the way 17:55:29 Rossen__: whether or not this object needs to cover all possible color spaces and their interaction, I think this is more of your line of questioning 17:55:38 pal: wrt string vs object, definitely want an object 17:55:42 pal: I think that sounds like a great idea 17:55:43 s/taks/talks/ 17:56:03 Rossen__: so remaining question is, do we have enough use cases that support having color spaces as an API functionality, what are these color spaces, where do we star/tend 17:56:06 pal: you define the object 17:56:13 pal: question is, do you define reference transformation 17:56:19 pal: assume this object has a color space and coords 17:56:34 pal: should the web platform define reference transforms between istances of this class associated with various color spaces, and what are they 17:56:44 pal: until we've answered what use cases we're targetting will be hard to answer that question 17:56:50 pal: easy to go crazy 17:56:56 chris: that's why we made this library 17:57:05 chris: if just talking about color metric conversion, can have singel transform 17:57:12 chris: as soon as ... e.g. hdr to sgr, then ... 17:57:27 pal: I don't agree, in case of 709 there's not a singe inverse transfer function used today 17:57:31 q+ 17:57:38 pal: so web could decide to just pick one. And actually that might really help the world. 17:57:43 pal: but not something to do lightly 17:57:48 pal: really need to understand retargetting 17:57:53 lea: it's OK to restrict the scope at first 17:58:01 lea: maybe we decide that some color spaces are out of scope for L1 17:58:19 lea: some are already out of scope for current design, e.g. index colors 17:58:24 pal: I really like the suggestion 17:58:31 pal: maybe for first pass, just replicate everything in srgb 17:58:39 pal: make sure everything works there 17:58:47 TabAtkins: CSS is already past SRGB, so already need more 17:58:50 pal: ok, then pick that 17:59:02 pal: If we all agree to moving from string to object, then validate that and grow from there 17:59:07 florian: need object we can do something with 17:59:28 https://www.w3.org/Graphics/Color/Workshop/talks.html 17:59:42 chris: In few seconds remaininng, questions pal raised, many were covered in the color workshop ^ 17:59:49 Rossen__: proposed path forward of scoping what we can do here 17:59:57 s/were/will be/ 18:00:02 Rossen__: scoping to CSS is valid path forward, start from there 18:00:06 q- 18:00:06 Rossen__: where is this work going to happen? 18:00:08 out of time 18:00:18 chris: currently in private repo... 18:00:31 q+ 18:00:36 Rossen__: ok, open in WICG 18:00:53 q- 18:01:26 ack pal 18:01:26 It sounds like the hard part of Pierre's question is around more exotic spaces anyway, which are *not* going to be supported as built-ins; they could just be added as author-defined ones, where these choices presumably can be made by the author, right? 18:01:29 pal: I think if the goal is to include video and image applications 18:01:36 pal: WICG isn't the right place, won't get the right people 18:01:43 pal: any color cg or whatever would be good 18:01:49 lea: what about a task force? 18:01:57 q? 18:02:10 TabAtkins: Point of WICG is to gather the people you need before you choose a venue 18:02:15 pal: But WICG is way too high bandwidth 18:02:28 TabAtkins: you don't subscribe to everything, you subscribe to the specific repo 18:02:39 lea: We don't need all video people, just a few 18:02:53 pal: Happy to point ppl to the repo, but they'll also want to discuss it 18:03:07 pal: some issues best discussed live 18:03:07 color cg had a lot of good discussion on related topics already 18:03:19 florian: Point of WICG is to be a place for "I haven't created a group yet" 18:03:21 q? 18:03:35 chris: ... already has the right people 18:03:38 chris: but can't do spec work 18:03:50 Rossen__: so let's pursue WICG and if it doesn't work, can transition out of there 18:04:24 fantasai: Seems like we wanna start with at least covering all the CSS and canvas color spaces 18:04:28 fantasai: So we can resolve on that at least 18:04:36 fantasai: Even without drafting up a more extensive use-cases doc 18:04:52 fantasai: and then maybe chris, lea, pierre can draft up the explanation of use-cases that pierre is looking for 18:05:12 Rossen_: Perfect, TAG loves to see use-cases right at front 18:05:17 fantasai: So take a resolution? 18:05:24 Rossen_: objections? 18:05:39 RESOLVED: Color API should handle all the color spaces currently specced for the web platform. 18:06:01 fantasai: On process, when do you spin out of WICG? 18:06:12 Rossen_: when we have impl interest 18:06:25 fantasai: We often have the case that things spin up in WICG and never spin out 18:07:01 florian: Implementer isn't strictly required, just need a community that is happy to charter the work, however you manage to get that 18:07:40 s/that/that. Implementer interest certainly helps with that, but it's not a formal condition/ 18:13:59 Topic: end 18:14:51 lea or chris: don't forgot to print the slides to PDF and send to www-archive, then comment the link in issue 1047 18:21:47 TabAtkins, already done during the call and link posted in irc 18:59:48 dholbert has joined #css 18:59:55 dholbert has joined #css 19:53:01 jensimmons has joined #css 20:08:55 hours late with this one: https://w3cmemes.tumblr.com/post/144307853757/meanwhile-in-the-houdini-task-force 20:09:43 Rossen_ has joined #css 20:09:51 Zakim, end meeting 20:09:51 As of this point the attendees have been (no one) 20:09:52 RRSAgent, please draft minutes v2 20:09:52 I have made the request to generate https://www.w3.org/2021/07/21-css-minutes.html Zakim 20:09:56 I am happy to have been of service, Rossen_; please remember to excuse RRSAgent. Goodbye 20:10:00 Zakim has left #css 20:16:39 Really wish we'd stop trying to sell the meme of "lol specs go to WICG to die" when we've got a ton of successful specs out of WICG. It's annoying and wrong.