RE: Suggestion - <excludePath>

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:amelia.bellamy.royds@gmail.com] 
Sent: Sunday, June 14, 2015 10:49 AM
To: public-fx@w3.org; www-svg@w3.org
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 <paul.lebeau@gmail.com> 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 <simi@live.no> 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)