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.
[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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 May 2012 19:07:52 GMT