Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Interop issue with canvas globalCompositeOperation "normal" value #7637

Open
domenic opened this issue Feb 18, 2022 · 7 comments
Open

Interop issue with canvas globalCompositeOperation "normal" value #7637

domenic opened this issue Feb 18, 2022 · 7 comments
Labels
interop Implementations are not interoperable with each other topic: canvas

Comments

@domenic
Copy link
Member

domenic commented Feb 18, 2022

Spinning off from #7599 (comment)

Before #7599, the spec said

The possible values are those defined in Compositing and Blending, and include the values source-over and copy.

which is very unhelpful. In that PR, @Kaiido made it more precise:

If the given value is not identical to any of the values that the <blend-mode> or the <composite-mode> properties are defined to take, then return.

However one of the values for <blend-mode>, namely "normal", is rather special. @Kaiido says:

There is actually an interop issue here. For Chrome (and maybe WebKit since they have the same behavior), the thing is that it's either <composite mode> + <blend:"normal"> or <composite:"source-over"> + <blend mode>. And at getting if we have <blend:"normal"> they return the composite mode.
This means that they do actually accept the input "normal" but it maps to "source-over" at getting.
Firefox on the other hand seems to ignore "normal" completely.
Here is a small test: https://jsfiddle.net/necuLt90/

/cc @whatwg/canvas to help us figure this out.
@domenic domenic added topic: canvas interop Implementations are not interoperable with each other labels Feb 18, 2022
domenic pushed a commit that referenced this issue Feb 18, 2022
@Kaiido
Editorial: modernize the canvas Compositing section
2ed482c 
This largely consists of defining new underlying concepts to back getters and setters, and make better use of existing ones.

It also makes the setter algorithm for globalCompositeOperation more precise, by clearly referencing the <composite-mode> and <blend-mode> properties instead of saying "the possible values are those defined in Compositing and Blending". (This did uncover an interop issue which we will track in #7637.)

Finally this renames the "current composition operator" to "current compositing and blending operator" (as per the Compositing and Blending spec's wording) and fixing the uses of "composition" vs "compositing".
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
@Kaiido
Editorial: modernize the canvas Compositing section
560371c 
This largely consists of defining new underlying concepts to back getters and setters, and make better use of existing ones.

It also makes the setter algorithm for globalCompositeOperation more precise, by clearly referencing the <composite-mode> and <blend-mode> properties instead of saying "the possible values are those defined in Compositing and Blending". (This did uncover an interop issue which we will track in whatwg#7637.)

Finally this renames the "current composition operator" to "current compositing and blending operator" (as per the Compositing and Blending spec's wording) and fixing the uses of "composition" vs "compositing".
@evilpie
Copy link

evilpie commented Feb 25, 2023

I think it would really be better to have an explicit list for this. <composite-mode> includes "plus-darker" and "plus-lighter", which isn't supported by Firefox or Chrome (I haven't checked Webkit)

@Kaiido
Copy link
Member

Kaiido commented Feb 26, 2023

Safari does support these two modes on CSS and canvas, I believe Chrome is in the processs of addingplus-lighter to their canvas after they implemented it for CSS https://crbug.com/1404963
Neither Chrome nor Firefox support plus-darker in CSS.
Firefox doesn't support clear <composite-mode> either.

I guess the question is, is it expected that the canvas should have a different list than CSS at some point? If only normal should have a special treatment it's probably easier to keep the CSS -> canvas mapping and let fxtf do all the definitions and list.

@annevk
Copy link
Member

annevk commented Feb 27, 2023

Generally we've tried to align 2D canvas with CSS (and SVG). So that is what we should do here as well.

I'm not sure how much I trust upstream to do a good job of also updating the 2D canvas tests though whenever they add new values. Not sure how to best approach that.

@fserb
Copy link
Contributor

fserb commented Feb 27, 2023

I think matching to CSS is the right thing to do.
Confirming what @Kaiido said, I'm in the process of adding plus-lighter to canvas on Chrome. Will wait until plus-darker is supported on CSS to add.

@Kaiido
Copy link
Member

Kaiido commented Feb 27, 2023

@fserb any input on what should be done to "normal"? Was my reading of Chrome's behavior in comment 0 correct? And if so, do you think it's the one that should be specced? (To be clear that would be mapping "normal" -> "source-over" explicitely.)

@evilpie
Copy link

evilpie commented Mar 6, 2023

Firefox doesn't support clear either.

Good point. I actually found this issue while working on the implementation of "clear". https://bugzil.la/1816775

@evilpie
Copy link

evilpie commented Apr 1, 2023

At this point I've added "clear" support to Firefox including some basic generated tests: web-platform-tests/wpt#39300.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
interop Implementations are not interoperable with each other topic: canvas
Milestone
No milestone
Development

No branches or pull requests
5 participants
@fserb @evilpie @domenic @annevk @Kaiido