W3C home > Mailing lists > Public > www-style@w3.org > December 2013

Re: [css-compositing] Request to move Compositing and Blending spec to CR

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 12 Dec 2013 21:36:04 -0800
Message-ID: <CAGN7qDCtazLfc6+j7Jirn0wVOKU7iaU_f6J_42EPr=NjaTQAfw@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: James Robinson <jamesr@google.com>, www-svg <www-svg@w3.org>, www-style list <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>
On Thu, Dec 12, 2013 at 9:24 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Fri, Dec 13, 2013 at 4:50 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>> On Thu, Dec 12, 2013 at 7:29 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>>
>>> On Fri, Dec 13, 2013 at 4:13 PM, Rik Cabanier <cabanier@gmail.com>wrote:
>>>
>>>> No, the spec should not refer to blogs. Also, this is not 'potentially'
>>>> useful as the absence of this description has caused confusion in the past.
>>>>
>>>
>>> I agree with James. Having the spec define behavior that is never used
>>> by any Web feature is very confusing.
>>>
>>> Section 4 is not really needed at all since the HTML5 canvas spec
>>> defines the canvas compositing behavior.
>>>
>>
>> Can you point where that is defined in the canvas spec?
>>
>
>
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-model
>

yes, that doesn't describe how you do the compositing. is it
'clip-to-self', or the bounds of the drawing bitmap, or infinite bounds?


>
>>
>>> If you want the Compositing and Blending spec to define new compositing
>>> modes for canvas, then define a list of operators that the HTML canvas spec
>>> can refer to, but don't define globalCompositeOperation here. Don't even
>>> mention canvas here.
>>>
>>
>> It's needed because the canvas spec doesn't say anything about how
>> compositing should happen.
>> I don't want to break canvas by removing this.
>>
>
> All you need to define for canvas is the per-pixel compositing behavior.
>

No. What if there are no pixels (ie with 'clear'), you'd still want to
clear that area.


>
>
>>
>>  Another very important reason is also that if this property/behavior is
>>>> included in the spec, the W3C patent policy will apply.
>>>>
>>>
>>> Describing something in a W3C spec that is not actually used by any
>>> features in that spec, just so we can get the patent policy to apply to it,
>>> borders on bad faith.
>>>
>>
>> It *is* being used.
>>
>
> Where? Pointing to "clip to self" saying "don't do this" does not
> constitute a use.
>
>
>> Also, future spec might want to refer to this. Another example is the
>> proposal for masking in canvas which has an option for clip-to-self. It
>> would be unfortunate that we would have to rev the compositing spec to
>> progress canvas or filters.
>>
>
> If a future spec will use it, the future spec can define it.
>

No, we want to avoid defining the same thing over and over again. Filters,
blending, canvas, masking all need to build on a common model.
This is why we did the compositing and blending spec in the first place:
harmonize the different specs.


> Any use of clip-to-self will have to define what the clip-to-self region
> is for each drawing operation, which is not necessarily easy to do. It
> certainly shouldn't be done by saying the clip-to-self region is where
> alpha > 0, for the reasons James pointed out near the beginning of this
> thread.
>

That is not what the spec says. clip-to-self=true works on the shape of the
element which is independent of its alpha.
Received on Friday, 13 December 2013 05:36:32 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:17 UTC