W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css-masking] 'mask' with resource and image references (was: [css4-images] support for SVG Paint Servers without element())

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 7 Nov 2012 10:43:16 -0800
Message-ID: <CAAWBYDAf=Fwo63Ts4HzNY64U5A7D8939pg_teR8sSE2Jafc3=w@mail.gmail.com>
To: Dirk Schulze <dschulze@adobe.com>
Cc: "robert@ocallahan.org" <robert@ocallahan.org>, "www-style@w3.org list" <www-style@w3.org>
On Wed, Nov 7, 2012 at 6:56 AM, Dirk Schulze <dschulze@adobe.com> wrote:
> On Nov 7, 2012, at 4:24 AM, Robert O'Callahan <robert@ocallahan.org> wrote:
>> On Wed, Nov 7, 2012 at 3:14 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>>> On Nov 6, 2012, at 5:06 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
>>> > Just remove the <mask-source> alternative. "mask:url(foo.svg#abc)" gets parsed to a mask-image value of url(foo.svg#abc). When rendering, since the mask-image value is a url() with a fragment identifier, it should be treated as a reference to an SVG <mask>.
>>> This is difficult because of multiple reasons:
>>> <mask-source> does not only allow URLs, but also the 'child' keyword and the child selector.
>> So add those separately as alternatives for mask-image.
> That doesn't sound right for me. 'mask-image' should get CSS images IMO. Both, the keyword and the selector are just other ways to reference <mask> elements.

No, that's actually required.  I hadn't reviewed this carefully
before, but roc is right.

The 'mask' property, as currently written, does not work.  'mask' is a
shorthand, which means that it must *fully* expand into
sub-properties.  Any behavior expressible via the shorthand *must* be
expressible by an appropriate combination of the longhands as well,
because the shorthand *disappears entirely* in the cascade.  It's
more-or-less just a macro for the longhands.

So, 'mask-image' needs to have its grammar revised to take this into
account, so that it can take mask references as well.  Alternately, we
need an additional property which takes a mask ref, and overrides
mask-image if specified (like list-style-type and list-style-image -
the latter wins if it's not none).

>>> The image on the 'mask-image' property gets clipped by the 'mask-clip' property, repeated by the 'mask-repeat' property and positioned by the 'mask-origin' property. All these properties do not apply on <mask> references.
>> That's not a problem as far as I can tell. When mask-image refers to a <mask>, mask-repeat, mask-clip and mask-origin simply won't apply.
> There is more then that. You need to take care of cross fading, transitions and animations. Cross fading is already supported in WebKit and will be defined in CSS4 Images or a following specification. This would not work with SVG masks. Again, in WebKit 'mask-image' and SVG masks are separate code paths that can't easily be combined.

That's not problematic.  Cross-fading is defined for *images*.  If the
value is instead a <mask> (which can be determined at parse time, via
roc's rules), it doesn't cross-fade.  Simple.

The fact that they're separate code paths is irrelevant.  The CSS
syntax used to specify the functionality is on a different layer.

>>> A combination of images and mask references for the 'mask-image' property is not defined by the model for 'mask-image'. It is unclear how both can be combined and I actually don't think that this is a very good idea. Both 'mask-image' and <mask> have there use cases independent of each other.
>> We need to define what happens if you combine images and mask references, but we can define something simple like "if any of the values in a mask-image list is an image, all the values that are not images are ignored (treated as not masking anything)".
> I don't think we should go this way. 'mask-image' already implies that it takes an image. <mask> definitely is not an image.

Just define that 'mask-image' takes either a single <mask>, or a list
of <image>s.  You can then do normal syntax checking and reject mixing
things together at parse time.

Received on Wednesday, 7 November 2012 18:44:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC