- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 13 Apr 2011 08:55:04 -0700
- 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 'object'. > 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? ~TJ
Received on Wednesday, 13 April 2011 15:55:55 UTC