IRC log of css on 2021-07-21

Timestamps are in UTC.

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