Re: [css-masking] mask-composite, vocabulary, and use cases

On Apr 23, 2014, at 10:00 AM, fantasai <fantasai.lists@inkedblade.net> wrote:

> I'm looking at
> 
>  mask-composite: clear | copy | destination | source-over | destination-over
>                  | source-in | destination-in | source-out | destination-out
>                  | source-atop | destination-atop | xor | lighter
> 
> and the syntax is completely arcane to me. The examples make sense.
> But I'm not a graphics-library person, so I can't relate to the
> vocabulary in use here.
> 
> Do we have to use Porter-Duff vocabulary, or would it be okay to use
> more vernacular English for some of these terms? E.g. "source" and
> "destination" mean nothing to me in terms of CSS objects, so I can't
> tell what they correspond to.
> 
> 
> Also, I'm not seeing why we have all of these things. Sure it would
> be simple to implement because it's just exposing all the values in
> a library, but there is a testing overhead for implementers and,
> more importantly, a cognitive overhead for authors.
> 
> Specifically,
> 
>  * I see no use cases for 'clear', 'copy', or 'destination'.
>    I recommend to remove them.

Yes, they do not provide much value.

> 
>  * I don't understand why we need both source-* and destination-*
>    variations of each operator. Shouldn't reordering be handled
>    by, like, actually reordering the image list?

Yes, that is one way to address this.

With source-in, source-over, source-atop, source-out, xor, lighter and reordering of layers you can address all destination-* modes as well. The main reason why I chose these keywords is the similarity with HTML Canvas where they all are widely used and known. And probably that is one reason why WebKit and Blink use these keywords as well.

We could reduce the modes and the names to over, in, out, atop, xor and lighter (not sure if we even need lighter). This would be consistent with what we do in Filter Effects[1].

> 
> 
>  # A specified compositing operator defines the compositing operation
>  # for the current mask layer with the immediate mask layer below it.
> 
> What happens if there are three layers? This sentence seems to only
> define what happens between two layers in isolation of any other
> layers.
> 
> We deferred layers originally because we weren't sure of how to
> express various ways of combining them. (Even if we weren't going
> to add all of those abilities now, we wanted to be sure we'd be
> able to extend the syntax to handle them all later). I can't see
> from what's in the spec right now if this actually solves the issue.

mask-composite does the same as background-blend-mode.

“A specified compositing operator defines the compositing operation for the current mask layer with the immediate mask layer below it.”

I assume that you see the problem that 3 layers can not be seen isolated with this behavior and you are right. The layer that is behind all other layers is the destination. The next layer is the source and will be drawn on top of the last layer. Both together get the new destination.

I agree that this can be clarified in the spec.

Greetings,
Dirk

[1] http://dev.w3.org/fxtf/filters/#element-attrdef-operator0


> 
> ~fantasai
>

Received on Wednesday, 23 April 2014 09:32:25 UTC