- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 May 2025 16:55:17 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <ydaniv> flackr I agree that we should tweak the naive model further<br> <TabAtkins> ChrisL: we ahve an extra issue that says we don't specify hit-testing anywhere. been open since 2018<br> <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<br> <TabAtkins> q+ to talk about the 2018 issue<br> <TabAtkins> ack ChrisL<br> <Rossen5> ack ChrisL<br> <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<br> <TabAtkins> smfr: so it's a compat issue in what can acutally be clicked<br> <TabAtkins> smfr: hit testing is undefined in general. what do we do?<br> <emilio> q+<br> <fantasai> scribe+<br> <Rossen5> ack TabAtkins<br> <Zakim> TabAtkins, you wanted to talk about the 2018 issue<br> <fantasai> TabAtkins: Me and Chris Harrelson chatted about this earlier today, and we want to get this spec written this year<br> <fantasai> TabAtkins: So already on my plan to do this year<br> <fantasai> TabAtkins: don't have an opinion on solving this issue for masks now or put details later into other spec<br> <ChrisL> q+ to mention masks vs clips<br> <fantasai> TabAtkins: but I would like to write up the spec later this year to close the 2018 issue<br> <fantasai> TabAtkins: No comments on this specific issue<br> <fantasai> Rossen5: That would be amazing to have<br> <fantasai> emilio: +1<br> <TabAtkins> emilio: yeah huge +1 to having the spec<br> <TabAtkins> emilio: for this issue, is there a good use-case... what would authors expect?<br> <TabAtkins> emilio: could see both.<br> <TabAtkins> emilio: might want mask decorative, others where you want it honored<br> <Rossen5> ack ChrisL<br> <Zakim> ChrisL, you wanted to mention masks vs clips<br> <TabAtkins> emilio: since there's disagreement i assume we can change, just need to figure out what th emost useful behavior is<br> <noamr> +1<br> <noamr> q+<br> <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<br> <TabAtkins> ChrisL: i think we should definitely define it, and it shoudln't be like a 50% mask value or something<br> <emilio> ack emilio<br> <Rossen5> ack noamr<br> <kizu> q+<br> <lea> what if we have reasonable defaults and a way to override them? (e.g. `hit-testing-area` or something, TBB)<br> <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<br> <TabAtkins> noamr: opacity doesn't affect hit-testing, that's a feature more than a bug<br> <TabAtkins> noamr: so opacity:0 elements are still hit-tested<br> <TabAtkins> noamr: to me mask is more like oapcity than a clip-path<br> <TabAtkins> noamr: so i think we should be consistent<br> <ChrisL> q+<br> <TabAtkins> q+<br> <Rossen5> ack kizu<br> <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<br> <TabAtkins> kizu: sometimes want differnet beahviors<br> <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.<br> <TabAtkins> ChrisL: i agree this shoudl be consistent with opacity. we're entirely silent on the opacity issue fwiw<br> <TabAtkins> ChrisL: at minimum, should we put something into opacity saying "this doesn't affect hit testing"?<br> <TabAtkins> ChrisL: seems there's consensus on that between browsers.<br> <TabAtkins> ChrisL: there's a WPT proposed by ladybird becuase this is untested<br> <Rossen5> ack ChrisL<br> <Rossen5> ack TabAtkins<br> <fantasai> TabAtkins: Agree, now that I remember<br> <fantasai> TabAtkins: binary vs gradient issue<br> <fantasai> TabAtkins: agree we should have mask by default work same as opacity, i.e. no effect on hit testing<br> <fantasai> TabAtkins: Need more exploration of tools; being able to derive a clip-path from a mask would be useful<br> <fantasai> TabAtkins: but that would be a clip-path feature<br> <fantasai> TabAtkins: put some individual details into properties like opacity / mask is a good idea<br> <Rossen5> ack fantasai<br> <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.<br> <TabAtkins> fantasai: can have examples, but not having the centralized list of exhaustive effects.<br> <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<br> <TabAtkins> fantasai: maybe we want to take those as resolutions?<br> <TabAtkins> Rossen5: okay, propose that opacity doesn't affect hit-testing. any objections to that?<br> <TabAtkins> RESOLVED: Specify that 'opacity' has no effect on hit-testing.<br> <TabAtkins> Rossen5: next, propose that 'mask' has no effect on hit-testing<br> <TabAtkins> smfr: this would require behavior changes from chrome and firefox<br> <TabAtkins> RESOLVED: Specify that 'mask' has no effect on hit-testing<br> <TabAtkins> Rossen5: finally, propose to define a way to derive a clip-path from mask<br> <TabAtkins> smfr: Noting that shape-outside also has a way to derive a path from an image, we should be consistent<br> <emeyer> +1 to smfr’s point about being consistent with shape-outside<br> <ydaniv> +1<br> <TabAtkins> smfr: shape-outside defaults to using the opacity of the image. if we have knobs for that, they should work in both places<br> <ChrisL> Agree that both mask opacity and mask luminance should be options<br> <fantasai> See https://www.w3.org/TR/css-shapes-1/#shape-image-threshold-property<br> <fantasai> and https://www.w3.org/TR/css-shapes-1/#shape-outside-property<br> <emeyer> +1 to ChrisL<br> <fantasai> TabAtkins: shapes spec uses alpha channel, defines threshold<br> <fantasai> TabAtkins: we can figure out how to make them consistent<br> <TabAtkins> Rossen5: so figure otu some way to define a clip path from an image, similar to shape outside. details TBD<br> <noamr> btw `view-transitions` spec *does* define hit-testing<br> <TabAtkins> RESOLVED: Define some way for clip-path to derive a path from an image, similar to shape-outside. Details TBD.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11339#issuecomment-2859319458 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 May 2025 16:55:18 UTC