Open annevk opened 6 years ago
As mentioned in that bug, an IDL enum would be even nicer.
IDL enum should be fine. Currently both authors do not participate in the W3C. Need to check with the CSS Wg if I can add those changes.
Proposal: Add IDL enum definitions for canvas compositing strings. String definitions can link to the CSS key value counter part. @annevk would that be ok?
Agree that this is a DOM definition and so should use the IDL syntax.
Should the mix-in interface that uses these values also be defined in this spec, or is it sufficient to define the enum here and reference it from the canvas specs?
Alternatively, the canvas spec could define the entire IDL (including the enum of possible values) and link to the individual composite mode definitions to define what the keywords mean. It would mean that any updates to add new composite modes would need edits to both specs, but I don't expect that will happen often with composite modes (as opposed to blend modes.)
For reference, the current HTML (Living Standard) definition of the function is:
interface mixin CanvasCompositing { // compositing attribute unrestricted double globalAlpha; // (default 1.0) attribute DOMString globalCompositeOperation; // (default source-over) };
The globalCompositeOperation attribute sets the current composition operator, which controls how shapes and images are drawn onto the output bitmap, once they have had globalAlpha and the current transformation matrix applied. The possible values are those defined in the Compositing and Blending specification, and include the values source-over and copy.
(Aside: the links in the Compositing & Blending spec should probably be changed to point to the WHATWG Living Standard instead of the no-longer-updated W3C Canvas2D spec.)
@dirkschulze Would you be willing to take on this spec as a new editor? There would need to be an active editor to publish an update.
Also since the spec is already CR, we'd need to get an opinion from the WG as to whether this counts as an editorial clean-up or if it requires a new WD then CR.
@dirkschulze yeah, or link the string definitions directly to the algorithms, just as you do for CSS. But indirection seems acceptable as well.
@AmeliaBR canvas did originally define the values, but they were moved here so that new compositing modes would require only changes here. I'm okay with undoing that change though. Up to you all.
@AmeliaBR
Also since the spec is already CR, we'd need to get an opinion from the WG as to whether this counts as an editorial clean-up or if it requires a new WD then CR.
We no longer have to go back to WD to make changes; we just request transition for an updated CR https://www.w3.org/2018/Process-20180201/#revised-cr
Proposal: Add IDL enum definitions for canvas compositing strings. String definitions can link to the CSS key value counter part. @annevk would that be ok?
I see that @annevk said that it would be.
@dirkschulze Would you be willing to take on this spec as a new editor? There would need to be an active editor to publish an update.
I agree there needs to be an active editor. I did a bunch of cleanup just now, but I am wary of signing up as editor as I have a fair number of specs already.
@dirkschulze Would you be willing to take on this spec as a new editor?
Would still like to see that happen if you are willing :)
In particular https://drafts.fxtf.org/compositing-1/#canvascompositingandblending cannot define the values in terms of CSS values. See also https://www.w3.org/Bugs/Public/show_bug.cgi?id=27313.
What would be good I think is to have a table that links the string value (used for canvas), CSS value (used for CSS), and algorithm together.
(It would also be somewhat nice if the algorithm sections list the value used for them and not just a title cased header.)