- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 23 Apr 2014 01:00:58 -0700
- To: "www-style@w3.org" <www-style@w3.org>
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. * 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? # 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. ~fantasai
Received on Wednesday, 23 April 2014 08:01:27 UTC