- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 26 Jul 2012 10:05:53 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: www-style list <www-style@w3.org>
- Message-ID: <CAGN7qDCyQUiA6kkKwF2Ue7H+i6UrRyzPfdsK2VK2ZpEnwhnUHg@mail.gmail.com>
On Wed, Jul 25, 2012 at 9:41 PM, Maciej Stachowiak <mjs@apple.com> wrote: > > On Jul 21, 2012, at 1:17 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > Hi Maciej, > > > On Sat, Jul 21, 2012 at 11:21 AM, Maciej Stachowiak <mjs@apple.com> wrote: > >> >> How do 'alpha-compositing' and 'blend-mode' interact if you have set >> both? I was unable to determine this from the spec. Does it actually make >> sense to specify both to non-default values at the same time? I was unable >> to understand what their relationship is supposed to be. >> > > blending and compositing are 2 separate operations. > Blending takes the foreground and background pixels, mixes them together > and produces a new image. > This image is then composited with whatever compositing mode you have set. > > The 2 operations do not interact. > > > They are both defined in terms of a function, a source color, a background > color, and a result color. What happens when both are specified? Do you > blend first, and then use that result to composite? It sounds like that's > what you are saying, but I don't think that is spelled out in the spec. > > This needs to be clearly spelled out in the spec. Please consider this a > comment on the spec. > >From the spec: Blending is the aspect of compositing that calculates the mixing of colors where the source element and backdrop overlap. Blending takes the colors of the source element and mixes them with the backdrop<https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#backdrop> in areas where the source element and backdrop overlap. Conceptually, the colors in the source element are blended in place with the backdrop. After blending, the modified source element is composited with the backdrop. [1] > > > Most implementations (including Apple's core graphics and Adobe PDF) > always assume 'src-over' after blending. > > > Is that what the spec will require? > yes, from the spec: The description of the ‘alpha-compositing’ property is as follows: ‘alpha-compositing’ *Value:* clear | src | dst | src-over | dst-over | src-in | dst-in | src-out | dst-out | src-atop | dst-atop | xor | plus * Initial:* *src-over**Applies to:* All elements. In SVG, it applies to svg, g, use, image, path, rect, circle, ellipse, line, polyline, polygon, text, tspan, and marker. *Inherited:* no *Percentages:* N/A*Media:* visual *Animatable:* yes > >> Some other comments: >> >> - The property values for the 'alpha-compositing' operator are >> inconsistent with the values for HTML5 Canvas: < >> http://www.w3.org/TR/2dcontext/#dom-context-2d-globalcompositeoperation>. >> I suggest making them match if there is no compelling advantage to the new >> names, otherwise this will be needlessly confusing to authors. >> > > That's correct. We reused the names that were in the SVG compositing spec. > It think we can make them longer, but I'd prefer to keep 'plus' instead of > 'lighter' because 'lighter' sounds too much like the 'lighten' blend mode. > 'clear' also seems absent in the canvas spec... > > > I think consistency with the HTML5 Canvas spec outweighs consistency with > the old SVG compositing spec (which I don't think was ever implemented in > browsers). I also think consistency outweighs fine-tuning the names to be > more clear. Adding a new mode is fine, but I'd suggest proposing it for > canvas as well. I think it would be confusing for authors if the names are > different. Let's not make the newly introduced names different. > I will update the spec so the 'source' and 'destination' are spelled out. I've made a proposal to extend canvas with the blending operators and I could add the missing compositing modes to it. It's unfortunate that 'plus' was renamed to 'lighten'. I'm a bit hesitant to change it... > > >> - Consider renaming 'alpha-compositing' to 'composite-operator' for >> similar reasons. >> >> > 'alpha-compositing' was a suggestion from Chris Marrin and people on the > mailing list liked it so I added it to the spec. (It was originally > 'comp-op') > > > I think alpha-compositing is a bad name because: > > 1) "alpha" is redundant, we don't have any non-alpha compositing. > There was a discussion last year on this [3]. Blending can be seen as color-compositing so we chose the alpha-compositing to make it clear that it is based upon the alpha of the pixels and not the color. > 2) "alpha-compositing" or "compositing" is ambiguous without a value - > does this turn compositing on/off, does it specify the alpha, or does it > specify the operator? It's not clear from the name. "composite-operator" or > "compositing-operator" are not ambiguous in this way. > I'm not sure what you mean. These are CSS so they have a default value which is listed in the spec [2] > 3) Consistency with HTML5 Canvas seems valuable to me, more so than > crafting the most aesthetically pleasing name. > I agree. If the 'lighten' name can't be changed in Canvas (or 'plus' added), I will be happy to update the spec. > > Is there a way for me to make sure the CSS WG considers these spec > comments? Should I file bugs? > The spec is not a WD yet so I will make the changes. Thanks! Rik 1: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blending 2: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#alpha-compositing 3: http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0109.html
Received on Thursday, 26 July 2012 17:06:27 UTC