W3C home > Mailing lists > Public > www-svg@w3.org > April 2011

Re: Comments on SVG Compositing

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 13 Apr 2011 08:55:04 -0700
Message-ID: <BANLkTin2=q2t+SX+qnF7GfZgrpQwkku=Ew@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Alex Danilo <alex@abbra.com>, www-svg <www-svg@w3.org>
On Tue, Apr 12, 2011 at 8:11 PM, Rik Cabanier <cabanier@gmail.com> wrote:
> Hi Alex,
> it would be nice to know why it is in SVG. Is there still a need for this
> parameter? What workflows would be broken if 'clip-to-self: canvas' was
> removed?

Earlier, I posted a mapping from comp-ops with 'clip-to-self:object'
to comp-ops with 'clip-to-self:canvas'.  Several of them were
significantly more complex in the 'canvas' case.  The converse is true
as well - several comp-ops under 'clip-to-self:canvas' are
significantly more complex to implement if you're restricted to only

> Personally, I think the PorterDuff blending modes are very confusing. Can't
> we strip them from the spec and replace them with more descriptive one?

I suspect the current names are already roughly as understandable as
they can be without becoming verbose.  The only ones that I ever have
to think about are the *-atop operators, but eventually I'll remember
that they're just a combination of the *-in and *-over ops.

I think they're also basically ubiquitous when talking about
compositing, such that replacing them would likely just cause
confusion.  Are there any examples of graphics programs which use
alternate names for the ops?

Received on Wednesday, 13 April 2011 15:55:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC