Re: [csswg-drafts] [filter-effects] feComposite (Porter-Duff) operator values do not match those defined in the referenced [compositing-1] spec (#5267)

>  The Filter Effects spec extended SVG 1.1 filters to include "non-duplicated" composing values in Compositing 1. See: Changes section of Filter Effects. The prose in the feComposite section does not mention this change...

I can see that "lighter" was added after the 2013 WD, but that's it.

I had a look at @adambelis's example.

* The spec, Chrome, Firefox, Inkscape and our own renderer accept (for example) "over" as a valid operation, with "in" always acting as the A ("src") channel and "in2" as the B ("destination") channel (@mclegrand this is definitely specified: "with in representing the source" is in the paragraph defining the "operator" attribute)
*  In addition, Inkscape *also* accepts "destination-over", "destination-in", "destination-out" and "destination-atop" as valid names of operations, which function exactly as "over", "in", "out" and "atop" except that the two channels are reversed. (There's no "destination-lighten" or "destination-xor" because order doesn't matter, and no "source-over", "source-in" etc. operations, as they're the same as "over" and "in").

Is that a fair summary?

Personally, the "destination-NNN" operations still seems unnecessary to me. I presume you're not suggesting adding "source-in" as a synonym for "in"? I can see that `source-in` is not supported in Inkscape. So the argument that it should match exactly the list from `css-compositing-1` seems to fall straight away. Secondly, given that the channels are called "in" and "in2", I'm not sure that arbitrarily assigning "in" as "src" is worse than arbitrarily assigning either "in" or "in2" to be "src", depending on the operation. Third, the original paper doesn't mention "src" or "destination", and while that terminology is used quite a bit (eg Java and css-compositing-1) it's not universal (eg the wikipedia page). So I'm not sure including those terms in the names of the operations is a hard requirement to help people understand their purpose.

But that's just my opinion - it doesn't matter too much to me, and I'm not an editor of this spec. It would be trivial to update our code to support this. So it's only a weak objection from me.

GitHub Notification of comment by faceless2
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 8 July 2020 15:31:57 UTC