W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2012

Re: Mask property syntax and CSS <image>

From: Rik Cabanier <cabanier@gmail.com>
Date: Sun, 5 Aug 2012 21:44:54 -0700
Message-ID: <CAGN7qDB6VGgD8xNMnY8_9Qu9YhPjPP35HAq5unT0DZb9aU8Oig@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: Brian Birtles <bbirtles@mozilla.com>, "public-fx@w3.org" <public-fx@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 6 August 2012 04:45:23 GMT