Better Support for CSS masks

[jackhp95]

Description

CSS Masks seem fairly neglected. There are cool things like mask-mode which doesn't work on chrome.

Rationale

Support meets an MVP level, but the more advanced features (like mode) are inconsistent, and the prefixed versions only complicate the matter. I'd love to be able to use this one any evergreen browser without needing to test behavior on each browser individually.

Specification

W3C
https://drafts.fxtf.org/css-masking/#the-mask

Tests

Each of these properties are implemented in each browser:
mask-clip
mask-composite
mask-image
mask-mode
mask-origin
mask-position
mask-repeat
mask-size

[jsnkuhn]

Awesome, was looking at this as well.

Web platform tests are here (not sure if border-masking examples are included):
https://wpt.fyi/results/css/css-masking/mask-image?label=experimental&label=master&aligned&view=subtest

• not something that is likely going to be highly voted on lists but when you need it would sure be nice to not have to dance around 10 years of issues

• browsers still use -webkit prefixing

• For mask-composite -webkit used completely different keywords and support for them is also buggy....
  https://css-tricks.com/mask-compositing-the-crash-course/#aa-extending-support

• mask-border should get a mention as well. This is implemented as -webkit-mask-box-image in chromium and safari from an older version of the spec i think?

[gsnedders]

Support meets an MVP level, but the more advanced features (like mode) are inconsistent, and the prefixed versions only complicate the matter. I'd love to be able to use this one any evergreen browser without needing to test behavior on each browser individually.

Hey—when it comes to rational we're primarily interested in web developer and/or end user impact, not the mere existence of bugs (or omitted features); one of the goals of the Interop projects is to focus on things that matter, not just to enumerate every incompatibility out there.

I've opened #151 to try and clarify that in the template, but if you could expand on why you believe this feature is important that would be great!

[jsnkuhn]

