Meeting minutes
Masonry
[css-grid-3] Drop `masonry-auto-flow: definite-first`?
TabAtkins: the spec doesn't currently define the masonry auto flow ? value
TabAtkins: can be inferred what it means
TabAtkins: distinction between items in a definite track versus items purely auto placed. That value means that anything you place indefinite will go first and then all auto-placed ones below it.
TabAtkins: I think it's a bad behavior.
TabAtkins: intended to match with grid 's behavior but it doesn't.
TabAtkins: what grid does is it breaks items into 4 categories.
TabAtkins: things with definite row + column, a definite row (any column), a definite column (any row), and fully auto placed
TabAtkins: it handles these in order of strictness
TabAtkins: in order to minimize chance of overflow
TabAtkins: so first it places things that are fully definite (row + column)
TabAtkins: next it places anything with a definite row, since if the row gets filled up it will overflow the row
TabAtkins: finally it flows column placed things and auto-placed things together as one category in order
TabAtkins: this is because column-placed things, worst case, they get shifted to the next row, so almost as flexible as auto-placed
TabAtkins: masonry stuff is all the final two categories
TabAtkins: so I think the default behavior is to match grid and flow them all together
TabAtkins: I think there's no actual use case for definite first.
TabAtkins: if you want things first, use the order property.
<fantasai> dbaron: I think it makes sense
fantasai: any objections to dropping the definite-first value of masonry-auto-flow
RESOLUTION: drop the definite-first value of masonry-auto-flow
[css-grid-3][masonry] Make auto-fit do things
fantasai: tab pointed out that the auto-fit value in masonry specs is designed to behave the same as auto-fill
fantasai: auto-fill will fit as many columns as fit in the containing block and leave that there
fantasai: auto-fit will do that, but then collapse any columns that are free after placement
fantasai: so we could do similar in masonry, but if we're doing auto sized columns it might not be as exciting
fantasai: but we can redistribute the space if you have a fixed # of columns or an auto # of colums that ...
fantasai: so we can still do things like collapse the empty columns in masonry
fantasai: so if you have fewer items than columns or explicitly placed columns then you can end up with empty tracks
florian: any reason not to?
fantasai: I can't think of any reason not to.
TabAtkins: a potential reason: if you move the columns around and potentially change size or gap between them (have spanners), this changes the size of things in the columns because they now have more space to flow into, which could make things shorter and could theoretically change column placement
TabAtkins: so your final masonry might end up more ragged than it would otherwise have been
TabAtkins: but that's largely a non-issue because your masonry is nearly empty
florian: but if you didn't want that, use the other keyword that doesn't do that
fantasai: also you can do this after track sizing
fantasai: size tracks, place items, figure out what's empty, don't resize the tracks afterwards
fantasai: doesn't reduce space into the tracks (like grid), but lets you redistribute spcae using alignment properties
fantasai: that track won't get empty, but increased gap size will increase available space to spanning item
florian: either way we're discussing whether it does the same as auto-fill, so if you don't want the rejiggering, use auto-fill
fantasai: further comments?
oriol: a question: if you use the align properties like align-content and set them to stretch, and then we can't stretch the tracks, does stretch not work on masonry?
oriol: is it just in this case where you're collapsing tracks... or in general?
fantasai: probably need to apply the distribution before placements -- size the tracks, apply alignment, then place items.
fantasai: if you want to do this drop tracks and then reapply values... wouldn't apply stretch because we don't want to resize the tracks
oriol: then if the values stretch, you have start alignment? fall back to other alignment?
fantasai: I think you get start.
fantasai: I think you have the same problem in grid if you don't have any auto tracks and you say stretch.
fantasai: we might want to give stretch a fallback alignment option.
fantasai: should we do it? I see Rachel nodding.
RESOLUTION: Make auto-fit drop tracks after sizing and placement, and apply content distribution to the tracks again afterward
Proposal: CSS Gap Decorations Level 1
kbabbitt: gap decorations in layouts like grid is something authors have been asking for.
kbabbitt: discussed in some other issues... this proposal takes some inspiration from previous discussions
kbabbitt: this adds row-rule-* to complement column-rule-* and makes them apply to grid and masonry
kbabbitt: this adds a new idea of varying gap decorations
kbabbitt: ??
kbabbitt: this example is a calendar grid with varying light and dark decorations.
<TabAtkins> alternating light and *very light* rules
kbabbitt: this is a calendar grid set up with alternating heavier and lighter rules for hours of the day and days of the week
kbabbitt: this specifies area where they apply and patterns for drawing
kbabbitt: plenty of use cases work without this, so could be pushed to a later version
kbabbitt: basic part here is row-rule-{width,style,color} and applying row-rule-* and column-rule-* to grid
fantasai: how does it address the last part, where there's no rule where there's no cells?
kbabbitt: the basic model that I have for where the decorations from the stem of the T to the next intersection
rachelandrew: same as multicol, don't draw the rules where there's no content
TabAtkins: strongly approve overall. Having control over rules is important for grid, useful for flexbox, useful for masonry. I agree with deferring rule images until some later time. They are mildly complicate in multicol, incredibly complicated in a 2D grid. Can't appreciate thus until you try to design it. Put that far in the future!
<rachelandrew> +1 on deferring rule images
TabAtkins: I like ideas here about areas. Captures functionality you can get tables, we don't have the hierarchy of elements in grid, good to be able to reproduce that.
TabAtkins: I don't like use of slashes mixed with commas more than we usually like. We can do that later, such as with a wrapping function.
TabAtkins: overall looks really good, don't have a strong opinion on what should be deferred versus MVP for level 1. Fine with simplest possible, but could see how much to get into a level 1.
TabAtkins: some other things mentioned in thread was about controlling length of rules so they don't fill entire row/column.
TabAtkins: model here does make that a little more complicated... might need some thought.
TabAtkins: but I'm happy to deal that in the future.
TabAtkins: maybe that means we should simplify to bare minimum in L1 to keep our options open for later.
kbabbitt: One comment about use of slashes: in this example, using slashes in the context of a shorthand. Not opposed to functional notation.
TabAtkins: you have to save commas for matching up with row rule areas.
TabAtkins: we try to avoid 2 levels of demarcation because it's hard to read. We can figure that out in the issues.
una: generally think it's a good idea. Some questions:
una: regarding which line item is on tap -- is it the horizontal or vertical? is it consistent? is there author control?
una: you mentioned no images -- agree it adds a lot of complexity. What about gradients? Could be effective.
una: my first thought was that given lack of intersection control, maybe want blend modes or filters to control how they intersect. Or can authors use blend modes etc. for gap decorators? Or is that a v2 thing?
kbabbitt: re paint order, there's a property for that, just to choose row or column on top. Could explore more flexibility later.
kbabbitt: for gradients and mix blend modes I'd think of that as something to explore later. Probably some complexity.
kbabbitt: for blend modes in particular, re how decorations interct when they meet at an intersection.
iank_: then also, gradients are images (at the spec level, no diference)
kbabbitt: I'm also still collecting use cases, please post examples to the issue.
<TabAtkins> Gradients *can* be 1-d (see border-stripe) but that still requires the rendering model to have a well-defined and understandable notion of "length"
rachelandrew: generally a fan of this. Something we know people asking for.
rachelandrew: I'm interested in the area syntax, i ithink it solves quite a few use cases, people asking for multicol pseudo-elements for grid. I think this would help with some of those.
rachelandrew: you perhaps saw my comments on ?'s original proposal... were hoping to do multicol overflow in th eblock direction which gives us ? rows. (??)
florian: I think it's a well thought out propsoal. A lot of complexity, but a lot of details. We can fiddle with the details a lot. I like it. Should turn it into a spec. Not sure if we want to spec more than the minimal set and then trip, or just spec minimal set.
florian: you mention orthogonal direction doesn't apply to multicol around spanners and things, and I agree with that choice.... we might later extend multicol to multiple rows of multiple columns, and that's where they should apply
florian: But I like it.
kbabbitt: for spanners in particular there are probably multiple solutions that work, such as putting borders on the spanning element
kbabbitt: i want to reserve ???
<Zakim> emilio, you wanted to ask how does this interact with gap? Presumably the effective gap would be max(rule-width, gap)?
kbabbitt: One reason I explored designing subareas was to make sure syntax could be extended, but I think I am leaning towards deferring it.
emilio: does do the row length and the gap length interact? Like in columns?
emilio: if you have a rule length that is bigger than the gap between the items, does that expand the gap or do something else?
<rachelandrew> made the same comment re multicol, rows, and spanners in the proposal from Mats w3c/
kbabbitt: gap decorations do not affect layout at all -- they're a paint-only effect. They'd paint behind the items like gap decorations in multicol.
kbabbitt: This is because for some of the subarea definitions, want to be able ot define an area to cover rows and columns generated implicitly as part of layout. So has to come after we figure out the size of the grid.
iank_: +1 to starting small. We'd have had to integrate with the column-rule* properties anyway.
iank_: you mentioned images explicitly left out because they're super complicated. Anything else left out initially?
kbabbitt: The other thing was application to tables.
kbabbitt: The underlying spec is still marked as not ready for implementation, probably still some compat differences.
kbabbitt: and existing table borders solve many scenarious
iank_: existing table model is different, and gap property doesn't apply there. So makes sense.
<Zakim> lea, you wanted to say I'd rather keep L1 as small as possible (possibly just `row-rule` that is identical to the existing `column-rule` and leave the bells and whistles for later, once we have experience of what authors do
lea: Just +1 to keeping level 1 super simpler -- get row-role-* as well and maybe a shorthand for both, and see what authors do before adding more.
fantasai: I was on the queue to disagree with that -- I think the spanning and 2D nature of grid raises a lot of issues not present with multicol. If we don't know how we're going to solve those, we'll likely get ourselves into a bit of a mess as we try to expand to handle those cases properly. I think it's great that this deals with all of those scenarios. I think the first spec draft should continue to do that so we have an idea
fantasai: ...how it all fits together. If some properties marked as at risk or not ready, that's fine.
fantasai: I like that this is handling the gaps. I think the part about grid area stuff I'm a little less sure.
<florian> +1 to fantasai on spec broadly and then trim / at-risk / defer the more advanced parts rather than spec narrowly
<lea> +1 to discussing these issues, my point was about reducing initial implementation burden, the design work should definitely happen
fantasai: your initial value says "1 1 -1 -1" to cover the whole grid -- but that only covers the explicit grid. One of the challenges with grid is that there's no way to address the last line including the implicit grid.
fantasai: Overall looks pretty good, probably some syntax we want to tweak. Glad you through through the intersections carefully.
<Zakim> fantasai, you wanted to say we need to sketch the whole thing
emeyer: haven't read this in detail... but doesn't seem to be a way to select a specific track?
emeyer: let's say I have a week calendar, and I want a rule next to Sunday and Saturday. From what I can see I'd have to do column-rule-color: black transparent transparent ... transparent black.
kbabbitt: Other way to do that is this syntax with grid-row-rule-area specifying 2 areas.
kbabbitt: works like transitions or animations where the area definitions are the controlling properties and the other properties line up.
TabAtkins: quick question: if you want to avoid drawing underneath a large spanning item? Handled by setting up another grid rule area and saying no rules in that area?
kbabbitt: A copule ways to do it. That's one. Also a way to stop short of intersections -- column-rule-outset. Default to running the line through, but can adjust.
TabAtkins: That would work OK if the item was opaque, but if it wasn't you'd need to suppress painting under it.
TabAtkins: one other question: What's the conflict resolution mechanism when 2 areas specify the same gap edge?
kbabbitt: not written yet, but I think your comment said last wins, and I think I agree.
fantasai: meaning in a comma separated list of areas the last one wins?
<iank_> (I think in the default case you likely want to draw behind, e.g. for interactive grids, i.e. a calendar, opacity triggers upon drag, which you want to see the stuff behind for that particular interaction)
fantasai: might want to consider first wins to match font-family and backgrounds?
kbabbitt: I was thinking of painting order.
TabAtkins: conflicting precedence in other properties, e.g., last animation wins.
fantasai: Any objcetions to starting an editor's draft for this feature?
fantasai: I suggest calling it grid gaps and rules level 2... pull in the gap property.
florian: gaps don't only apply to grid
fantasai: oops, CSS Gaps and Rules
TabAtkins: I don't like starting modules with a new name and numbers greater than 1.
fantasai: Want me to publish a gap level 1 that only has gap?
TabAtkins: I won't stop you from busywork to justify incrementing a number...
fantasai: shortname? css-gaps? ...
kbabbitt: I called it gap-decorations
una: calling it just gaps is about styling the size of the gaps
fantasai: I'm proposing pulling that into the same module
<TabAtkins> css-rules is no good (too many synonyms) so just css-gaps
florian: Calling it gaps alone might make sense when we eventually put in images.
<TabAtkins> css-gaps-and-the-things-that-go-in-them
dbaron: singular or plural?
fantasai: I think plural
fantasai: proposed resolution: import the draft with shortname css-gaps and title CSS Gap Decorations with kbabbitt as editor.
kbabbitt: I don't want people to misinterpret is a document with the shortcomings of CSS!
kbabbitt: what I'm hearing in terms of content is definitely row and rule lines, but areas might get pulled into later level.
fantasai: I think spec what you've got and then decide what to defer.
fantasai: And it starts as an editor's draft, ask for FPWD when you think you're ready. (Doesn't have to be perfect.)
fantasai: as long as it's mostly complete in terms of functionality
RESOLUTION: import the draft with shortname css-gaps and title CSS Gap Decorations with kbabbitt as editor.
CSS Color
[css-properties-and-values-api] Resolved value of registered <color> custom properties.
<jarhar> emilio: i recently noticed that what computed style returns for some properties is inconsistent. for most places it seems like tests expected the computed and not resolved color as any other color would.
emilio: but then ? expects some legacy rgb color result. i think we should decide on one. all engiens are exposing the computed and not resolve dcolor so if they did currentcolor and so on i think its fine to be doing that but i think it would be good to clarify that
<TabAtkins> +1 from me
ChrisL: i agree that they should do that. i see that mozilla made changes to wpt so that either is accepted as a pass. this is not a good situation. i think we should have a form that presserves currentcolor it means you get the right color instead of hard coding the color. i dont see why legacy rgb was accepted and why currentcolor should be
resolved so eagerly
emilio: this coudl be due to some animation implementation in webkit or blink but im not sure if blink and webkit actually interpolate including currentcolor like firefox does. if you interpolate curretncolora s asomething else then firefox will get the right behavior and im not sure if the others can do that but i think thats a bug in webkit
ChrisL: it would be good to get feedback from those implementors, firefox has donet he right thing while theres a spec ambiguity but id liek to hear if theres an objection to making the value be the one that includes currentcolor with color mix. i think thats the best one currently
<ChrisL> So color-mix(in srgb, currentcolor, rgb(200, 200, 200)) for example
futhark: i can speak for blink. internally we should be using currentcolor inherit currentcolor. any other - if there are behaviors that are differnet that can be considered bugs. in computedstyle we always return the result color which is the used color that does not include currentcolor. our goal is to return currentcolor in the ?om api but we
currently dont do that but thats something we want to change
lea: chris you mnetnioedn that if we dont resolve currentcolor then that can be inerhited. is that the intent? i have come across cases where authors are registering custom properties as colors and then expecting it to resolve and inherit the textcolor of that element down to descendant rather than resolinv currentcolor the same was as you can
register a length asnd then set 1em as that and ?? expect it to resolve as colors
emilio: and that works the same anywhere
lea: there shouldnt be any special behavior for color mix ai agree
emilio: my understanding is that lbink actualy does return correct color from getcomputedstyle for these properties already. its just with animations where you dont
emilio: so if you look at the first link in the issue, the test does pass in blink and yeah it expects the getcomputedstyle value to not resolve, which is inconsistent with other color properties
futhark: i dont think thats intentional, or maybe it is when you do the interpolation im not sure if thats intentiona.,
emilio: i agree its weird which is why we should - im fine saying that we should always resolve them. i think we resolve them mostly for compat
futhark: i was looking at the spec and the cssom spec limits using the resolved value for certain colors but ? currentcolor not listed in the cssom spec. it would make sense for all colros to resolve for getcomputedstyle api and also be consistent with custom properties to do the same thing. that sounds like a consistent way for me. and then the
typedom return the current color version
<emilio> sgtm
fantasai: i believe we have a proposed resolution which is that getcomputedstyle returns a resolved color including custom registered properties
futhark: yes
ChrisL: but then its different in typedom? lets capture that
florian: so its not the used value and its not the computed value?
futhark: the cssom spec says that its the used value i think
florian: i think resolved is defined to be either the comptued or used depending onwhat it is
florian: the current proposed resolution is circular
fantasai: please type in a proposed resolution
kbabbitt: im going to take a swing at rephrasing to say that the resolve dvalue fo ra registered custom proeprty of type color is the used value to be consistent with the used value of typed color on a non custom proeprty
fantasai: go further and include non standard properties
kbabbitt: that makes sense. and then in typedom we return the current value
<Zakim> kbabbitt, you wanted to rephrase the resolution
RESOLUTION: <color> values returned by getComputedStyle() on standard CSS properties or registered custom properties is the used value
ChrisL: values in list of properties needs to be removed or ? or whatever. was it just removing that list?
RESOLUTION: computed <color> values returned by TypedOM are the actual computed value
emilio: my other question is how would this animated value serialize. should it serialize with legacy rgb or the color function, but i guess this is somewhat - we could move this to a separate issue maybe
<ChrisL> It is related to w3c/
[css-color-adjust] Allow authors do define custom `color-scheme` values.
<TabAtkins> w3c/
TabAtkins: bramus had a proposal for allooiwng authors to write their own color schemes. theres a reason to want a parrticular set of colors. after back and forth we came to a particular shape to proposal at this comment. the core use cases are a. built in stuff uses system colors all over the plate. if you wanted all them to be sconsistent with
your set of colors you have to override builtins until we add more controls. if you missed any ? the second use case is the web prefere3nces api proposal lets you persist certain site preferences and persists across page loads. if that happens then you could save the color scheme for a site and then make it apply the next time you visist the siste.
the proposal is a new color scheme at rule you give a name and a color scheme and then you can override any of the system colors for that color scheme
TabAtkins: anything you dont override ?? add more, that gets taken from the base scheme.
TabAtkins: this dash ident is usable in the colro scheme, that will switch all the system colros for light and dark and it will let you respond to it - schemed color something like that. if we are in light or in dark or --solarized used this third color, if and when the web preferences api that could be persisted over there without having the
possibility of flash of unstyled content
TabAtkins: that is the proposal. any thoughts?
<ChrisL> This function computes to the computed value of the first color, if the used color scheme is light or unknown, or to the computed value of the second color, if the used color scheme is dark.
<Zakim> ChrisL, you wanted to ask how light-dark works when a custom scheme is in effect
ChrisL: i have a question about this. we accept that means the light dark thing will evaluate to light because it matches light or unkonw. unless its marked as dark we treat it as light. i just wanted to make sure were ok with that
TabAtkins: im not sure i understand
ChrisL: in color 5 we have light-dark and it says that if it matches light or is uknown wthen you get light, otherwise you get dark. custom color schemes will come out as light
TabAtkins: it will be a known keyword that will respond appropriately
ChrisL: ok then how do you determine if its light or dark?
TabAtkins: ah right because it has simple syntax of two values
TabAtkins: at the moment the only two builtin ones are light dark so it should act like whatever its base scheme is. if youre building a sheme based on dark then i tshould respond with dark. we should also have a new syntax with more schemes
ChrisL: so we need to do some work on light dark once we have this
TabAtkins: yes
alisonmaher: i have a question on how this will interact with forced colors. today it overrides light and dark themes, but it looks like authors might specify their own. so i wonder if we will still have forced colors oerride other schemes or ??
TabAtkins: i expect we shouldnt change that, if authors want to return an alternate scheme thats interesting
TabAtkins: by default i think we should just be - default color schemes are jus tlike like and dark, forced colors will override everything becuase user preference should override author preference
alisonmaher: sounds good
<Zakim> alisonmaher, you wanted to ask how this interacts with forced colors mode
<Zakim> fantasai, you wanted to ask about interaction with UI such as scrollbars and form controls
fantasai: hows this expected to interact with ui pieces such as scrollbars and form controls
TabAtkins: to the extent that they draw from system colors they will use what you specify. if they are painted with unknown colors it wont be affected by those
TabAtkins: if you wantt hem to be more controlable we should be - that should be based onsystem colors or add more system colors. we cant give all the colors and things change over time
TabAtkins: i iimagine that to the extent that we dont have control over them, they should act in the base scheme like light or dark but that should get better as we go along do piecemeal
kizu: i wanted to ask about color scheme its not a media query you cant change it from author styles themselves. ??? decided to to html, it will stil match the color scheme that was defined outside the document. there is a way with custom properties and light dark to detect light or dark color because you can assign light dark to a custom proeprty
and then in a query check this value, but it will only work for light and dark function. so we will need either a container query which reflects the propsoed colors sheme or have some other conditional way of checking what is the color because we cant change the first color scheme because its a media query
TabAtkins: that should be handled by web preferences api. if you use the js api, we can expose that to to the document because its document level, no circularity involved
TabAtkins: we were designing light dark we knew we wanted to address mroe schemes in the future but we only have two, so for that the work we did on light dark for allowing morecolor schemes ???
kizu: i also need to think about the html meta color scheme, can you define more than two there if you want to ?
TabAtkins: yeah but color scheme meta should be defined by css parsing, we should accept the same set of values that color scheme does. to the extent that might need tweaking to keep up with css behavior we can make sure that is happening. it is either well defined now or close to work consistently with css
lea: so first i think its important use case to define something for color schemes. i dont think we should do it adhoc, theres alot fo existing work with design systems that is realted and we only get one chance to do it right. also i think that so if we want to go the route of redefining system colors we should have a systematic attempt to define
??? color scheme otherwise it is too little too late. using light and dark to ??? ancestry seems very weird. its a workaround but ideally we need a conditional which makes that clear
TabAtkins: design token stuff, the general case of wanting to do mroe complex things of wanting to set up sets of colors it soutside the scope of this because you can already do this with variables, if you want to do more useful stuff that ultimatesly lives in the same space as variables, you can already do it.
TabAtkins: what you cant do is custom usage of builtin colors and you want to override and do it in a fairly safe way because as we add new colros int he browser ui it should still look reasonable. if a newly added form control is added it should be ok
TabAtkins: thats why this uses the systme color approach instead of appropriately designed tokens, ??? undoable at the moment. regarding needing a large set of system colors, i agree but that doesn't stop us from doing it with colors right now. ??? so taht you build on a predefined color scheme ?? gradually extend this in the future, still get
moderately ok things, exspecially if close to a dark or light scheme. if youre in the middle we need another predefined scheme but thats the best we can do at the moment
TabAtkins: we only have light and dark predefined things, you can do things in the middle, neither is great, if we define midtone stuff so theres an idea of predefined colors if you didnt define them, were working with the tools we got
lea: i like this, but when it comes to light dark but what im saying is picking colors is orthogonal to light or dark, seems orthoganal. maybe this could fit into other use cases for positionals we are discussing tomrorow
TabAtkins: we thought about scheme color but did light dark because its common case and not ideal for other schemes but not the end of the world, stand by our conclusion from design process, its awk but we can put other schemes besides light or dark in there
fantasai: id liek to go back to the use cases for this. so generaly what it does is it changes a bunch of variables you coudl use in your design to a new set of different things and thats it?
fantasai: right it changes system colors which are color variables. if your design is using system colrs then it changes. if your design is using other things then nothing changes
fantasai: so what is the benefit of this over variables?
fantasai: so your intention i snot to define the custom color scheme but to influence the ui elements?
TabAtkins: yeah beause thats what you can do today
fantasai: ok that wasnt clear but thats what youre doing?
TabAtkins: thats very clear in the op, smaller version in comment
fantasai: ok so now the question is can - is it possible to do that cross all platforms?
TabAtkins: yeah? the system colors are all under browser control, but whether the yswstem colros are used in a set of ui controls is a different matter
TabAtkins: this isnt setting anything on how browsers use system colors but they do tend to use their system colors to a large extent. theyre still pretty decently used across things. if not then theyre probably not controllable at all like glossy buttons from previous macos versions
fantasai: so youre expecting that this will chagne the way scrollbars etc change in some platforms but not others?
TabAtkins: to the extent that itis today
TabAtkins: if there are thing sthat are uncontrollable then yes but there are a bunch of proeprties set and colros set with system colors, if you have knowledge of how colors are set you can manually override that but if you add new ones then they cant be styles and we should make that case safer
fantasai: so most people override ? except for form controls ? except for html stylesheet
TabAtkins: i think we do use them for borders on inputs etc backgrounds on various things
<Zakim> florian, you wanted to react to lea
florian: so you dont so much mean influence the native rendering of form controls, rather their css version which you could as you said override by redefining the proeprties but you dkont know how theyre built but theorietically its doable in css but authors dont necessarily know how, right?
TabAtkins: this is allowed - browsers to do more specialized rendering based ont heir colors in a similar way to accent-color. its lightly specified but that still gives you theming capability that is a meaningful input to hbow pages work
emilio: in that topic, for example we do have some non exposed to web content system colors for things like ? options in active windows or select and button having different backgrounds. seems like this proposal allows you to address them with standard styles for form controls almost feels like not very useful
TabAtkins: as we decide there are gaps in system colors that will be useful to expose for authors we should and will expand that, generally the system color set more useful
<kizu> w3c/
kizu: i just wanted to mention that - i pasted it into irc
kizu: issue about giving access to accent color we have inconsistency where we have the accentcolor variable or keyword which doesnt match wich accent-color when you set it and maybe we want to approach for this as well, you can define accent color but can be overridden by accent-color property
TabAtkins: the accent color exposure issue is about exposing the - not about the ability to contorl the accent color - when you set it you cant access it back any way, stored but then you dont have a way to get it, lea made this issue
^ kizu not tab
TabAtkins: thats just a usability issue not security issue
<fantasai> s/TabAtkins: issue/kizu: issue/
lea: less power to custom styling than native form controls which actually use the system accent color
fantasai: any other comments on this proposal? tab what are you looking for
TabAtkins: if theres n oobjections then id like to include this as part of color adjust 2. i dont believe we have any impelemntor support yet so we can iterate on this for a while but i just wanted to get the ball rolling if it sounds ok with people
fantasai: i need to check with webkit people
fantasai: it would be helpful if it said instead of changing the system color keywords that it is to influence the styling of all sorts of stuff that is the main use case youre thinking of
<TabAtkins> w3c/
TabAtkins: heres the post where i ? about the use cases, the original post is about heres a set of variables, but you can already use variables
TabAtkins: we had a couple useful techincal questions which have obvious answers but could be written down in a proposal so they dont get asked again
fantasai: how about you create an explainer with the proposal and the description you have of the use case is that it only changes the system colors keywords then its just a pile of variables which is not a huge benefit
fantasai: so why are we building this into the browser is the question you need to answer
TabAtkins: ill come back in abit with a more detailed one. so it sounds like no large objections just use cases?
fantasai: if this can all be done with variables then theres no use for this
TabAtkins: theres more to this that makes it more compelling
<TabAtkins> +1 to lea's point
lea: before we switch topics, as a general principle authors can do it with variables i dont thin kthats a principle we should be following because theres a difference between native syntax and author thing, its a contract that both ends in a codebase need to be aeawrae of to foloow. lets say youre integrating a component in a page which has its
own variables, and the compoentns has different variables and authors have to glue the two. when you have native conventions about this thing then you dont have to glue them together. im saying as a general principle it doesnt mean that if authors can do it by convention then we dont have to do it in the syntax
<ydaniv> +1
[css-color-5] Should relative `rgb()`/`rgba()` and relative `hsl()`/`hsla()` serialize exactly as declared?
<ChrisL> relative rgb()/rgba() and relative hsl()/hsla() serialize as rgb() and hsl() when alpha is unity.
ChrisL: i have a proposed resolution im going to paste it in now
ChrisL: regardless of what you specified, you drop the a
ChrisL: thats consistent with everywhere else i believe
ChrisL: many people said it was fine
fantasai: and this is for the specified value?
ChrisL: the spec says if its one then we drop the a. but i have two and the other one is up for discussion
fantasai: any objections?
RESOLUTION: relative rgb()/rgba() and relative hsl()/hsla() serialize as rgb() and hsl() when alpha is unity.
ChrisL: for the second one theres two ways we could go with
<ChrisL> relative rgb()/rgba() and relative hsl()/hsla() serialize exactly as specified if they use currentcolor, as alpha is unknown.
ChrisL: let me give one possible resolution
<lea> fantasai: I wonder if we could quickly resolve on that accentColor issue since it was brought up anyway and seemed to have general consensus? 😇
ChrisL: so if youre using currentcolor then you dont know what alpha is. if you set rgba you get rgba, if you set rgb you get rgb
ChrisL: the other one is to say that we dont care, we just use the aimiless form beauuse in the modern syntax you can set rgb and then give an alpha. either we eagerly preserve the a's or we get rid of them. i dont have a stron gopinion
florian: we tend to prefer the shortestserialization possible. if someone wants it the other way around for some reason i would be fine with it., the most important thing is define something
ChrisL: any other opinions?
fserb: i think there is a use case of people trying to get the color back and this is more work because it may change, maybe we should keep it, but not super strong on this. i think i would favor that
ChrisL: the only argument i had against it is that you have to keep around exactly what the author typed, but
fserb: its usually eaiser to do the shortest
ChrisL: yeah exactly
fantasai: anybody working on serialization have any idea? emilio?
emilio: slight preference for shortest serialization?
fantasai: ok, then does anybody object to that?
<kbabbitt> +1 slight preference for shorter serialization
fserb: for no relative colors do we always do the short version?
RESOLUTION: relative rgb()/rgba() and relative hsl()/hsla() serialize as rgb() and hsl() when alpha is unity or unknown (like with currentColor)
ChrisL: we drop the a
break until 12:00 CEST
<TabAtkins> w3c/
[css-color-4] Channel clipping breaks author expectations, especially when using 'perceptually uniform' spaces
<TabAtkins> w3c/
miriam: i opneed this issue because theres a number fo new colro sapces that are intended to be perceptually uniform and wide gamut in fa ct unbounded gamut. and in order for a color space to be perceptually uniform, it cant be spatially uniform. they dont have nice cylindrical edges like hsl. you cant have both of those things. these color spaces
are exceiting to authors for being able to move around in color space in ways thatfeel perceptually reliable. if i add a certain amount of lightness it should be a certain amount lighter which is not possible in hsl
miriam: the problem is, because we dont have uniform edges, we end up outside of them quite easily, at that point we have to decide what to do. the spec tries to handle that by maintining lightness and sacrificing chroma with an algorithm, proposal s for preserve lightness aprpoach. in browsers, corpping rgb channels can give you strange changes in
lightness and huge, its the worst of all cases
miriam: thats the summary of the issue. browsers ship the problem and not the solution, so some of the arguments should be that we shouldn't have color spaces that allow you to do this, we shipped the way to easily make mistakes but did not guardrail, we need some sort of guardrail in these spaces, to me that is preserving lightness
miriam: that is starting to get into other things, ok bye
fantasai: tab you have a proposal?
<una> (As a non-color expert I can +1 the pain points of using modern color syntax and getting unexpected results)
TabAtkins: ok, so as miriam said if you use a color far outside your gamut its going to be mapped to your gamut. the current proposal makes that depend on your monitor which can result in different colors displayed on the screen, especially since lightness preserving tends to sacrifice chroma, when you look at your screen and see low chroma they
design your color, they use that in their design, in the better monitor they get an insanely vivid pink instead of light coral
TabAtkins: current approach isnt future compatible with monitor technology if you specify colors outside of gamut when designing the page
<ChrisL> The "insane pink" is due to switching into HDR mode, so the comparison is invalid
<ChrisL> the claim of "no perceptual mapping" in ICC profiles is invalid
TabAtkins: second thing is that ever since css2, css colors and image colors have been magical. via the introduction of - color profile stuff, you can have an ff0000 red and and ff000000 in your page look the same, and its important for having your page colors match up with images used on the page and dont want color drops
TabAtkins: make sure that images and css colors work in the same way by default even if the fact that images and videos need to use cheap mapping methods rather than good mapping methods. were ok with authors opt into breaking that consistency even if the final result is not as ideal
TabAtkins: these altogether, whenever youre specifying a color with oklab or oklch functions, we eagerly map that into rec2020 gamut. somewhat arbitrary choice, we can accept others, fairly light gamut likely to encompass monitors for the future, small enough that even when you do cheap easy clipping into srgb you still get a color close to the
design intent. if designer is rec2020 and user srgb or vice versa it will still work out pretty well
TabAtkins: we dont care very much what the mapping method is to take the far out of gamut oklab color into 2020. if the spec wants to preserve lightness were ok with that
TabAtkins: do it eagerly so its future proof, once its in that gamut we want to make sure its allowed by the spec to match up with how we handle images and videos etc. because the quality mapping is fairly critical in that region. we do expect there to be an opt out method alternate function what have you that lets you specify oklab or oklch thats
not eagerly mapped
TabAtkins: ??? and you know its going to be played on a quality monitor, and then the other methods of specifying colors, that use arbitrary color schemes we prefer to leave those alone, as the browser sees fit video in that color profile, those arent designed for easy author useage on the page, they are sdesigned for hardware ? matching what they
might be used in an image for video we dont need to worry about authors to see a weird color unless theyre trying to match an image win which case it should match
TabAtkins: eagerly map oklab into 2020 gamut and if you need to reduce further from there provide methods for that, dont touch other colors, render as accurately as it can
TabAtkins: apple and mozilla folks are broadly supportive of that. simon finds it reasonable
TabAtkins: he also supports the ability to give authors choice of gamut mapping
TabAtkins: Tiann Louw from mozilla says that 2020 might be iffy, but doesn't think its a blocker and seems reasonable
TabAtkins: other thoughts?
ChrisL: i want to address two inaccurate statements. first is about colors that were wildly different vivid pinks, that was done by sdr color imagery and then throwing in an hdr color
ChrisL: so yeah ok thats a very different color, the other one which is frequently stated but not demonstrated that all colros inside gamut will never change. since i just mentioned hdr, hdr has sigmoid curve you will bring the darks down and lights up which means colors in gamut will change
ChrisL: if you have a perceptual rendering intent then colors inside the gamut will chagne so smooth gradients continue to look smooth. the other - thats perceptual rednering intent, relative ? will guarantee colors wont change, thats not the only option
ChrisL: its depends on what the ? is
ChrisL: firstly ill point out that this proposal droped an hour before the meeting, i have not had time to play with it and see what its properties are, its an interesting proposal but it hasn't been played with
ChrisL: cheap gamut mapping methods: people have proposed 5 or 6 methods of cheap gamut mapping which haven't received comments
ChrisL: some of them are very cheap like linearized ?? and then clip or compress down, single step process no loops very efficient could probably be done in hardware, no comments
ChrisL: hardware can do this because games work in linear light, so could be quite efficient but no comment on that
<ChrisL> https://
ChrisL: theres a gamut mapping playground where all o fthese have been implemented, you can put different colors in
ChrisL: theres been no comment from the chrome team about these proposals
ChrisL: some aspects are interesting, some aspects are concerning. this eager converting to 2020 gamut. if i take something out of gamut in oklch and gamut is 30 and this eager conversion, what happens when i get back the computed value? are they wildly different? has the chroma reduction happened? its saying that you specify one value and you use
a different value - how observable is that? it has changed, this seems odd to me
ChrisL: in terms of the 2020 reasonable target, id say, the reason i say that is because all the primaries are in spectral locus, you can only get them with 100% of one wavelength but then youd have greater than 100% ?? which is why youll never have a ProPhoto monitor because ?? the triangle can cover as much of the area as possible
ChrisL: was the point clear? im agreeing with the proposal there are real colors outside rec2020 but not very many, you have to look for real world examples. as a - if we have to have this as a boundary as a reasonable or unreasonable color, direct 2020 seems good ot me but im worried about the impact if this conversion is done behind the scenes, how do
authors work with this
TabAtkins: exact timing is - exactly what we want for gradients to work well is unclear, it would show up by computed value time, the conversion might happen at a point - is still a detail to be woked out. it should be good for authors
florian: i wanted to ask what do you mean by eagerly convert. is it parsing time? computing time? do you bring in direct2020 first and then do the color math? if you have functions do you convert before or after that?
florian: i think im hearing you say its up in the air, but maybe youve done that already
<ChrisL> s/lockers/locus/
ccameron-chromium: i think the way - within the general frame we are flexible, my way that im thinkig about it is to view oklab as having th egamupt mapping be a part of the definition of the coordinate spaces
ccameron-chromium: it would only be observable if you round to a different color space. it would be withini that definition of srgb or xyz or whatever your connection space is. in implementation terms this is done per pixel
ccameron-chromium: does that answer the question? its in the definnition of how the coordinates are defined in the coordinate space
florian: maybe? what im wondering about for example is as ? was saying, the boundaries are not uniform so if you tahke a color that - if youre gpoing to rotate it around, whether its in or out of gamut will depend on the view. so do you bring it into gamut first and then rotate or vice versa? would make a difference. i suspect what we want is
predictability so if its done late thats fine, that would preserve uniformity, but i havent thought deeply about this
ccameron-chromium: that sounds good if one is ?? doing this rotation, it would be that you rotate first then map, it may be that if one is doing a rotation in the context of some other operation then maybe we talk about ahaving an escape hatch to get out ?? i think thats particular case is smalll
ccameron-chromium: rotate then map vs other is rotate then map because youre working within the coordinate system
ccameron-chromium: how to implement it, its really thinking of it as a coordinate system rather than a mapping on all colors
florian: makes sense, thanks
lea: so lots of things to process. i left a comment but im going to summarize my points here. i do agree that its ok not to gamut map for rgb formats. i would rather not spec it as anything using the color funciton and scope it down to color spaces like display p3
lea: especially since down the line we plan to add custmo color spaces and we dont know what they would be or if they woul dbenfit from gamut mapping
lea: ??? once rgb formats dont gamut map you need relative color syntax to map to relative syntax and then you dont have gamut mapping
lea: i am not a huge fan of tying down css to a color space, id rather not repeat the same mistake, i think it woudl lbe ok to do that as long as we concisder the devide and map to whatever is larger for that color, but counter to what the proposal was trying to do. what many people have not realized is that ccameron said that people can specify
imaginary colors and then monitors can do it and then you have a color thats burning through your eyes, but they are happening gradually
lea: were talking about extremely bright colors on unmaintained websites, but these websites tend to not be the ones that what most users are using
lea: and it happens so gradually that people do have time to adapt. its not like suddenly a display comes out that that can display ?
<TabAtkins> We do not, usually, intentionally design for slow breakage when we have a way to avoid it.
lea: worry is overprounounced compared to reality. i do think its important to let authors control
lea: different use cases prioritize different things. some cases propritize color mapping between image and videos. others abou tlightness preservation or hue or chroma
lea: having a control for this would be the best of all worlds. by default it should be lightness were preserving for ax. anything esely you preserve could have readable for developers but not readable for other peopls monitors
lea: and preserving chroma should not be the default because its not a stable stragegy.
lea: if we preserve lightness or hue then theres always a color in gamut for any gamut. for chroma theres no such garauantee because its usually chroma that gets you out of gamut. centering design aroung images and videos is wron gpriori8ty. i dont think its as common as preserving author intent all over ui, far more important use case than images
and videos, which there should be some way to get it but we shouldn't be designing entire css color sysntax around this one use case.
lea: people mentioned perceptual rendering intents that end up changing colors that are already in gamut, i dont think thats an optipn for css, we should preserve colors in gamut
lea: if we start changing colros in gamut we could be changing srgb colors that are widely employed. we are not bound to using the same gamut mapping stragety geverywhere
lea: we scould use one for gradients and use another one for background and borders or text colors or anything like that.
<ChrisL> Here is a chromaticity diagram for ProPhoto, showing primaries well outside the visible limits
<ChrisL> https://
<dbaron> +1 to perceptual rendering intents that change colors in gamut not being a reasonable option for CSS
miriam: thought overlap with lea's, like chris said i havent played with this so i dont know the results of it. i am frustreated in the proposal that all of the prioritizeds are around image and video matching whent his entire discussion started out of author requests for some other prioritizes
<TabAtkins> That's... not at all true? It's part, but the future-hostility is the biggest part.
miriam: feels absurd that those get dropped every time we come to it
<TabAtkins> It's *the first thin in my list*
miriam: yes image and video matching are important but please stop dropping all the other author use cases
<TabAtkins> whooops i'm out, my uber is here in two minutes
<lea> +infinity to what miriam just said
<lea> 👏🏼👏🏼👏🏼
miriam: the other frustration there is when i proivde example to hue shift has problems for other cases im told thats an edge case, but then the counter example is this bright pink that required jumping into hdr rendering, and that is somehow not a strange edge case, so just frustrated about how this is presented, but maybe its fine i should go
play with it
ccameron-chromium: playing with it, theres an experimental flag in chromium that we published a while ago called css gamut mapping. do give that a try, unfortuantely its been a while so its there in stable right now but its expired so we have to make sure its still kept alive
ccameron-chromium: that is roughly the place and time of where it would be applied. in terms of priories, its important to have prioritises - important to address use cases
ccameron-chromium: the main thing of the proposal is that it doesn't break color matching, if color matching is to be broken we want users to say this is my intention. that flag in chromium modula o the xact math it does what the proposal is proposing
lea: is clipping the default behavior in stable chrome/? i remember experiments with other behaviors without a flag
ccameron-chromium: its always been that we will clip it at a certain point, near or above the monitor. there will be some clipping
ccameron-chromium: in some circumstances the clipping is done further down the pipeline than us, it will be done either by windows or macos, and the os has the option to do something mroe but chrome does clipping of all colors specificed except for that flag, ?? will be gamut mapped with that flag
lea: so if that flag is not set then it just passes it to the os without clipping?
ccameron-chromium: yes
<Zakim> lea, you wanted to react to ccameron to ask ccameron-chromium if the current behavior in stable Chrome is still clipping
florian: for a while without having thought of the eact proposal that something resembling it is likely part of the solution set that we want to look after. whether that should be dthe default behaiovri is another question. which use case tdo we prioritize? we have mu;ltiple use cases and this or something like this probably should be available.
wehther matchig videos and images is the thing we prioritize or whether we go closer to some other things that mirian was talking about and opt into this
<ChrisL> https://
ChrisL: so firstly i want to drop two links to images
ChrisL: one shows primaries are outsid ethe primaries of the shape, the 10% pure wavelength there are no colors outside that. if you compare that to direct 2020 it is exactly on the edge, you cant get bigger, it sthe largest gamma you can get if you have three primaries ant ehpeimriare s have to be real were not going to get biger than that unless
we ? primaries
ChrisL: question: when chrome does hdr mode for image and video is any tone mapping applieduse more
<lea> ChrisL: These diagrams have two triangles. What's the inner one? sRGB?
ccameron-chromium: videos are passed to the os and ? mappings apply, for images tone mappi9ng apply to get you into the tone range of the monitor. there are the vast majority 99.999% of images that are hdr are done using the ? map format, with that format it is possible to specify color match with css
ccameron-chromium: you can specify that colors reamin gifxed, a specific pixel remains fixed, so you can color match wih css or with video or anything else
ChrisL: so youre saying that if you have a gain map image you have to tailer the gain map so that the pixels that you want to be unchagned remain unchanged right?
<Zakim> florian, you wanted to react to florian
ccameron-chromium: ? has to specify ? so if you have an emoji that you put into your image then ? will do tone mapping, otherwise people use ? to determine what that will be, but every pixel comes with tone mapping, i think tab or someone suggested that css could have an equivalent thing where you specify theres the max of what i would want this to
be, and im supportive
ChrisL: so if i go into current builds of photoshop and export a gainmap image, heres my hdr photo i just took and i export i t out it calculates the gainmap there will be no clor match because the gainmap software will interpolable between sdr and hdr and that tone mapping operation will chagne all of the in gamut colors unless i specificaly edit
the gainmap unless i say these are the ones i dont want to chagne. im pushing on this because as mia said we are moving to a model where mapping between images and colors an ddoing perceptual manipulations is low priority and yet in the gainmap image speac eyou have to identify pixels you dont want to chagne otherwise they will change
ccameron-chromium: with the gainmap images in particular, if one exports it from photoshop, they key thing is the determinism there. is that its well defiend how - there are two points you move between. the key takeaway is to look at whats oign gon in the world of hdr video where hdr video color matching is not possible and i would characterisze
hdr video as when viewed in desktop computers and mobile devices as a sdisaseter zone. every application that tries to integrate hdr video into their app is frustrating and gives up and goes to sdr because the interaction is underdefined in there
ccameron-chromium: in terms of color matching gainmap images give a ? where that is possible. if you dont need to colo rmatch to any color of that image thn thats fine if you go into ps and export and sdr image you can ? color matchi f you want to,
ccameron-chromium: ?? color matching between images and videos it was behind every corner, the key thing is to think of it as a parameter space. better to give users parameter spaces where theyre going to bget a specific behavior. would like heres a ? preserving space, heres a hsl kind of space whereits more chroma perserving, heres something where
its more perceptual. color matchihng is the cornerstone of color management and its very hard to make a system that works twithout it
ccameron-chromium: the other different options are - im a fan of ? a different option to have them, ? from the pserspective of color matching, i like it woudl be wonderful to support css colo s that have some sort of gainmap like scheme ? and were ok with anything in between them
dbaron: repeating what tab said on irc before he left, which is that what he said is that his top motivation in response to the argument that e primary motivation was to do image and ivdeo matching, tab had said that his primary motivation was about the future compat issues and not about image
dbaron: i dont want to put words in his mouth but it soudned like it was a motivation but the biggest was future compat
ccameron-chromium: in terms of the compatability thing in 2020 vs other spaces, i would emphazie that im fine with other options as long as its well defined. there is this difficult that its hard to define whats a wide color sdr color vs hdr color, in some discussions were discussiong we can do it based on ??? sheet of paper and that kind of thing
as sdr
ccameron-chromium: srgb colors go outside of that gamut, so its very hard to find a dividing line between sdr and hdr, that will always be some boundary in place and map to that, any definition is fine, 2020 was what ??
<miriam> (doing only a quick comparison, I'm pretty happy with the results of the chrome algo so far)
<Zakim> lea, you wanted to ask, if we do adopt the proposal to gamut map to Rec.2020, can we change it later, as screen gamuts evolve? Or will we be stuck with Rec.2020 forever?
lea: if that is the case, if we can change it alter then gtiven that tehde current situation is the worst of all words,, ,right now we have the terrible sitation the me and mia have describes and that these colors are unusuable, and given the fact that - i think there is even if we dont have consensus about everything we do have consensus baout
some things. we have consensus around rgb spaces not gamut mapping, author intent is clear there, hard to ?? without intending to, given taht the blink folks are willing to gamut mapping with 2020, and open to changingi it alter, we could resolve to do that while exploring better solutions because the longer we go without any mapping the harder it
willb eto change, not hard to go to 2020 to p3 than the current situation where verything is clipped
lea: i would be in favor of resolving for that as long as its not the end of gamut mapping and that this is just lets resolve on this because its better. once we resolve on this then foolks wil give us feedback because weve been trying to get this feedback for months or years with no response
lea: as chris described earlier
fantasai: proposal on the table to do gamut mapping by ok stuff to rec2020 and continue discussing the issue
lea: this should not be framed around spaces like oklch but device and ? color spaces. right now they are oklab oklch ? and ?
lea: should also apply to future spaces, they will have the same problem
<ccameron-chromium> with respect various gamut mapping algorithms, it's an issue that the gamut mapping is applied at a time that breaks color matching.
fantasai: i would like the chrome reps and peole in this issue what are the action items you want to assign to each other because we are going to assiign actin items
lea: is the proposal that we gamut map to 2020 and then its normative to clip or that they re allowed to clip
fantasai: leave it undefined and continue discussing
<lea> PROPOSED RESOLUTION: Gamut map all device independent color spaces to Rec.2020 for now, UAs are allowed to clip or gamut map from there to device gamut. Exact GMA TBD
ccameron-chromium: would it be ok to respond to whether ? algorithms or are we short on time?
<dbaron> ccameron: I agree with that [leave it undefined]. [earlier]
fserb: what about having a way to opt out of this?
<lea> PROPOSED RESOLUTION: RGB color spaces do not gamut map (srgb, display-p3, rec2020, a98rgb).
ccameron-chromium: chromium is ok with ok spaces, for lab and lch were a bit more afraid of that because lab is used as a canonical color space for ICC/ [??] color matching, were a little bit uncomfortable with that but ??
lea: about escape hatch, relative color syntax to go to one of the rgb spaces
ChrisL: resolution doesn't say when it happens so we can timplement it
<fantasai> PROPOSED: Gamut map all device independent color spaces to Rec.2020 for now, transforming from there to device gamut is undefined. Exact gamut-mapping algorithm TBD. Continue discussing in the issue.
fantasai: continue discussing in issue
RESOLUTION: Gamut map all device independent color spaces to Rec.2020 for now, transforming from there to device gamut is undefined. Exact gamut-mapping algorithm TBD. Continue discussing in the issue.
lea: im not sure about xyz ones
fantasai: does anyone want to discuss that resolution further?
dbaron: just to reword so its clear what its a list of
<fantasai> PROPOSED: RGB color spaces (srgb, display-p3, rec2020, a98rgb) do not gamut map.
ccameron-chromium: is the resolution oklab oklch maybe some other things question mark and then not gamut map rgb?
ccameron-chromium: sounds good
ccameron-chromium: rest is still under discussion?
fantasai: uyes
RESOLUTION: RGB color spaces (srgb, display-p3, rec2020, a98rgb) do not gamut map.
fantasai: now i want to ask people what action items should be taken away from here? lea wants feedback on gamut mapping algos so we can pick a good one. action item for?
lea: ccameron
ccameron-chromium: i think the core issue ive been failing to communicate is the breaking of color matching and specifying far out of gamut colors and particular choide of algo is separate to that. its about where the algos fit but now which one it is
ccameron-chromium: earlier i had issues with the algos perf characteristics, more the problem with the approach of where mapping is being placed
fantasai: will you review the gamut mapping algos?
lea: we need feedback from someone
ccameron-chromium: i can look at them again
fantasai: then chris lea and mia to look at chrome proposal
ACTION: ccameron: review gamut mapping algorithms
ACTION: lea, chris, mia to review Chrome proposal discussed today
[css-color-5] Should colors nested in a parent color function (RCS, color-mix, light-dark, color-contrast) serialize in their most precision saving form
ChrisL: The nesting of things with color-mix()/light-dark()/ etc. was not fully specified
ChrisL: We discussed some, and we have some proposed replacement text that looks extremely detailed and accurate to me
ChrisL: So I'd like to adopt into the spec
<ChrisL> w3c/
RESOLUTION: Adopt the proposed text
[css-color-5] Behavior of `none` in relative color syntax
lea: We have this concept of "none", which defines a missing color component
<emilio> lea, can you use a mic?
lea: when you interpolate with another color, and the other color has an actual number
lea: then that component will take its value from the other color
lea: This concept started for representing achromatic colors
lea: but it also allows specifying parts of color and adding in by interpolation, which is useful
lea: we recently resolved to preserve none in calculations
lea: previously computed to zero, in order to avoid exposing color space math
lea: but implementers interpreted as "any time you do any math, compute to zero" which isn't needed
lea: in April we resolved to preserve "none" in calculations
<fserb> +1
ChrisL: Suggest we adopt changes proposed by Romain Menke
ChrisL: idk if we need more changes to close the issue
w3c/
lea: that's a problem from a different issue
<lea> w3c/
lea: right now we have concept of analogous color spaces
lea: can convert to a different color space, can convert none
lea: e.g. lch and oklch, a lightness of none will be preserved
lea: you make the none's zeroes, you convert to other color space, you plug the none's back to the alogous components
lea: but wouldn't work if you preserve calculations if different scales
lea: e.g. rgb and color(rgb)
lea: in color function range is 0-1
lea: in rgb the range is 0-255
lea: so adding 50 to rgb color is 20%, but srgb using color function is nonsensical
lea: I think that should be allowed
lea: not sure what the solution is here
lea: but preserving calculations when converting to differnet color space is iffy
lea: preserve for other operations, but maybe not converting colors
<Zakim> ChrisL, you wanted to ask if the edits suggested in w3c/
lea: either preserve none as a whole or drop ti
ChrisL: I'm not sure
ChrisL: I think preserving none is the right thing, but I'm not sufficiently sure
lea: when converting color spcaes, numbers mean different thing
lea: having a whole component as none made sense, but calculations if converting it's ...
lea: anything we come up with would be way too weird
<miriam> +1 preserve none unless converting spaces
<emilio> nope
fserb: when crossing function boundaries where maybe stop making sense, you need to convert none
lea: agree, anythng else seems super weird
fserb: think about those boundaries and resolve at them
<lea> PROPOSED RESOLUTION: `none` in calculations is converted to 0 when converting a color to a different color space. It is still preserved otherwise, and is still preserved when used as the whole value of a component.
RESOLUTION: `none` in calculations is converted to 0 when converting a color to a different color space. It is still preserved otherwise, and is still preserved when used as the whole value of a component.
[css-color-4] Expand the concept of analogous components to analogous sets of components to minimize `none` → `0` conversions
lea: mapping between components of analogous color spaces is well-defined in the spec
lea: e.g. mapping green to green, ligthness to lightness, etc.
lea: if analogous component exists in other color space, after conversion none is preserved
lea: we convert none to zero, and then convert, and then put none back
lea: want to expand the idea
lea: if lightness is none and convert from labl to oklch
lea: lightness is still none
lea: but if lightness is a specific number and a/b are none they would become zero
lea: what this concept defines is .. if you split the components into sets that correspond
lea: then what remains is also analogous
lea: so a+b is analogous to c+h
lea: this mainly makes a difference for lab to lch
lea: or colors where all are none
lea: that would be an analogous set
lea: that's logically consistent
<dbaron> makes sense
fserb: will you describe in the spec in those terms, or actually list all the combinations?
<ChrisL> I think these analogous sets make sense
<dbaron> (it doesn't sound to me like there's much of an explosion... I think)
lea: combinatorial explosion. So anything that remains after subtracting the analogous components is (as a set) an analogous component
<lea> PROPOSED RESOLUTION: Expand concept of analogous components to analogous *sets* of components.
PROPOSED: The components that remain after removing the anlogous components are (as a set) an analogous component.
<dbaron> (including all components being none being analogous for all color spaces)
<fserb> +1
RESOLUTION: Also any set of analogous components are
[css-color] Clarification needed on how missing alpha components flow through relative color syntax for hsl/hwb
ChrisL: Alpha is analogous to alpha needs to put in the spec
ChrisL: Romain Menke points out that we have no interop on none alpha
ChrisL: Chrome interprets it as the component of the other color per spec
ChrisL: Safari and Firefox don't, treat as zero, unclear to me if they consider it a bug or think the spec should change.
ACTION: fantasai and emilio to ask their respective teams this question
[css-color-5] RCS channel keywords interaction with calc() is underspecified
ChrisL: About preserving numeric values of keywords
ChrisL: is it parse-time, computed-time, or used-time resolution?
ChrisL: Color 5 doesn't specify
ChrisL: if you do calc(none * 2) what do you get?
ChrisL: does it evaluate to none or nan or what?
ChrisL: no discussion
fserb: is it different from what we just discussed?
ChrisL: seems related
ChrisL: but about whether you preserve calc() explicitly as calc()
<emilio> w3c/
dbaron: I think we have general principle for calc() that we resolve at multiple value stages
dbaron: if you can resolve at earlier stages, you do; if not then preserve to later stages
dbaron: I think that's what happens for <length> calc(), e.g. calc(1in + 5pt) gets resolved immediately
dbaron: but calc(1in + 1em) needs font-size, so resolve it later
dbaron: maybe that applies to some degree here?
emilio: also issue of what does multiplying by none even mean?
emilio: Another issue linked which discussed it a bit
emilio: what I proposed was to make none infectious like nan
emilio: but lea wasn't happy about that
emilio: so deciding what to do with none changes when you can resolve some of these calcuations
lea: Reason is, when you have none
<dbaron> (Yeah, I have no idea what it means to do math on none....but I'm also not following this spec that closely.)
lea: can have e.g. clamp(0.5, none, 0.6)
lea: that means give me value from other color, and clamp it
lea: if it's infectious, that could mean lightness is unrestricted which could make text unreadable
lea: not sure what 'none * 2' means.
lea: if you interpolate with another color, then none becomes value of the other component and then is multiplied
lea: so color-mix() in oklch
<lea> color-mix(in oklch, oklch(calc(none * 2) .1 180), oklch(.5 .1 180)) =
lea: that would produce...
<lea> oklch(1 .1 180)
lea: it's like a late variable
miriam: for a specific use case, none + 180 in a hue is a common use case
dbaron: just to throw out an example that's awful
dbaron: if you have calc() on none in both colors in a color-mix, need to say what happens
dbaron: presumably none in the result?
lea: I think this was well-defined
lea: if both none-containing expressions, then you use calc-mix() to interpolate until you can resolve the nones
dbaron: but only meaningful if then mixed with something else?
lea: yes, either mix with something not none, or become zero
dbaron: ok
fserb: I think everything inside calc() is context-dependent
fserb: calc(none + 180) going to do something on the other side
fserb: calc has to be resolved before you do relative color syntax
fserb: You cannot leave the relative color syntax without resolving the number
fserb: the number resolves ...
fserb: the number that calc() returns, it depends on that context
fserb: if you converting from anything with a hue, calc(180) you can't keep calc and [missed]
lea: this is confusing
fserb: if you keep calc() means you won't look inside until later on
fserb: to move forward on relative color syntax, it needs to become a number
<dbaron> maybe I'm not ok with that answer... still confused about what color-mix(in oklch, oklch(.5 .1 calc(none + 180)), calc(.3 .1 calc(none + 180)) means...
fserb: it's only meaningful as a number, not as an unresolved calc()
lea: what is the proposal?
fserb: calc() cannot be carried out of relative color syntax
fantasai: Let's take back to the issue or lunch break
[css-color] How to handle out-of-bounds legacy srgb values?
<ChrisL> Proposed Resolution: out-of-bounds legacy srgb values are clamped at computed-value time
ChrisL: oriol's suggestion
fserb is nodding
emilio: does this match implementations? I think it doesn't
emilio: seems fine-ish
emilio: but I thought implementations were fairly interoperable here
oriol: in the tests I have, I was producing this legacy rgb colors using animations with custom timing function that could force one of the children to become negative
oriol: what I saw was that webkit clamps at computed value time, but Blink and Gecko did not
oriol: so child would inherit value that's out of bounds
oriol: if you serialize the color hten it gets clamped
oriol: if you reassign the serialization then it doesn't really round-trip on children that are inheriting
dbaron: This is proposing that they are clamped at computed value time in addition to any clamping at parse time?
<dbaron> ChrisL: yes
emilio:
emilio: color-mix() not being able to represent animations is a problem
emilio: otherwise you can't express currentcolor in the computed value properly
emilio: we should maybe revisit this, which may change the resolution here
ChrisL: Let's take it back to the issue then