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.