[css-masking] Impact of masks on hit-testing needs to be specified

[smfr]

Currently, CSS Masking says nothing about whether masks impact hit-testing (i.e. if clicks on the masked-out part of the content are treated as a click on the element).

Chrome and Firefox do consult the mask for hit-testing; WebKit does not. Test:
https://codepen.io/therealpaulplay/pen/wBwGdXX

This was reported as a bug in WebKit.

CSS has historically shied away from specifying hit-testing, but I think this one is important. Also of note is that the spec does talk about the impact of clip-path on hit-testing.

[schenney-chromium]

There is this in the rendering section:

• The mask-image property has no effect on the geometry or hit-testing of any element’s CSS boxes.

It seems that Chrome and Firefox are wrong, though as a user I would expect their behavior.

[ydaniv]

As a user I'm actually surprised by that. I thought all engines follow that part of the spec and ignore the mask for hit-testing.

[svgeesus]

Related:

• CSS needs to define hit testing #2325

[css-meeting-bot]

The CSS Working Group just discussed [css-masking] Impact of masks on hit-testing needs to be specified, and agreed to the following:

• RESOLVED: Specify that 'opacity' has no effect on hit-testing.
• RESOLVED: Specify that 'mask' has no effect on hit-testing
• RESOLVED: Define some way for clip-path to derive a path from an image, similar to shape-outside. Details TBD.

The full IRC log of that discussion

