- From: Rik Cabanier <cabanier@gmail.com>
- Date: Sun, 5 Aug 2012 21:44:54 -0700
- To: Dirk Schulze <dschulze@adobe.com>
- Cc: Brian Birtles <bbirtles@mozilla.com>, "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CAGN7qDB6VGgD8xNMnY8_9Qu9YhPjPP35HAq5unT0DZb9aU8Oig@mail.gmail.com>
Isn't the new mask used as follows: <rect id ="r_1...> <rect mask="element(#r_1)"> or as CSS (?): <rect id ="r_1...> <rect style = "mask: element(#r_1);"> If so, I think it's compatible with the css4 element() notation. In fact, I think we want the exact same wording and behavior as that element. (Including the wording on compositing over a transparent backdrop) Rik On Sun, Aug 5, 2012 at 9:01 PM, Dirk Schulze <dschulze@adobe.com> wrote: > > On Aug 5, 2012, at 8:52 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > > > > > On Sun, Aug 5, 2012 at 7:25 PM, Brian Birtles <bbirtles@mozilla.com> > wrote: > > Hi, > > > > I'm just following up on some concerns with recent changes to SVG mask > syntax.[1] > > > > Firstly, it looks like we'll replace the element() syntax with select() > to avoid clashes with CSS Images.[2] > > > > Why? It seems like we want the exact same functionality. > > > I might be wrong, but I think we wanted to use element() to select a child > mask element. In this case it is a selection, while element() creates a > buffer and draws the referenced content in it. Of course it can be useful > as a mask as well. And when we support the Image element (like Brian > suggests), it is also possible to use element(). But the functionality > differs from the actual use case we had in mind: selecting a mask element > for masking. > > Greetings, > Dirk > > > > > Secondly, ideally we'd like to make the mask property take a CSS <image> > value. However, that introduces the issue of how to differentiate between > the following: > > > > mask: url(#maskElem); // Existing usage. Process as an SVG <mask>. > > mask: url(#imgElem); // Valid CSS <image>. > > > > Ideally we'd like to be able to differentiate between special SVG mask > element behaviour and regular CSS <image> processing at the parser level. > > > > Some <image> values are easy, e.g. image(), element(), linear-gradient() > etc. we can just treat as images (if nested <url> components refer to masks > too bad?) > > > > For url() values, we could use the presence of a #hash-reference to > branch? > > > > mask: url(abc.png); // Treat as image > > mask: url(abc.svg); // Treat as image (-webkit-mask does this) > > mask: url(#elem); // SVG mask processing > > mask: url(abc.svg#elem); // SVG mask processing > > > > I think you need to use image() if you want to use media fragment > identifiers so we'd be ok there? > > > > Also, what about url(#imgElem)? Is that valid? To refer to arbitrary > HTML content and apply usual CSS <image> processing? > > > > Once you hit the SVG mask processing branch I think we want to do > target-specific processing (i.e. <mask> behaves differently to > <linearGradient> behaves differently to <circle>) but maybe that's ok? > > > > Note that one implication of branching on # is that 'url(abc.svg)' will > be treated the same as 'url(abc.png)', i.e. will get treated as an alpha > mask. We won't be able to implement the 'vectors are luminance, rasters are > alpha' strategy floated on www-svg recently.[3] It probably pushes us more > towards 'default is alpha everywhere except <mask>' so you get consistent > behaviour between: > > > > mask: url(circle.svg); // alpha > > mask: url(#circleElem); // alpha > > > > and, likewise, > > > > mask: linear-gradient(...); // -webkit-mask makes this alpha > > mask: url(#gradientElem); // alpha > > > > Can anyone help? > > > > Thanks! > > > > Best regards, > > > > Brian Birtles > > > > [1] https://svgwg.org/svg2-draft/masking.html#mask-property > > [2] http://dev.w3.org/csswg/css4-images/ > > [3] http://lists.w3.org/Archives/Public/www-svg/2012Jul/0134.html > > > > > >
Received on Monday, 6 August 2012 04:45:23 UTC