- From: Dirk Schulze <vbs85@gmx.de>
- Date: Sun, 18 Apr 2010 15:06:17 +0200
- To: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
- Cc: robert@ocallahan.org, Erik Dahlstrom <ed@opera.com>, www-svg@w3.org
I don't want to distract from filters. But another point, that I don't understand in this discussion about margin, is masking. Doesn't masking have the same problem? <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> <defs> <mask id="mask"> <circle cx="50" cy="50" r="50" fill="white"/> </mask> </defs> <line x1="0" y1="50" x2="100" y2="50" stroke-width="100" stroke="green" mask="url(#mask)"/> <rect x="0" y="0" width="100" height="100" fill="green" mask="url(#mask)" transform="translate(100,0)"/> </svg> We only see one green circle, because the boundingBox of the line has a height of zero. So why fix this "issue" on filters with margin, but not on masking? Dirk Am Sonntag, den 18.04.2010, 14:25 +0200 schrieb Jasper van de Gronde: > Dirk Schulze wrote: > >> More fundamentally, the filter effects region is not MEANT to be a > >> general clipping facility, and is frankly a pretty poor substitute. > > Rob wrote a mail about the unclear description of clipping and filter > > effects in the Specs some time ago. On WebKit we interpret it the same > > way like for filterRegions. That means we use subRegions as clipping > > areas. IIRC batik and Opera do the same. > > Emphasis was intended to be on "general (clipping facility)". > > Put differently: as far as I can tell anything that can be done with a > filter effects region can also be done a different (often more generally > useful) way. Being able to ignore the option reduces complexity of > implementations (or keeps it more or less the same) and confusion. It is > not uncommon to get bug reports that boil down to some oddity caused by > having a filter effects region specified. > > Now, completely removing the option at this point might be troublesome, > but we could try working towards that. > > (And indeed, the filterRes property would be another candidate, although > I'd have less problems with simply ignoring it.)
Received on Sunday, 18 April 2010 13:06:52 UTC