Meeting minutes
github-bot, take up w3c/
[css-color-hdr] New values for dynamic-range-limit property
<github-bot> OK, I'll post this discussion to https://
ChrisL: We haven't agreed on the intermeidate values for dynamic-range.
ChrisL: agreed on "standard" and "no-limit"
ChrisL: proposal is "constrained", several people suggested and it seems to already be adopted by some community members
ChrisL: so suggest we just take it
<moonira> зкуыуте+
jensimmons: it makes sense, constrained-high was designed to work with "high" when "high" meant HDR, but that's no-limit now
Rossen5: so proposal is to go with "constrained". any other comments, objections?
RESOLUTION: Use "constrained" for the middle value
github-bot, take up w3c/
[css-highlight-api] Should highlightsFromPoint also return ranges under the hit point?
<github-bot> OK, I'll post this discussion to https://
fernando: this is about the return value of highlightsFromPoint
fernando: original proposal for for highlights that are hit under a certain point
fernando: after some examples, might be useful to return the *ranges* hit for every highlight that is hit, too
fernando: so proposing to return, rather than a sequence of highlights, a sequence of highlighthitresults that are the highlight and the range
fernando: this is useful fro spell checkers, custom find in page, etc where you need to know what word you're interacting with
fernando: so i'd like to hear your thoughts
emilio: seems fine overall
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?
fernando: yes, correct
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
emilio: but as long as we're just filtering the existing ranges from the highlight, that's fine
emilio: one concern is you can't early-out as soon as you hit a highlight, you do need to iterate over the ranges
emilio: might be a littl eanoying to have to do that work if the user doesn't need it
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
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
emilio: but the commonc ase is not hitting them anyway
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]
emilio: that's right
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
fernando: the latter, only the ranges that were hit
fernando: you can already retrieve all the associated ranges just from the highlight directly
schenney: okay, i think that addresses the concern i raised on the intent. i'm happy, then
<Zakim> fantasai, you wanted to ask about a11y
fantasai: two questions
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?
fantasai: if there's use-cases for just getting the highlight, the extra compute doesn't have to be done
fantasai: second, seems like we're envisioning some sophisticated interfaces being built. is there a plan for how this would work for keyboard users?
fernando: for first, currently there's no extra compute, we already have to go thru the ranges to hit-test anyway
fernando: but maybe there's another impl that can be done where it's an extra cost
fernando: for second, could you repeat?
fantasai: [repeats the question]
fernando: the API takes two coords, x y, that can be done with keyboard if you get the caret position
fantasai: that sounds a lot more complicated. do we think authors will acutally do that?
fernando: hm, that could be something to think about. but i think this is similar to elementsFromPoint... was this a concern there as well?
fernando: would be interested to know how that api deals with it, it seems like the same idea
fantasai: so i suggest the spec should include a practical example with this API that shows off keyboard usage
fantasai: if that ends up being unreasonably complicated, we should solve that somehow
fantasai: whether that's altering this api or adding a new one
<fantasai> But in any case the spec should show off best practices
emilio: i think the keyboard interface is a lot simploer, you don't need to compute the caret position. the selection api has ranges
emilio: at least the range api does have an isPointInRange or something
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
emilio: also i don't think AbstractRange has that API, only the live ranges. i think we should fix that.
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
dandclark: i think we shoudl also take a look at what devs are doing now
dandclark: we're just taking this ability into the engine. should look and see if that's already keyboard accessible.
dandclark: 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.
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
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
schenney: i'll look into that and raise an issue if that is a problem
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
dandclark: details escape me, they're different between paltforms, but we do expose things to a degree.
TabAtkins: Want to emphasize that this is essentially identical to elementsFromPoint()
<dandclark> TabAtkins: emphasizing that this is identical to elementsFromPoint. Should ensure it's solvable, add example, but that shouldn't be a blocker
<dandclark> ...it's doing the same things this other thing is already doing, and that thing is good on its own merits
emilio: one clarification on perf arg
emilio: i agree it's probably not worth two APIs, the common case needs the hit range anyway
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
<emilio> whatwg/
emilio: but i think in the common case you'll do it anyway, so no need for a separate api
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
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
<Zakim> flackr, you wanted to ask about generic api combining things you might want to hit test
flackr: i think highlightFromPoint, you onlly get a highlight if the element with the highlight woudl have bene hit
flackr: but elementsFromPoint gives you the list in order
flackr: could be useful to ahve elements and highlights together, in order. maybe with options to let you test for pointer-events:none, etc
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
<TabAtkins> +1
Rossen5: so it sounds like we're agreeing with the proposal
Rossen5: there's good feedback i'm hoping editors will take back to the spec, for added clarity if nothing else
Rossen5: how it's different from rangesFromPoint(), how it addresses keyboard a11y, etc
Rossen5: but that said, any objections to the proposal as outlined?
RESOLUTION: Accept the proposal in the issue.
github-bot, take up w3c/
[css-animations-2][web-animations-2] How should AnimationTrigger work?
<github-bot> OK, I'll post this discussion to https://
github-bot, end topic
github-bot, topic w3c/
[css-highlight-api] Should highlightsFromPoint also return ranges under the hit point?
<github-bot> OK, I'll post this discussion to https://
fantasai: flackr brought up that elementsFromPoint returns a list. does this return a list of highlights...? wait nm, i misread the issue
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
flackr: and i think ti stops as the first opaque elements
emilio: does it?
flackr: would be weird for it to not, don't want to hit a highlight that's obscured by another element
emilio: i think as specified it'll return the highlight
Rossen5: ccan we take this back to the issue?
emilio: yes
github-bot, take up w3c/
[css-animations-2][web-animations-2] How should AnimationTrigger work?
<github-bot> OK, I'll post this discussion to https://
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
DavidA: end goal is to support scroll-triggered animations
DavidA: two appraoches we can do this. different implications for the existing concepts
DavidA: one appraoch is thinking about animation triggers as an internal animation mechanism
DavidA: the other is triggers as an external thing.
DavidA: diff between modesl is their relationship between triggers and play/pause/etc
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
DavidA: the exteneral way, the trigger is what invokes play()
DavidA: we're not looking for a resolution today, just feedback on which way, if any, the WG would lean towards
DavidA: i think that'll inform how a lot of other issues i've filed will resolve
DavidA: i can talk about details
fantasai: i think it woudl be confusing if play() didn't make the animation play. i think the second animation makes more sense
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
DavidA: that would still be accommodated i nthe internal model
DavidA: what play() does, if the trigger isn';t armed, play() arms the trigger. if it's armed and tripped, play() starts the animation.
<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
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
ydaniv: like what fantasai asked about
ydaniv: and once we agree on the behavior, can decide what the model should be
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
<flackr> w3c/
ydaniv: a couple of issues i think are still open are, what happens with multiple calls to play() with an already activated trigger?
ydaniv: and what happens if a user calls reverse()?
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
DavidA: for reverse(), i think the expectation is also tha tit would play, it's like play() it just auto-reverses it
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
flackr: so does assigning a trigger to it make it start having an effect? particularly in the "before" phase?
flackr: that seems surprising. seems like you need some way to "arm" the trigger that's not just implict
flackr: also from element.animate() it impliciatly calls play, we wouldn't expect it to start playing
flackr: note i'm not looking to address these issues right now
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 acting on the animation and can each make it play or pause or whatever
fantasai: i think those calls interleave in that way, like there's two users that each have access to the play/pause buttons
(modulo some questions about the animation being "active" for before effect, etc, I also agree with fantasai initially)
<ydaniv> I had the same model in mind as fantasai
Rossen5: so, what resolution are you looking for?
DavidA: none right now, looking for feedback on what model to go with
DavidA: [summarizes the models again]
<flackr> ydaniv, fantasai that model naively would mean that the animation isn't in getAnimations, and isn't in the before phase until triggered
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
DavidA: so if people still want to think about it, that's fine, otherwise we can resolve one way or another
(I think continuing on the issue and treating this as just raising awareness is just fine.)
fantasai: adding extra apis to enable/disable the trigger makes sense to me
Rossen5: all right, let's come back with a model with those extra APIs
github-bot, take up w3c/
[css-masking] Impact of masks on hit-testing needs to be specified
<github-bot> OK, I'll post this discussion to https://
<ydaniv> flackr I agree that we should tweak the naive model further
ChrisL: we ahve an extra issue that says we don't specify hit-testing anywhere. been open since 2018
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
smfr: hit testing is undefined, with masks there's different behavior. webkit follows the current spec and ignores the mask, chrome respects the mask
smfr: so it's a compat issue in what can acutally be clicked
smfr: hit testing is undefined in general. what do we do?
<Zakim> TabAtkins, you wanted to talk about the 2018 issue
TabAtkins: Me and Chris Harrelson chatted about this earlier today, and we want to get this spec written this year
TabAtkins: So already on my plan to do this year
TabAtkins: don't have an opinion on solving this issue for masks now or put details later into other spec
TabAtkins: but I would like to write up the spec later this year to close the 2018 issue
TabAtkins: No comments on this specific issue
Rossen5: That would be amazing to have
emilio: +1
emilio: yeah huge +1 to having the spec
emilio: for this issue, is there a good use-case... what would authors expect?
emilio: could see both.
emilio: might want mask decorative, others where you want it honored
<Zakim> ChrisL, you wanted to mention masks vs clips
emilio: since there's disagreement i assume we can change, just need to figure out what th emost useful behavior is
<noamr> +1
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
ChrisL: i think we should definitely define it, and it shoudln't be like a 50% mask value or something
<lea> what if we have reasonable defaults and a way to override them? (e.g. `hit-testing-area` or something, TBB)
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
noamr: opacity doesn't affect hit-testing, that's a feature more than a bug
noamr: so opacity:0 elements are still hit-tested
noamr: to me mask is more like oapcity than a clip-path
noamr: so i think we should be consistent
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
kizu: sometimes want differnet beahviors
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.
ChrisL: i agree this shoudl be consistent with opacity. we're entirely silent on the opacity issue fwiw
ChrisL: at minimum, should we put something into opacity saying "this doesn't affect hit testing"?
ChrisL: seems there's consensus on that between browsers.
ChrisL: there's a WPT proposed by ladybird becuase this is untested
TabAtkins: Agree, now that I remember
TabAtkins: binary vs gradient issue
TabAtkins: agree we should have mask by default work same as opacity, i.e. no effect on hit testing
TabAtkins: Need more exploration of tools; being able to derive a clip-path from a mask would be useful
TabAtkins: but that would be a clip-path feature
TabAtkins: put some individual details into properties like opacity / mask is a good idea
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.
fantasai: can have examples, but not having the centralized list of exhaustive effects.
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
fantasai: maybe we want to take those as resolutions?
Rossen5: okay, propose that opacity doesn't affect hit-testing. any objections to that?
RESOLUTION: Specify that 'opacity' has no effect on hit-testing.
Rossen5: next, propose that 'mask' has no effect on hit-testing
smfr: this would require behavior changes from chrome and firefox
RESOLUTION: Specify that 'mask' has no effect on hit-testing
Rossen5: finally, propose to define a way to derive a clip-path from mask
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
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
See https://
and https://
<emeyer> +1 to ChrisL
TabAtkins: shapes spec uses alpha channel, defines threshold
TabAtkins: we can figure out how to make them consistent
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
RESOLUTION: Define some way for clip-path to derive a path from an image, similar to shape-outside. Details TBD.
github-bot, take up w3c/
[css-borders] Add a 'hairline' border-width value
<github-bot> OK, I'll post this discussion to https://
TabAtkins: Discussed border-rounding behavior, where borders with nonzero width but less than a pixel will round to something visible
TabAtkins: lot of discussion
TabAtkins: conversation seemed to lean towards exposing a 'hairline' keyword for a few propoerties
TabAtkins: and maybe a rounding function that rounds like borders do, always away from zero
TabAtkins: since then, Oriol suggested 'hairline' as a unit
TabAtkins: maps to a number of device pixels
TabAtkins: can be used as a length unit anywhere lenghts are allowed
TabAtkins: avoids need for new rounding function
TabAtkins: also useful if you want another box to match the width of a box with hairline border
TabAtkins: could specify calc(100px + 2hairline)
TabAtkins: smfr concerned that larger multiples wouldn't be reasonable
TabAtkins: but use cases for small multiples
TabAtkins: so I suggest resolving on this approach
TabAtkins: a new unit that is 1px or less, but at least one device pixel
emilio: one question, should we make it a keyword rather than a unit?
emilio: a unit that's such a mouthfull feels weird
<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
smfr: i wo9uldn't object to the unit, think ti's a bit weird tho
<dandclark> TabAtkins: Exactly what we do today with border witdths less than a pixel. We still have some def of what it means internally
fantasai: i think making this a unit feels wrong, if you want the boxes to match you should use box-sizing
<jfkthame> fantasai++
fantasai: people might start using the unit to reference device pixels in a way that's more fragile than we want
flackr: if an author wants something thicker than a hairline...?
TabAtkins: max(1hairline, .3px)
fantasai: i think ahving a rounding function makes more sense
<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)
TabAtkins: well this clearly wasn't doable in five minutes
<emeyer> I have concerns about device fingerprinting with a unit that yields a number of device pixels.
emeyer, device pixel ratio is already exposed in numerous other ways