- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 11 Dec 2013 21:45:32 -0800
- To: James Robinson <jamesr@google.com>
- Cc: www-svg <www-svg@w3.org>, www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAGN7qDAOQOj7t___roRCDsgjrKrg8nax1MwTGjNJfOPmPke7_g@mail.gmail.com>
Also note the title: Compositing and Blending Level 1 and not: *CSS* Compositing and Blending Level 1 >From the spec: The (archived <http://lists.w3.org/Archives/Public/public-fx/>) public mailing list public-fx@w3.org (see instructions<http://www.w3.org/Mail/Request>) is preferred for discussion of this specification. When sending e-mail, please put the text “compositing-1” in the subject, preferably like this: “[ compositing-1] *…summary of comment…*” On Wed, Dec 11, 2013 at 9:41 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > > On Wed, Dec 11, 2013 at 9:28 PM, James Robinson <jamesr@google.com> wrote: > >> Why are you trying to define how canvas works in a CSS spec? Canvas is >> defined as part of HTML, including how the compositing operations are >> applied. The text here is completely unhelpful. >> > This is not a 'CSS' spec; this is done through the fx working group which > works on graphical operators. > Some are CSS, others apply to canvas. The Web animation spec is purely > JavaScript but will eventually define CSS properties as well. > > HTML refers to this spec to define compositing; the same is done in the > filters spec. I don't understand what you think that that is not helpful > (unless you think compositing should be redefined in every spec) > > >> On Dec 11, 2013 7:16 PM, "Rik Cabanier" <cabanier@gmail.com> wrote: >> >>> >>> >>> >>> On Wed, Dec 11, 2013 at 6:57 PM, James Robinson <jamesr@google.com>wrote: >>> >>>> >>>> On Wed, Dec 11, 2013 at 6:44 PM, Rik Cabanier <cabanier@gmail.com>wrote: >>>> >>>>> >>>>> >>>>>> >>>>>> Canvas is defined in HTML. Having text here to define a behavior >>>>>> that canvas does not use is just confusing with no upside. >>>>>> >>>>> >>>>> No, canvas refers to the compositing spec for the 'globalComposite' >>>>> operator [1]: >>>>> >>>>> The globalCompositeOperation attribute sets the current composition >>>>> operator, which controls how shapes and images are drawn onto the scratch >>>>> bitmap<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#scratch-bitmap>, >>>>> once they have had globalAlpha<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-globalalpha> and >>>>> the current transformation matrix applied. The possible values are those >>>>> defined in the Compositing and Blending specification. [COMPOSITE]<http://www.whatwg.org/specs/web-apps/current-work/multipage/references.html#refsCOMPOSITE> >>>>> >>>>> >>>>> Do you think the canvas spec should be more clear that compositing is >>>>> defined in the "Compositing and Blending specification"? >>>>> >>>> >>>> The paragraph in question - "9.2.3. Clip to self behavior" - describes >>>> a behavior that is not used by canvas, or (from what you've said) by >>>> anything in the Compositing and Blending spec. What value does it have >>>> other than creating confusion, in that case? >>>> >>> >>> Section 5-10 define a generic model for blending and compositing. >>> The normative section defines a subsection of that model. Hopefully we >>> can implement the whole model over the coming years. >>> By defining it this way, it should be more clear to an implementor how >>> things are supposed to be work. >>> For example, the problems that you mentioned earlier: >>> >>> Firefox applied the compositing operation to the entire canvas, >>> respecting the current clip, and WebKit applied the compositing operation >>> only to the "bounds" of the draw. >>> >>> would not have happened if there had been a definition like you find in >>> the current spec: >>> http://dev.w3.org/fxtf/compositing-1/#groupcompositingcliptoself >>> >>> I don't really see a way to define how compositing works in canvas >>> without describing the clip-to-self behavior somehow... >>> >> >
Received on Thursday, 12 December 2013 05:46:03 UTC