W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2012

Re: First draft of the blending and compositing spec

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 31 May 2012 21:07:19 +0200
Message-ID: <CAGN7qDA=dqQ+YyTu9j+p+u_DwD-4hrGzm3_yEEv-2Xjs0sJOAQ@mail.gmail.com>
To: Jeremie Patonnier <jeremie.patonnier@gmail.com>
Cc: public-fx@w3.org
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.
'Knockout' is a correct word so it seems that we should go with that

> 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

> 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

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:47 UTC