- From: Rachel Nabors <rachelnabors@gmail.com>
- Date: Sun, 14 Jun 2015 23:53:59 +0000
- 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>
- Message-ID: <CAPFA0t1gxqYC+W_Pfr6m_KY20wdjxkQOSDoP=ZHTrceZ4EZu1Q@mail.gmail.com>
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