16:01:12 <RRSAgent> RRSAgent has joined #css
16:01:16 <RRSAgent> logging to https://www.w3.org/2025/05/07-css-irc
16:01:16 <Zakim> RRSAgent, make logs Public
16:01:17 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:01:19 <lea> lea has joined #css
16:01:20 <jbreiland> jbreiland has joined #css
16:01:22 <TabAtkins> ScribeNick: TabAtkins
16:01:22 <emeyer> emeyer has joined #css
16:01:26 <Rossen5> present+
16:01:31 <jensimmons> jensimmons has joined #css
16:01:37 <miriam> present+
16:01:38 <jensimmons> present+
16:01:39 <dandclark> present+
16:01:41 <smfr> smfr has joined #css
16:01:46 <emilio> present+
16:01:47 <emeyer> present+
16:01:54 <ydaniv> present+
16:01:55 <JoshT> JoshT has joined #css
16:02:01 <ChrisL> present+
16:02:02 <weinig> present+
16:02:05 <DavidA> present+
16:02:14 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11698#issuecomment-2836725870
16:02:14 <github-bot> Topic: [css-color-hdr] New values for dynamic-range-limit property
16:02:14 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11698.
16:02:16 <jfkthame> jfkthame has joined #css
16:02:20 <kizu> kizu has joined #css
16:02:21 <smfr> present+
16:02:21 <ChrisL> q+
16:02:23 <kizu> present+
16:02:30 <chrishtr> present+
16:02:43 <dholbert> dholbert has joined #css
16:02:49 <TabAtkins> ChrisL: We haven't agreed on the intermeidate values for dynamic-range.
16:02:50 <dholbert> present+
16:02:52 <alisonmaher> alisonmaher has joined #css
16:02:56 <alisonmaher> present+
16:02:59 <TabAtkins> ChrisL: agreed on "standard" and "very-high"
16:03:09 <kbabbitt> kbabbitt has joined #css
16:03:20 <TabAtkins> ChrisL: proposal is "constrained", several people suggested and it seems to already be adopted by some community members
16:03:24 <astearns> s/very-high/no-limit/
16:03:24 <TabAtkins> ChrisL: so suggest we just take it
16:03:27 <flackr> present+
16:03:33 <moonira> зкуыуте+
16:03:40 <moonira> present+
16:03:52 <TabAtkins> jensimmons: it makes sense, constrained-high was designed to work with "high" when "high" meant HDR, but that's no-limit now
16:04:11 <jfkthame> present+
16:04:20 <TabAtkins> Rossen5: so proposal is to go with "constrained". any other comments, objections?
16:04:31 <TabAtkins> RESOLVED: Use "constrained" for the middle value
16:04:56 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12031
16:04:56 <github-bot> Topic: [css-highlight-api] Should highlightsFromPoint also return ranges under the hit point?
16:04:56 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12031.
16:05:05 <noamr> noamr has joined #css
16:05:40 <noamr> present+
16:05:51 <TabAtkins> fernando: this is about the return value of highlightsFromPoint
16:05:58 <fernando> fernando has joined #css
16:05:59 <TabAtkins> fernando: original proposal for for highlights that are hit under a certain point
16:06:13 <TabAtkins> fernando: after some examples, might be useful to return the *ranges* hit for every highlight that is hit, too
16:06:28 <TabAtkins> fernando: so proposing to return, rather than a sequence of highlights, a sequence of highlighthitresults that are the highlight and the range
16:06:45 <TabAtkins> fernando: this is useful fro spell checkers, custom find in page, etc where you need to know what word you're interacting with
16:06:55 <TabAtkins> fernando: so i'd like to hear your thoughts
16:07:00 <emilio> q+
16:07:20 <Rossen5> ack ChrisL
16:07:22 <Rossen5> ack emilio
16:07:22 <schenney> q+
16:07:26 <TabAtkins> emilio: seems fine overall
16:07:49 <TabAtkins> emilio: is the idea that... presuambly we're not synthesizing ranges, we return the actual Range objects right? just filtering down the ranges that the highlight currently has?
16:07:52 <TabAtkins> fernando:  yes, correct
16:07:59 <sakhapov> sakhapov has joined #css
16:08:18 <TabAtkins> emilio: okay, i think we had similar discussions (unsure if this api or another one), the concern was that it wasn't clear exactly what ranges to return
16:08:34 <TabAtkins> emilio: but as long as we're just filtering the existing ranges from the highlight, that's fine
16:08:37 <Rossen5> q+ to ask about overlapping ranges
16:08:44 <TabAtkins> emilio: one concern is you can't early-out as soon as you hit a highlight, you do need to iterate over the ranges
16:08:56 <TabAtkins> emilio: might be a littl eanoying to have to do that work if the user doesn't need it
16:09:20 <TabAtkins> emilio: but if you're clickign on one misspelled word, having to walk all the ranges associated with that highlight in author-land seems bad
16:09:35 <TabAtkins> emilio: so i think it's probably fine, just a bit unfortunate you'll still have to pay for it if all you need is the highlight itself
16:09:42 <TabAtkins> emilio: but the commonc ase is not hitting them anyway
16:09:44 <Rossen5> ack schenney
16:10:03 <TabAtkins> schenney: i think the issue you're remembering is related to the pseudo-classes on pseudo-elements, if you hovered a [missed due to overtalk]
16:10:05 <TabAtkins> emilio: that's right
16:10:28 <TabAtkins> schenney: if you set a highlight with a particuilar name, with multiple sub ranges, and you click on any one range you'll get all the ranges for that highlight? or just the ones under the hit point
16:10:34 <TabAtkins> fernando: the latter, only the ranges that were hit
16:10:42 <Rossen5> q-
16:10:44 <TabAtkins> fernando: you can already retrieve all the associated ranges just from the highlight directly
16:10:54 <TabAtkins> schenney: okay, i think that addresses the concern i raised on the intent. i'm happy, then
16:10:57 <Rossen5> ack fantasai
16:10:58 <Zakim> fantasai, you wanted to ask about a11y
16:11:02 <TabAtkins> fantasai: two questions
16:11:18 <TabAtkins> fantasai: for emilio's question, would it make sense to have two different apis? one that returns the highlight and one that filters the ranges?
16:11:20 <dandclark> q+
16:11:30 <TabAtkins> fantasai: if there's use-cases for just getting the highlight, the extra compute doesn't have to be done
16:11:51 <TabAtkins> fantasai: second, seems like we're envisioning some sophisticated interfaces being built. is there a plan for how this would work for keyboard users?
16:12:09 <TabAtkins> fernando: for first, currently there's no extra compute, we already have to go thru the ranges to hit-test anyway
16:12:22 <TabAtkins> fernando: but maybe there's another impl that can be done where it's an extra cost
16:12:37 <TabAtkins> fernando: for second, could you repeat?
16:12:40 <emilio> q+
16:12:47 <TabAtkins> fantasai: [repeats the question]
16:13:20 <TabAtkins> fernando: the API takes two coords, x y, that can be done with keyboard if you get the caret position
16:13:45 <TabAtkins> fantasai: that sounds a lot more complicated. do we think authors will acutally do that?
16:13:52 <schenney> q+
16:13:54 <TabAtkins> q+
16:14:18 <TabAtkins> fernando: hm, that could be something to think about. but i think this is similar to elementsFromPoint... was this a concern there as well?
16:14:28 <TabAtkins> fernando: would be interested to know how that api deals with it, it seems like the same idea
16:14:59 <TabAtkins> fantasai: so i suggest the spec should include a practical example with this API that shows off keyboard usage
16:15:07 <TabAtkins> fantasai: if that ends up being unreasonably complicated, we should solve that somehow
16:15:14 <TabAtkins> fantasai: whether that's altering this api or adding a new one
16:15:28 <fantasai> But in any case the spec should show off best practices
16:15:49 <TabAtkins> emilio: i think the keyboard interface is a lot simploer, you don't need to compute the caret position. the selection api has ranges
16:16:02 <TabAtkins> emilio: at least the range api does have an isPointInRange or something
16:16:17 <Rossen5> ack emilio
16:16:19 <TabAtkins> emilio: so it's actually easier to imlement for keyboard users, they just iterate over the highlights, then the ranges, and see if the caret point is in there
16:16:36 <TabAtkins> emilio: also i don't think AbstractRange has that API, only the live ranges. i think we should fix that.
16:16:51 <TabAtkins> fantasai: so yeah, i think the spec should just have an example of how to do this properly, so people know how to do it
16:17:03 <Rossen5> ack dandclark
16:17:12 <TabAtkins> dandclark: i think we shoudl also take a look at what devs are doing now
16:17:25 <TabAtkins> dandclark: we're just taking this ability into the engine. should look and see if that's already keyboard accessible.
16:17:57 <TabAtkins> fantasai: think the other point from fantasai about two APIs - wasn't sure if we were talkinga bout extra work from author or engine. either case, i think it makes more sense to be just one API.
16:18:03 <TabAtkins> s/fantasai/dandclark/
16:18:22 <emilio> q+
16:18:24 <TabAtkins> dandclark: from engine side we're doing the work anyway, from dev side fi they're getting it all together anyway they can just ignore one
16:18:29 <Rossen5> ack schenney
16:18:41 <dandclark> q+
16:18:47 <TabAtkins> schenney: on the a11y issues, i think it's a broader issue. no way to know in the a11y data if  a word or string is highlighted, i think
16:18:55 <TabAtkins> schenney: i'll look into that and raise an issue if that is a problem
16:19:13 <fantasai> scribe+
16:19:26 <TabAtkins> dandclark: exposing a11y of highlights is something we looked at. different platforms have different ways of exposing it, but OSes do have wayss to expose grammar/spelling/emphasis
16:19:39 <TabAtkins> dandclark: details escape me, they're different between paltforms, but we do expose things to a degree.
16:19:47 <Rossen5> ack TabAtkins
16:19:56 <flackr> q+ to ask about generic api combining things you might want to hit test
16:19:59 <fantasai> TabAtkins: Want to emphasize that this is essentially identical to elementsFromPoint()
16:20:11 <dandclark> TabAtkins: emphasizing that this is identical to elementsFromPoint. Should ensure it's solvable, add example, but that shouldn't be a blocker
16:20:13 <keithamus> keithamus has joined #css
16:20:28 <dandclark> ...it's doing the same things this other thing is already doing, and that thing is good on its own merits
16:20:36 <dandclark> q-
16:20:40 <Rossen5> ack emilio
16:20:44 <TabAtkins> emilio: one clarification on perf arg
16:20:58 <TabAtkins> emilio: i agree it's probably not worth two APIs, the common case needs the hit range anyway
16:20:59 <dgrogan> dgrogan has joined #css
16:21:15 <TabAtkins> emilio: my point is just that right now you could stop once you hit *one* range that works, you don't nhave to iterate all the rest
16:21:22 <emilio> https://github.com/whatwg/dom/issues/591
16:21:27 <TabAtkins> emilio: but i think in the common case you'll do it anyway, so no need for a separate api
16:21:45 <TabAtkins> emilio: for keyboards, i just linked to a DOM issue moving a lot of stuff from Range to AbstractRange. should move a lot of the test stuff
16:22:12 <TabAtkins> flackr: dunno if i mentioned it in this group, but i said it in the intent thread. i think we need to think about a more generic hit-testing api that combines the variosu things
16:22:20 <Rossen5> ack flackr
16:22:20 <Zakim> flackr, you wanted to ask about generic api combining things you might want to hit test
16:22:26 <TabAtkins> flackr: i think highlightFromPoint, you onlly get a highlight if the element with the highlight woudl have bene hit
16:22:34 <TabAtkins> flackr: but elementsFromPoint gives you the list in order
16:22:54 <TabAtkins> flackr: could be useful to ahve elements and highlights together, in order. maybe with options to let you test for pointer-events:none, etc
16:23:10 <TabAtkins> flackr: so this doesn't need to block this work, but we should pursue a more general hit-test API so we can deal with interleaved things
16:23:12 <TabAtkins> +1
16:23:33 <TabAtkins> Rossen5: so it sounds like we're agreeing with the proposal
16:23:53 <TabAtkins> Rossen5: there's good feedback i'm hoping editors will take back to the spec, for added clarity if nothing else
16:24:10 <TabAtkins> Rossen5: how it's different from rangesFromPoint(), how it addresses keyboard a11y, etc
16:24:17 <TabAtkins> Rossen5: but that said, any objections to the proposal as outlined?
16:24:27 <TabAtkins> RESOLVED: Accept the proposal in the issue.
16:24:40 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12119
16:24:40 <github-bot> Topic: [css-animations-2][web-animations-2] How should AnimationTrigger work?
16:24:40 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12119.
16:24:48 <TabAtkins> github-bot, end topic
16:24:56 <TabAtkins> github-bot, topic https://github.com/w3c/csswg-drafts/issues/12031
16:24:56 <github-bot> Topic: [css-highlight-api] Should highlightsFromPoint also return ranges under the hit point?
16:24:56 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12031.
16:25:24 <TabAtkins> fantasai: flackr brought up that elementsFromPoint returns a list. does this return a list of highlights...? wait nm, i misread the issue
16:25:44 <TabAtkins> emilio: rob's point is just that you don't interleave the highlights and elements. it's also a little naive, doesn't check pointer-events, etc
16:25:52 <TabAtkins> flackr: and i think ti stops as the first opaque elements
16:25:55 <TabAtkins> emilio: does it?
16:26:06 <TabAtkins> flackr: would be weird for it to not, don't want to hit a highlight that's obscured by another element
16:26:13 <TabAtkins> emilio: i think as specified it'll return the highlight
16:26:20 <TabAtkins> Rossen5: ccan we take this back to the issue?
16:26:22 <TabAtkins> emilio: yes
16:26:33 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/12119
16:26:34 <github-bot> Topic: [css-animations-2][web-animations-2] How should AnimationTrigger work?
16:26:34 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12119.
16:27:02 <TabAtkins> DavidA: we have this concept of animation triggers, which is a way to declaratively tie *when* to play/pause to a timeline, same as scroll-driven animations
16:27:11 <TabAtkins> DavidA: end goal is to support scroll-triggered animations
16:27:22 <TabAtkins> DavidA: two appraoches we can do this. different implications for the existing concepts
16:27:31 <TabAtkins> DavidA: one appraoch is thinking about animation triggers as an internal animation mechanism
16:27:38 <TabAtkins> DavidA: the other is triggers as an external thing.
16:27:52 <TabAtkins> DavidA: diff between modesl is their relationship between triggers and play/pause/etc
16:28:19 <TabAtkins> DavidA: for internal, we think of play as arming the trigger, so responsibility is the trigger itself. calling play() just gets the trigger ready, and then when the trigger is satisfied it actually plays
16:28:28 <TabAtkins> DavidA: the exteneral way, the trigger is what invokes play()
16:28:45 <TabAtkins> DavidA: we're not looking for a resolution today, just feedback on which way, if any, the WG would lean towards
16:29:00 <TabAtkins> DavidA: i think that'll inform how a lot of other issues i've filed will resolve
16:29:07 <TabAtkins> DavidA: i can talk about details
16:29:39 <ydaniv> q+
16:29:40 <TabAtkins> fantasai: i think it woudl be confusing if play() didn't make the animation play. i think the second animation makes more sense
16:29:55 <flackr> q+
16:30:00 <TabAtkins> fantasai: coudl imagine an animation easily that the author wants to tirgger on a scorll position, but also have an explicit trigger from the uesr. those shoudl interact in a reasonable way
16:30:10 <Rossen5> ack fantasai
16:30:22 <TabAtkins> DavidA: that would still be accommodated i nthe internal model
16:30:39 <TabAtkins> DavidA: what play() does, if the trigger isn';t armed, play() arms the trigger. if it's armed and tripped, play() starts the animation.
16:31:13 <dandclark> TabAtkins: I don't think that's right, if you have a trigger set up and you're not at the position, but want to have a button to trigger the animation, that won't trigger it in this case
16:31:39 <Rossen5> ack ydaniv
16:31:44 <TabAtkins> ydaniv: on my last issue comment, i tried to enumerate the things i think we already agree on in the behavior. we shoudl solve the behavior first, what we expect
16:31:48 <TabAtkins> ydaniv: like what fantasai asked about
16:32:01 <TabAtkins> ydaniv: and once we agree on the behavior, can decide what the model should be
16:32:22 <TabAtkins> ydaniv: so i enumerated stuff i think we agree on, and rob has a comment on a lot of stuff about how it works with existing animation features, which i also think we have agreement on
16:32:29 <flackr> https://github.com/w3c/csswg-drafts/issues/12119#issuecomment-2842322212
16:32:42 <TabAtkins> ydaniv: a couple of issues i think are still open are, what happens with multiple calls to play() with an already activated trigger?
16:32:55 <TabAtkins> ydaniv: and what happens if a user calls reverse()?
16:33:36 <TabAtkins> DavidA: on the first, repeated calls to play(), i think that's what i just talked about - i think the expectation is it would play again if you call it repeatedly
16:34:05 <TabAtkins> DavidA: for reverse(), i think the expectation is also tha tit would play, it's like play() it just auto-reverses it
16:34:41 <TabAtkins> flackr: another important aspect to consider is, if you cancel an animation, it won't have an effect until you play() again. if you construct an animation but don't play() it it wont' ahve an effect
16:34:55 <TabAtkins> flackr: so does assigning a trigger to it make it start having an effect? particularly in the "before" phase?
16:34:58 <Rossen5> ack flackr
16:35:11 <TabAtkins> flackr: that seems surprising. seems like you need some way to "arm" the trigger that's not just implict
16:35:27 <TabAtkins> flackr: also from element.animate() it impliciatly calls play, we wouldn't expect it to start playing
16:35:44 <TabAtkins> flackr: note i'm not looking to address these issues right now
16:35:58 <Rossen5> ack fantasai
16:36:16 <TabAtkins> fantasai: i'd ahve to read the whole thing to have a good sense, but i feel like the trigger should be another actor - the user (via JS) and the trigger, they're both animating on the animation and can each make it play or pause or whatever
16:36:34 <TabAtkins> fantasai: i think those calls interleave in that way, like there's two users that each have access to the play/pause buttons
16:36:54 <TabAtkins> (modulo some questions about the animation being "active" for before effect, etc, I also agree with fantasai initially)
16:36:55 <ydaniv> I had the same model in mind as fantasai
16:37:18 <fantasai> s/animating on the/acting on the/
16:37:26 <TabAtkins> Rossen5: so, what resolution are you looking for?
16:37:45 <TabAtkins> DavidA: none right now, looking for feedback on what model to go with
16:38:10 <TabAtkins> DavidA: [summarizes the models again]
16:38:30 <flackr> ydaniv, fantasai that model naively would mean that the animation isn't in getAnimations, and isn't in the before phase until triggered
16:38:37 <TabAtkins> DavidA: would probably be useful to know that, in the second model (trigger calls play()), to rob's point, we'll need some explicit apis to say when to enable and disable the trigger
16:38:58 <TabAtkins> DavidA: so if people still want to think about it, that's fine, otherwise we can resolve one way or another
16:39:16 <TabAtkins> (I think continuing on the issue and treating this as just raising awareness is just fine.)
16:39:27 <TabAtkins> fantasai: adding extra apis to enable/disable the trigger makes sense tome
16:39:36 <fantasai> s/tome/to me
16:40:02 <TabAtkins> Rossen5: all right, let's come back with a model with those extra APIs
16:40:07 <ChrisL> q+
16:40:11 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/11339
16:40:11 <github-bot> Topic: [css-masking] Impact of masks on hit-testing needs to be specified
16:40:11 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/11339.
16:40:15 <ydaniv> flackr I agree that we should tweak the naive model further
16:40:44 <TabAtkins> ChrisL: we ahve an extra issue that says we don't specify hit-testing anywhere. been open since 2018
16:41:06 <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
16:41:18 <TabAtkins> q+ to talk about the 2018 issue
16:41:31 <TabAtkins> ack ChrisL
16:41:33 <Rossen5> ack ChrisL
16:41:54 <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
16:42:01 <TabAtkins> smfr: so it's a compat issue in what can acutally be clicked
16:42:08 <TabAtkins> smfr: hit testing is undefined in general. what do we do?
16:42:16 <emilio> q+
16:42:16 <fantasai> scribe+
16:42:22 <Rossen5> ack TabAtkins
16:42:22 <Zakim> TabAtkins, you wanted to talk about the 2018 issue
16:42:29 <fantasai> TabAtkins: Me and Chris Harrelson chatted about this earlier today, and we want to get this spec written this year
16:42:35 <fantasai> TabAtkins: So already on my plan to do this year
16:42:45 <fantasai> TabAtkins: don't have an opinion on solving this issue for masks now or put details later into other spec
16:42:51 <ChrisL> q+ to mention masks vs clips
16:42:55 <fantasai> TabAtkins: but I would like to write up the spec later this year to close the 2018 issue
16:43:00 <fantasai> TabAtkins: No comments on this specific issue
16:43:07 <fantasai> Rossen5: That would be amazing to have
16:43:14 <fantasai> emilio: +1
16:43:14 <TabAtkins> emilio: yeah huge +1 to having the spec
16:43:26 <TabAtkins> emilio: for this issue, is there a good use-case... what would authors expect?
16:43:32 <TabAtkins> emilio: could see both.
16:43:41 <TabAtkins> emilio: might want mask decorative, others where you want it honored
16:44:09 <Rossen5> ack ChrisL
16:44:09 <Zakim> ChrisL, you wanted to mention masks vs clips
16:44:10 <TabAtkins> emilio: since there's disagreement i assume we can change, just need to figure out what th emost useful behavior is
16:44:23 <noamr> +1
16:44:29 <noamr> q+
16:44:40 <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
16:45:00 <TabAtkins> ChrisL: i think we should definitely define it, and it shoudln't be like a 50% mask value or something
16:45:07 <emilio> ack emilio
16:45:12 <Rossen5> ack noamr
16:45:21 <kizu> q+
16:45:29 <lea> what if we have reasonable defaults and a way to override them? (e.g. `hit-testing-area` or something, TBB)
16:45:31 <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
16:45:39 <TabAtkins> noamr: opacity doesn't affect hit-testing, that's a feature more than a bug
16:45:44 <TabAtkins> noamr: so opacity:0 elements are still hit-tested
16:45:51 <TabAtkins> noamr: to me mask is more like oapcity than a clip-path
16:46:05 <TabAtkins> noamr: so i think we should be consistent
16:46:06 <ChrisL> q+
16:46:07 <TabAtkins> q+
16:46:17 <Rossen5> ack kizu
16:46:35 <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
16:46:40 <TabAtkins> kizu: sometimes want differnet beahviors
16:47:02 <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.
16:47:18 <TabAtkins> ChrisL: i agree this shoudl be consistent with opacity. we're entirely silent on the opacity issue fwiw
16:47:31 <TabAtkins> ChrisL: at minimum, should we put something into opacity saying "this doesn't affect hit testing"?
16:47:39 <TabAtkins> ChrisL: seems there's consensus on that between browsers.
16:47:50 <TabAtkins> ChrisL: there's a WPT proposed by ladybird becuase this is untested
16:47:54 <Rossen5> ack ChrisL
16:47:56 <Rossen5> ack TabAtkins
16:48:02 <fantasai> TabAtkins: Agree, now that I remember
16:48:06 <fantasai> TabAtkins: binary vs gradient issue
16:48:18 <fantasai> TabAtkins: agree we should have mask by default work same as opacity, i.e. no effect on hit testing
16:48:30 <fantasai> TabAtkins: Need more exploration of tools; being able to derive a clip-path from a mask would be useful
16:48:34 <fantasai> TabAtkins: but that would be a clip-path feature
16:48:44 <fantasai> TabAtkins: put some individual details into properties like opacity / mask is a good idea
16:48:52 <Rossen5> ack fantasai
16:49:30 <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.
16:49:43 <TabAtkins> fantasai: can have examples, but not having the centralized list of exhaustive effects.
16:50:05 <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
16:50:13 <TabAtkins> fantasai: maybe we want to take those as resolutions?
16:50:42 <TabAtkins> Rossen5: okay, propose that opacity doesn't affect hit-testing. any objections to that?
16:50:59 <TabAtkins> RESOLVED: Specify that 'opacity' has no effect on hit-testing.
16:51:09 <TabAtkins> Rossen5: next, propose that 'mask' has no effect on hit-testing
16:51:22 <TabAtkins> smfr: this would require behavior changes from chrome and firefox
16:51:40 <TabAtkins> RESOLVED: Specify that 'mask' has no effect on hit-testing
16:51:50 <TabAtkins> Rossen5: finally, propose to define a way to derive a clip-path from mask
16:52:52 <TabAtkins> smfr: Noting that shape-outside also has a way to derive a path from an image, we should be consistent
16:52:57 <emeyer> +1 to smfr’s point about being consistent with shape-outside
16:53:07 <ydaniv> +1
16:53:11 <TabAtkins> smfr: shape-outside defaults to using the opacity of the image. if we have knobs for that, they should work in both places
16:53:17 <ChrisL> Agree that both mask opacity and mask luminance should be options
16:53:20 <fantasai> See https://www.w3.org/TR/css-shapes-1/#shape-image-threshold-property
16:53:26 <fantasai> and https://www.w3.org/TR/css-shapes-1/#shape-outside-property
16:53:29 <emeyer> +1 to ChrisL
16:53:44 <fantasai> TabAtkins: shapes spec uses alpha channel, defines threshold
16:53:51 <fantasai> TabAtkins: we can figure out how to make them consistent
16:54:12 <TabAtkins> Rossen5: so figure otu some way to define a clip path from an image, similar to shape outside. details TBD
16:54:24 <noamr> btw `view-transitions` spec *does* define hit-testing
16:54:28 <TabAtkins> RESOLVED: Define some way for clip-path to derive a path from an image, similar to shape-outside. Details TBD.
16:55:14 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/3720
16:55:15 <github-bot> Topic: [css-borders] Add a 'hairline' border-width value
16:55:15 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/3720.
16:55:54 <fantasai> TabAtkins: Discussed border-rounding behavior, where borders with nonzero width but less than a pixel will round to something visible
16:55:59 <fantasai> TabAtkins: lot of discussion
16:56:10 <fantasai> TabAtkins: conversation seemed to lean towards exposing a 'hairline' keyword for a few propoerties
16:56:28 <fantasai> TabAtkins: and maybe a rounding function that rounds like borders do, always away from zero
16:56:42 <fantasai> TabAtkins: since then, Oriol suggested 'hairline' as a unit
16:56:47 <fantasai> TabAtkins: maps to a number of device pixels
16:56:58 <fantasai> TabAtkins: can be used as a length unit anywhere lenghts are allowed
16:57:03 <fantasai> TabAtkins: avoids need for new rounding function
16:57:17 <fantasai> TabAtkins: also useful if you want another box to match the width of a box with hairline border
16:57:25 <fantasai> TabAtkins: could specify calc(100px + 2hairline)
16:57:40 <fantasai> TabAtkins: smfr concerned that larger multiples wouldn't be reasonable
16:57:46 <fantasai> TabAtkins: but use cases for small multiples
16:57:55 <emilio> q+
16:57:57 <fantasai> TabAtkins: so I suggest resolving on this approach
16:58:10 <fantasai> TabAtkins: a new unit that is 1px or less, but at least one device pixel
16:58:19 <Rossen5> ack emilio
16:58:23 <smfr> q+
16:58:36 <TabAtkins> emilio: one question, should we make it a keyword rather than a unit?
16:58:46 <TabAtkins> emilio: a unit that's such a mouthfull feels weird
16:58:52 <emeyer> q+
16:59:02 <flackr> q+
16:59:15 <dandclark> TabAtkins: A keyword either is not usable in calc, or is one of hte calc keywords, unless we do something to make it usable both ways
16:59:30 <TabAtkins> smfr: i wo9uldn't object to the unit, think ti's a bit weird tho
16:59:50 <dandclark> TabAtkins: Exactly what we do today with border witdths less than a pixel. We still have some def of what it means internally
17:00:08 <emeyer> q-
17:00:20 <TabAtkins> fantasai: i think making this a unit feels wrong, if you want the boxes to match you should use box-sizing
17:00:31 <Rossen5> ack smfr
17:00:33 <Rossen5> ack fantasai
17:00:39 <jfkthame> fantasai++
17:00:41 <TabAtkins> fantasai: people might start using the unit to reference device pixels in a way that's more fragile than we want
17:00:59 <TabAtkins> flackr: if an author wants something thicker than a hairline...?
17:01:05 <TabAtkins> TabAtkins: max(1hairline, .3px)
17:01:10 <Rossen5> ack flackr
17:01:13 <Rossen5> ack fantasai
17:01:19 <TabAtkins> fantasai: i think ahving a rounding function makes more sense
17:01:33 <emilio> fwiw, I think implementing it as a keyword seems trivial-ish as well (so that it works in calc() and other <length>s too)
17:01:35 <TabAtkins> TabAtkins: well this clearly wasn't doable in five minutes
17:01:35 <emeyer> I have concerns about device printing with a unit that yields a number of device pixels.
17:01:45 <emeyer> s/printing/fingerprinting/
17:01:59 <emeyer> emeyer has left #css
17:02:04 <TabAtkins> emeyer, device pixel ratio is already exposed in numerous other ways
17:02:09 <Rossen5> topic: End
17:02:17 <Rossen5> Zakim, end meeting
17:02:17 <Zakim> As of this point the attendees have been Rossen, miriam, jensimmons, dandclark, emilio, emeyer, ydaniv, ChrisL, weinig, DavidA, smfr, kizu, chrishtr, JoshT, dholbert, alisonmaher,
17:02:20 <Zakim> ... kbabbitt, flackr, moonira, jfkthame, noamr, keithamus
17:02:20 <Zakim> RRSAgent, please draft minutes v2
17:02:22 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/07-css-minutes.html Zakim
17:02:29 <Zakim> I am happy to have been of service, Rossen5; please remember to excuse RRSAgent.  Goodbye
17:02:30 <Zakim> Zakim has left #css
17:03:34 <TabAtkins> emilio, yeah, we *can* do the keyword both ways at once - a keyword usable on its own (in specific properties...? there's parsing concerns if it's widely usable) and a calc-keyword. But that means in the places where we didn't define the keyword to be usable directly, authors have to remember to write it as `calc(hairline)`, which is unfortunate.
17:03:56 <TabAtkins> `1hairline` is fine to be usable everywhere, since dimensions don't trigger the same parsing concerns
17:12:29 <emilio> TabAtkins: I see... Slightly annoying indeed
17:31:41 <jensimmons> jensimmons has joined #css
18:47:16 <jfkthame> jfkthame has joined #css
20:47:21 <jfkthame> jfkthame has joined #css
22:26:00 <jfkthame> jfkthame has joined #css