<ydaniv> flackr I agree that we should tweak the naive model further
<TabAtkins> ChrisL: we ahve an extra issue that says we don't specify hit-testing anywhere. been open since 2018
<TabAtkins> ChrisL: this is one example, there are other things taht are unspecified. might affect whether we want to sprinkle details around or collect them into one spec
<TabAtkins> q+ to talk about the 2018 issue
<TabAtkins> ack ChrisL
<Rossen5> ack ChrisL
<TabAtkins> smfr: hit testing is undefined, with masks there's different behavior. webkit follows the current spec and ignores the mask, chrome respects the mask
<TabAtkins> smfr: so it's a compat issue in what can acutally be clicked
<TabAtkins> smfr: hit testing is undefined in general. what do we do?
<emilio> q+
<fantasai> scribe+
<Rossen5> ack TabAtkins
<Zakim> TabAtkins, you wanted to talk about the 2018 issue
<fantasai> TabAtkins: Me and Chris Harrelson chatted about this earlier today, and we want to get this spec written this year
<fantasai> TabAtkins: So already on my plan to do this year
<fantasai> TabAtkins: don't have an opinion on solving this issue for masks now or put details later into other spec
<ChrisL> q+ to mention masks vs clips
<fantasai> TabAtkins: but I would like to write up the spec later this year to close the 2018 issue
<fantasai> TabAtkins: No comments on this specific issue
<fantasai> Rossen5: That would be amazing to have
<fantasai> emilio: +1
<TabAtkins> emilio: yeah huge +1 to having the spec
<TabAtkins> emilio: for this issue, is there a good use-case... what would authors expect?
<TabAtkins> emilio: could see both.
<TabAtkins> emilio: might want mask decorative, others where you want it honored
<Rossen5> ack ChrisL
<Zakim> ChrisL, you wanted to mention masks vs clips
<TabAtkins> emilio: since there's disagreement i assume we can change, just need to figure out what th emost useful behavior is
<noamr> +1
<noamr> q+
<TabAtkins> ChrisL: coming back to SVG, where this came from, we distinguish between "clip" (inside vs outside, a binary) and "mask" (a gradient from fully opaque to transparent). people ask about 0/transparent
<TabAtkins> ChrisL: i think we should definitely define it, and it shoudln't be like a 50% mask value or something
<emilio> ack emilio
<Rossen5> ack noamr
<kizu> q+
<lea> what if we have reasonable defaults and a way to override them? (e.g. `hit-testing-area` or something, TBB)
<TabAtkins> noamr: i'm not aware fo the history, but i'd say it needs to be derived from opacity - whatever we decide for opacity we shoudl use here
<TabAtkins> noamr: opacity doesn't affect hit-testing, that's a feature more than a bug
<TabAtkins> noamr: so opacity:0 elements are still hit-tested
<TabAtkins> noamr: to me mask is more like oapcity than a clip-path
<TabAtkins> noamr: so i think we should be consistent
<ChrisL> q+
<TabAtkins> q+
<Rossen5> ack kizu
<TabAtkins> kizu: this might be covered by the future spec, but both for this an dcases like borde-rradius, would be nice to have a proeprty controlling the hit test
<TabAtkins> kizu: sometimes want differnet beahviors
<TabAtkins> kizu: years ago when browsers changed the hit-test for border-radius, i was annoyed i couldn't achieve the old beahvior without adding a wrapper.
<TabAtkins> ChrisL: i agree this shoudl be consistent with opacity. we're entirely silent on the opacity issue fwiw
<TabAtkins> ChrisL: at minimum, should we put something into opacity saying "this doesn't affect hit testing"?
<TabAtkins> ChrisL: seems there's consensus on that between browsers.
<TabAtkins> ChrisL: there's a WPT proposed by ladybird becuase this is untested
<Rossen5> ack ChrisL
<Rossen5> ack TabAtkins
<fantasai> TabAtkins: Agree, now that I remember
<fantasai> TabAtkins: binary vs gradient issue
<fantasai> TabAtkins: agree we should have mask by default work same as opacity, i.e. no effect on hit testing
<fantasai> TabAtkins: Need more exploration of tools; being able to derive a clip-path from a mask would be useful
<fantasai> TabAtkins: but that would be a clip-path feature
<fantasai> TabAtkins: put some individual details into properties like opacity / mask is a good idea
<Rossen5> ack fantasai
<TabAtkins> fantasai: i think the hit testing spec should provide a framework for defining how it works fundamentally/generally, but specific properties should define how they work. that's what we do for border-radius and clip-path currently. having it all centralized makes it more likely we'll forget stuff.
<TabAtkins> fantasai: can have examples, but not having the centralized list of exhaustive effects.
<TabAtkins> fantasai: so it seems there's a proposal to define opacity as not affecting hit-testing, a proposal to define mask as not defining hit-testing, and a proposal to derive clip-path from a mask
<TabAtkins> fantasai: maybe we want to take those as resolutions?
<TabAtkins> Rossen5: okay, propose that opacity doesn't affect hit-testing. any objections to that?
<TabAtkins> RESOLVED: Specify that 'opacity' has no effect on hit-testing.
<TabAtkins> Rossen5: next, propose that 'mask' has no effect on hit-testing
<TabAtkins> smfr: this would require behavior changes from chrome and firefox
<TabAtkins> RESOLVED: Specify that 'mask' has no effect on hit-testing
<TabAtkins> Rossen5: finally, propose to define a way to derive a clip-path from mask
<TabAtkins> smfr: Noting that shape-outside also has a way to derive a path from an image, we should be consistent
<emeyer> +1 to smfr’s point about being consistent with shape-outside
<ydaniv> +1
<TabAtkins> smfr: shape-outside defaults to using the opacity of the image. if we have knobs for that, they should work in both places
<ChrisL> Agree that both mask opacity and mask luminance should be options
<fantasai> See https://www.w3.org/TR/css-shapes-1/#shape-image-threshold-property
<fantasai> and https://www.w3.org/TR/css-shapes-1/#shape-outside-property
<emeyer> +1 to ChrisL
<fantasai> TabAtkins: shapes spec uses alpha channel, defines threshold
<fantasai> TabAtkins: we can figure out how to make them consistent
<TabAtkins> Rossen5: so figure otu some way to define a clip path from an image, similar to shape outside. details TBD
<noamr> btw `view-transitions` spec *does* define hit-testing
<TabAtkins> RESOLVED: Define some way for clip-path to derive a path from an image, similar to shape-outside. Details TBD.