There was a suggestion of four to six years ago on www-svg, that was replete 
with examples, rationale, discussion, and, even, quantifiable buy-in, of why 
clip-path, with a simple inverse flag to mimic mask/exclusion made sense. I 
think the SVG WG agreed it was a good idea.  I don’t know if SVG is relevant to 
discussions of geometry any more, though, since it seems to have been agreed 
that SVG no longer has jurisdiction (Or did I misread something? A distinct, 
but optimistic, possibility)

 

I think SVG WG  sorta said, at the time,  that they’d implement it after some 
nonenumerable set of events. It does make sense, of course, but it starts to 
resemble architecture rather than decoration.  

 

Regards

D

 

From: Amelia Bellamy-Royds [mailto:[email protected]] 
Sent: Sunday, June 14, 2015 10:49 AM
To: [email protected]; [email protected]
Cc: Paul LeBeau; Simen Mangseth
Subject: Re: Suggestion - <excludePath>

 

I would strongly support a reverse clip-path.  I am not sure whether we need a 
new element, though -- another option would be to modify the clip-path property 
to include an in/out parameter.  This could allow the same operation to apply 
to CSS shapes clipping paths.

 

Of course, clipping paths are now the domain of the CSS Masking module, so any 
serious pursuit of new functionality would belong in level 2 of that module.  
For that reason, I've copied this message to the SVG/CSS Effects Task Force's 
public-fx list.

 

Although you can mimick the visual effect or a "reverse clip" with a mask, 
there are limitations: 

- It requires a lot of extra markup (first the clip path, then a mask 
containing a black rectangle that is clipped to the clipPath, on top of a white 
rectangle that is larger than the bounding box)

- Clipping paths can be processed more efficiently by some user agents, because 
they are vector operations instead of pixel operations

- Clipping paths affect pointer-events hit testing, masks don't.  For 
interactive graphics, using a mask can result in non-intuitive behavior.

 

Practical use cases include creating partially overlapping shapes, such as 
interlocking rings.  You need to clip the ring that is drawn on top to *not* 
include part of the ring on the bottom.

 

~ABR

 

On 14 June 2015 at 06:43, Paul LeBeau <[email protected]> wrote:

You can achieve the same result simply with a <mask>.  What would be the 
advantage of this over a mask?

 

Paul

 

 

On 14 June 2015 at 21:17, Simen Mangseth <[email protected]> wrote:

Hello, I don’t know if there has been any discussion on this, and this may have 
been achievable using Vector Effects 1.2 
(http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html)
 
<http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html>
 , but that spec is obsolete, isn’t it? Anyway, this would be a more “native” 
and clean solution.

 

My suggestion is a new element that behaves like <clipPath>, but instead of 
choosing what to include, <excludePath> (or whatever it would be called) would 
specify what should be clipped out from a path.​

 

This is achievable with a compound path, but instead of a complex compound 
path, one could have simple shapes (e.g. a rect or polygon) without having to 
expand into that.

 

Example:

<defs><excludePath id="x">
<path d="">
<circle cx="" cy="" r="">
</excludePath></defs>

<rect exclude="#x">

This would render a rectangle with a path and a circle clipped from the 
rectangle shape, leaving two holes (see attachment excludepath.png). On the 
contrary, a <clipPath> with the same contents would look like attachment 
excludepath_clippingpath.png.

I can think of many scenarios where this would be useful, and both simpler code 
and simpler to use for the developer. 

I can see that it’s possible to define a custom clipping path whose content is 
a compound path with the same result, but this is much harder than just 
defining what to exclude.

If this has already been proposed, or even better, if it’s already in the SVG 
2.0 spec, I’m sorry. Please consider if it’s not, though.

 

Best regards,

Simen Mangseth (web developer)

 

 

Reply via email to