Can personally attest that I'd likely use CSS masking more if it just worked as expected. Wanting to pull what's left of my hair out every time I need to use masking is not a great feeling. It's been around 10 years since CSS3 when this was originally implemented, we just shouldn't still have these kind of issues after that long. When implementations are this inconsistent it means more dev time checking on browsers and devices and even if you do that (which many people won't) you still risk missing something which leads to the bad use experience.

Many of the issues, it seems, come down to browser vendors needing to do some name aliasing. So much of it could be a quick win situation.

[ydaniv]

I believe the biggest pain point in masks today is not being able to use inline SVG for masking HTML via CSS, which is, IMHO, the ultimate win of masking with vector graphics.

At Wix we use masks quite extensively but were only able to use the CSS-embedded way, naturally, which is quite a hassle if you're a developer, and not a site generator program.

[jsnkuhn]

So wouldn't this fall under something like element() to use inline SVG as a mask-image then?

[ydaniv]

So wouldn't this fall under something like element() to use inline SVG as a mask-image then?

Not really, it's using SVG's masking capabilities directly for masking by specifying a <mask-source> value, instead of an <image> value.

[progers]

There seems to be web developer interest in the mask-image part of this proposal:

• Usage in Chrome is at 19% of pageloads: https://chromestatus.com/metrics/css/timeline/popularity/289
• The star count of Chromium's mask-image bug is 17 which is reasonably high: https://crbug.com/432153

The other aspects of masking, other than mask-image, seem to have less developer interest, at least using these datasources (popularity and chromium bugs).

So wouldn't this fall under something like element() to use inline SVG as a mask-image then?

Not really, it's using SVG's masking capabilities directly for masking by specifying a <mask-source> value, instead of an <image> value.

I was surprised to see this doesn't work in Chromium or WebKit, and I confirmed there are several failing WPT tests due to this. I filed https://crbug.com/1369996 to track this.

[ydaniv]

Thanks @progers!

The other aspects of masking, other than mask-image, seem to have less developer interest

Some of these may be in part because of partial support of other features, like the above-mentioned.

For example, if <mask-source> is well supported, having full support for mask-type/mask-mode may also be essential.

[gsnedders]

Am I right in thinking we're roughly looking at path:/css/css-masking not clip here? It seems like basically all these tests are about mask-image, and not the other aspects of masking?

[jsnkuhn]

The issues as described by caniuse is:

Partial support in WebKit/Blink browsers refers to supporting the mask-image and mask-box-image properties, but lacking support for other parts of the spec.

the issues to a certain degree come down to (if i remember correctly) there being a complete redesign of the spec at one point? And some of the implementation getting updated and other not.

Ana Tudor did a good job breaking down the issues with mask-compositing that also gets at some of the larger issues here: https://css-tricks.com/mask-compositing-the-crash-course/#aa-extending-support

[ydaniv]

@gsnedders there's also this old post: https://lab.iamvdo.me/css-svg-masks/ - might be a bit dated, but roughly covers some of the main missing features.
And of course this old one from Yoksel: https://codepen.io/yoksel/full/GRodvp - mostly you can see the "SVG mask for HTML elements" one which is only supported on Gecko.

[jsnkuhn]

The Chrome bug about all of this: https://bugs.chromium.org/p/chromium/issues/detail?id=432153

For clarity:

What I'm referring to here is yes mask-image. It is listed as "7. Positioned Masks" in the spec:
https://drafts.fxtf.org/css-masking/#positioned-masks

The other thing being mentioned is "9. SVG Mask Sources" Referencing an inline SVG mask element as a mask-image

mask-image: url(#mask2);

https://drafts.fxtf.org/css-masking/#svg-masks

[jensimmons]

We may need to debate exactly which types of "mask" is being proposed in this issue. But for CSS, there are quite a few properties that were originally -webkit-mask-*. And interoperability would be improved by encouraging all browsers to support the unprefixed versions, and to squash any interop bugs.

The Web Almanac shows these are some of the most-tested properties listed in feature queries, taking 5th through 13th place:

[jsnkuhn]

probably worth noting that this is mostly just a Chromium issue at the moment? Firefox has been good on this since 2017 and Safari unprefixed earlier this year.

https://caniuse.com/?search=mask

[jsnkuhn]

I wonder if this proposal is only one example of a larger issue. Maybe the larger proposal should just be a large scale CSS3 clean up. A big part of which would be an effort to un-prefix CSS3 properties that have fallen under the radar?

Things like mask, box-decoration-break, background-clip: text;, etc

This chart is not super user friendly (maybe there's a better one out there) but gets the general idea of what the current-ish prefixing situation is:
https://css-tricks.com/is-vendor-prefixing-dead/#aa-prefixing-in-2021

I guess an investigation into how many of these prefixes can just be straight up un-prefixed would be needed. It seems in some cases support for the -webkit prefix in particular would need to be continued (since some of these things have been siting untouched for 8-ish years) as a "CSS3" version but un-prefixed could be looked at as "CSS4" and beyond?

[foolip]

There were some mentions of masks in State of CSS 2022, although not enough to make the top list in #248. 11 mentions is ~0.5% of the 1995 responses. Most were just "masks" or "CSS masking", but one comment mentioned mask-mode + mask-composite and another mentioned image-mask, and must have meant mask-image.

[foolip]

In the MDN short survey on CSS & HTML, "CSS mask property (mask-image, mask-mode, etc.)" was selected by ~16% of survey takers, putting it in the middle third of the 20 options. (There is some uncertainty as with any survey data.)

[thebabydino]

Chrome bug for mask: url(#mask) (referencing an inline SVG mask) https://bugs.chromium.org/p/chromium/issues/detail?id=1369996

[foolip]

Thank you for proposing CSS masks for inclusion in Interop 2023.

We are pleased to let you know that this proposal was accepted as the Masking focus area. You can follow the progress of this Focus Area on the Interop 2023 dashboard.

For an overview of our process, see the proposal selection summary. Thank you for contributing to Interop 2023!

Posted on behalf of the Interop team.