-
Notifications
You must be signed in to change notification settings - Fork 645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-color-6] add color functions for some (or all) compositing/blending operations #8431
Comments
Thanks for opening the issue? Are there use cases for every possible |
I think there are use cases in so far as there are use cases for setting composite modes or blend modes -- combined with the use case for wanting to use such a color function as part of a color contrast function. That said, CSS currently exposes only the blend modes and not the composite mode (which seems a little odd to me). I admit that partly I suggested the composite mode because they produced a clear syntax with the mode as the operator. |
Composite modes and blend modes operate on entire elements. Are there any use cases for isolated colors, that are NOT covered by existing syntax? |
I was actually going to file this issue. Would the proposed function here allow achieving the same results as this?
I suggested color-mix() to someone facing this, and I realized that it wouldn't work because you would end up with a semi-transparent color. Maybe some fancy mix involving relative color syntax and color-mix() might work, but at this point, it's more convoluted than it should be. I'm happy to file a new issue if this use-case isn't covered. |
I think even a simple version that doesn't take a composite-mode would be useful here: |
We should consider if extending |
I’m still missing a discussion on use cases. How can we design syntax, and discuss if we need a new function or an extension of |
#8431 (comment) describes exactly what I would use such a function for. Someone was asking me how they could turn a semi-transparent color into an opaque color by blending one of top of the other. I'm not sure |
Some thoughts:
These could be added, but currently |
I saw that comment, but that is not really a use case, it's an attempted solution to a use case. What were they trying to do that required this operation? What was the actual problem they were trying to solve? |
The person wanted to blend one semi-transparent system color ( |
I could see people wanting this when working with design systems too that have both opaque & semi-transparent colors |
So are there any use cases that require more than simple alpha compositing? |
Not that I'm aware of, I would be satisfied with a |
We can still do |
Looking at it again, that seems unnecessarily wordy. Let’s just do |
I was looking for this! Thought for sure this was possible with |
So, in terms of specifying this: we should presumably reference General Formula for Compositing and Blending from Compositing 1. However, that spec is silent about colorspace, at least in the normative parts, and simply refers to "the premultiplied color". The examples use Red Green and Blue, natural given the age of the spec, and at the time sRGB would be assumed. The more complex parts such as blend modes even use the NTSC luma formula (operating on gamma-encoded RGB values)
but that doesn't affect the simple
I recall hearing that on some systems, compositing happens in the native RGB colorspace of the display (eg P3). |
Is anyone arguing against this? If not we could do an async resolution. PROPOSED Resolution: Add a |
What happens when you put more than 2 colors? |
You start from the end, and do them pairwise. In other words Edited to correct syntax
As @LeaVerou said
|
The CSSWG will automatically accept this resolution one week from now if no objections are raised here. Anyone can add an emoji to this comment to express support. If you do not support this resolution, please add a new comment. PROPOSED Resolution: Add a color-over(#) function to CSS Color 6 to do simple source-over compositing |
(Not an objection because I would love to have this feature in CSS, but note that there are only 7 participants in this thread, so only 7 people got a notification with a chance to object / propose alternatives.) |
@benface that’s fair, but note that I also posted this to www-style (https://lists.w3.org/Archives/Public/www-style/2024Jul/0012.html) and the resolution is not entirely binding. If this resolution passes then we will add it to the spec draft, but I expect we will continue to debate syntax and even whether we should remove it from the draft. Nothing is ever final in CSS specs until it’s interoperably implemented and web content depends on those implementation details. |
I think I'd prefer to take up this topic on a call. |
@fantasai can you give us some indication of what you would like to change about the proposed resolution? |
Well, first off I don't think there's clarity in this thread about what the proposal actually is. :) For example, Chris's proposed resolution uses a comma-separated syntax, but his subsequent examples are space-separated. But in general I think it's better to discuss non-trivial issues on a call (for a variety of reasons that aren't specific to this issue), and I don't think adding a new feature can be considered trivial. |
My mistake.
Fair enough. |
I also suggest picking a name that can later accept different compositing/blending operations as the first argument (similar to how we set up parameters for a gradient at the start of a gradient stop list), since it seems reasonably likely we'll want to expand in that direction at some point. (I don't think we need an operator per list item; if authors are getting that fancy, they can nest these functions.) |
I agree with @LeaVerou that I would suggest either:
or (based on @fantasai's internal suggestion):
(potentially the blend mode could be preceded by the |
|
The CSS Working Group just discussed
The full IRC log of that discussion<ChrisL> q+<Rossen4> ack ChrisL <matthieud> ChrisL: you want to composite color1 on color2 <matthieud> ntim: currently web devs need background gradient to composite one color on top of the other. <TabAtkins> +1 to the functionality too, seems easy and moderately useful <matthieud> ChrisL: proposition is using color-layer <fantasai> color-layer([<blend-mode>, ]? <color>#) <astearns> slight preference for color-over, as I associate *-layer with stacks of things <matthieud> ntim: either color-over() or color-layer() and inside the function you have a comma separated list of colors and optional blend-mode <miriam> layer-colors() reads better to me <matthieud> ChrisL: optional blend-mode preference, if not specified you get the default <matthieud> fantasai: we agree on the arguments of the function [<blend-mode>, ]? <color># <Rossen4> ack miriam <ChrisL> q+ <ntim> q+ <matthieud> miriam: color-layer read weirds because it's not a single layer <matthieud> miriam: proposal for layer-colors() or color-over() <fantasai> color-layers? <Rossen4> ack ChrisL <Rossen4> ack ntim <matthieud> ChrisL: all color functions start with color-* <ChrisL> ntim++ <matthieud> ntim: consistency with color-mix() <miriam> color-stack(), color-over()… <matthieud> ChrisL: color-stack() sounds like stacking context, weird <fantasai> POLL: A) color-over B) color-layer C) color-stack <fantasai> D) color-layers <nicole> D <fantasai> not A <astearns> A <matthieud> D <ntim> A or B (no strong opinion) <Rossen4> D B <schenney> B <ChrisL> D <TabAtkins> d <miriam> A C or D <kbabbitt> A > D > B> C <schenney> Change: D <ethanjv> D > A <masonf> someone needs to write some code to see which option won. <nicole> haha <matthieud> Rossen4: based on first choice color-layers() win <ChrisL> \0/ <fantasai> RESOLVED: color-layers([<blend-mode>, ]? <color>#) <matthieud> RESOLVED: function name is "color-layers()" |
Big -1 to this new This is a function creating a
|
I'm not sure I would immediately think Something like I don't think either instantly calls to mind Porter-Duff more than the other. Mainly people who know how compositing works are the ones that would make the association, and whether you use Out of all the suggestions, I probably don't like |
|
@fantasai's suggestion of layers comes from If I'd choose another name, I'd choose either:
Not a fan of |
In #7358 (comment) @LeaVerou wrote:
In today's telecon, for the same reason (and I think not having read Lea's comment) I suggested something similar:
In other words, what I was thinking was roughly a
composite(
<color>
<composite-mode>
<color>
)
function, which has a slightly larger feature space. (Except I didn't want<composite-mode>
exactly, because I'd rather not have thesource-
anddest-
prefixes in this case.)But it's possible we might also want to allow choosing the
<blend-mode>
.Opening this issue because it seems like this side discussion probably deserves its own issue, and we can decide whether or not we actually want such a feature.
The text was updated successfully, but these errors were encountered: