W3C home > Mailing lists > Public > www-svg@w3.org > June 2015

Re: Suggestion - <excludePath>

From: Rachel Nabors <rachelnabors@gmail.com>
Date: Sun, 14 Jun 2015 23:53:59 +0000
Message-ID: <CAPFA0t1gxqYC+W_Pfr6m_KY20wdjxkQOSDoP=ZHTrceZ4EZu1Q@mail.gmail.com>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>, "public-fx@w3.org" <public-fx@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
Cc: Paul LeBeau <paul.lebeau@gmail.com>, Simen Mangseth <simi@live.no>
All of Amelia's reasoning: this.

Many times I've encountered just such problems in my own interactive work
and heard others lamenting them: excessive markup, messed up pointer events..

Animation-direction has a "reverse" option. Is there a reason it would be
bad for clip-path to have one as well?

On Sun, Jun 14, 2015 at 7:49 AM Amelia Bellamy-Royds <
amelia.bellamy.royds@gmail.com> wrote:

> 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)
Received on Monday, 15 June 2015 00:55:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:01 UTC