- From: Rik Cabanier <cabanier@gmail.com>
- Date: Thu, 31 May 2012 21:07:19 +0200
- To: Jeremie Patonnier <jeremie.patonnier@gmail.com>
- Cc: public-fx@w3.org
- Message-ID: <CAGN7qDA=dqQ+YyTu9j+p+u_DwD-4hrGzm3_yEEv-2Xjs0sJOAQ@mail.gmail.com>
Thanks for your feedback! On Thu, May 31, 2012 at 8:20 PM, Jeremie Patonnier < jeremie.patonnier@gmail.com> wrote: > Hello, > > I took the time to read this draft and I wish to thank you to push such a > proposal. As an author, I dream of such feature available in the browser :D > > Here are some thought about the draft. I'm not an expert in compositing > and blending but I felt smart by reading this spec it's amazingly clear and > understandable. Still, I saw things that puzzled me so here are they : > > 4.2 : This part really needs an example > The section has links to the compositing and blending section that describes how they apply there. Nikos just reordered the spec so maybe we can make this more clear. > 4.3 : You say "knockout group" but the property is "knock-out". why are > you using a dash for the property and not for the designation? > We tried to maintain the properties from the existing SVG compositing spec. [1] 'Knockout' is a correct word so it seems that we should go with that instead... > > I found unclear the way each element, inside the knockout group, is > prioritized to determine which element knock-out which other one. It looks > like it depend of the z-index of each element but it's not clearly stated. > It could also be interpreted as dependent of the source code flow. In the > end I presume it depend of the paint order define by each browser. The > "knock-out" property definition does not really help much more here. > Correct, it is in paint order. > > 5 : Even if it's "standard" to use the word destination when we are > talking about Porter Duff stuff, it make the spec harder to read and > understand. IMO it could be easier to chose a word ("backdrop" or > "destination" whatever you prefer) and remain consistent all along the > spec. It will avoid confusion. > > I'm not an expert in compositing so, I do not understand what the 4 pixel > subregions mean and the spec does not really help to understand this. As a > consequence, the example looks wired and it's unclear to me why each pixel > subregion is 25% in the example. I think it needs some clarification (at > least for dumb author like me). > > 5.1.13 : A visual example will be helpful to understand the math > We will work on this. The compositing section is pretty hard, much more so than blending. > > 8.1 : This section make some reference about HTML elements. What about SVG > ones? > It should be identical. Any SVG element should support the CSS keywords. > Is it planed to have something about compositing and blending fill and > stroke independently? > I don't think that that is in the works. Do you believe it is important? > > 8.2.1 : When using the alpha-compositing property, how do we know what the > destination is? Is it the whole background page? > > "Elements will always composite with ‘clip-to-self’ set to ‘true’." this > sentence let think that there is some kind of "clip-to-self" property > available that could be turned off. Is it possible to rephrase this? Maybe > : "Elements will composite as their 'clip-to-self' behavior is always > considered enabled" > > 8.2.3 I should miss something : "For an individual layer ‘isolation’ is > always ‘isolate’." What a "layer" is? > Good point. We should add some clarification. > > 8.2.4: IMO "knock-out: knock-out;" looks a bit awkward. Because it's a > yep/nope property, could we imagine something like this : the "knock-out" > value become the "enabled" value and the "preserve" value become the "none" > value. I really think it make things clearer for author : > > div { knock-out: enabled; } > div ( knock-out: none; } > > I think both really speak for themselves with those values :) > I agree the current wording is a bit strange and I like your suggestion better. > > 8.3.7 : I think there is a need to be able to do that in SVG with the > stroke independent than the fill. Unfortunately, I do not have relevant use > case to provide at the moment. > > I hope it will help > Certainly! Thanks again! > > Best regards > -- > Jeremie > ............................. > Web : http://jeremie.patonnier.net > Twitter : @JeremiePat <http://twitter.com/JeremiePat> > > > 2012/5/10 Rik Cabanier <cabanier@gmail.com> > >> All, >> >> during yesterday FX meeting, some people voiced concern with the lack of >> context of the 'enable-background' [1] and 'isolate' [2] properties. >> I've added some annotations and would like feedback to see if it >> clarifies their usage. >> >> Thanks! >> Rik >> >> [1] >> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#comp-enable-background >> [2] >> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#enable-background >> >> >> On Thu, May 3, 2012 at 10:20 PM, Rik Cabanier <cabanier@gmail.com> wrote: >> >>> All, >>> >>> Nikos and I have created a first pass at a compositing and blending spec >>> and posted it here: >>> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html >>> >>> The section on compositing needs more depth, but I think the blending >>> and specification section are ready for a first review. >>> We will present this during next week's FX face-to-face meeting along >>> with some prototype implementations. >>> >>> Let us know what you think. >>> >>> Thanks! >>> Rik Cabanier >>> Adobe Systems, Inc >>> >> > [1] http://www.w3.org/TR/SVGCompositing/
Received on Thursday, 31 May 2012 19:07:50 UTC