15:39:53 <RRSAgent> RRSAgent has joined #css
15:39:57 <RRSAgent> logging to https://www.w3.org/2026/03/31-css-irc
15:39:57 <Zakim> RRSAgent, make logs Public
15:39:58 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
15:49:00 <liminzhu> liminzhu has joined #css
15:50:27 <astearns> astearns has changed the topic to: agenda: https://github.com/orgs/w3c/projects/232/views/1
15:51:34 <hoch> hoch has joined #css
15:52:49 <flackr> flackr has joined #css
15:55:52 <dshin-moz> dshin-moz has joined #css
15:56:31 <dshin-moz> dshin-moz has left #css
15:56:46 <dshin> dshin has joined #css
16:00:33 <Kurt> Kurt has joined #css
16:00:37 <astearns> we’ll likely start in 10-15 mins. Still seeing some local folks parking and coming in
16:01:12 <flackr> present+
16:02:46 <romain> present+
16:03:21 <kizu> present+
16:03:23 <dbaron> I can hear the room and see the room (weird angle)
16:03:26 <dbaron> Present+
16:03:47 <kbabbitt> present+
16:04:00 <astearns> dbaron: could you say something so we can see if remote folks are audible?
16:04:08 <alisonmaher> present+
16:04:16 <Rossen> Rossen has joined #css
16:04:35 <dbaron> astearns, done, did you hear?
16:04:53 <dbaron> (and flackr heard me and answered, too)
16:05:01 <iank_> iank_ has joined #css
16:05:08 <flackr> my bad, i'm remote, i thought you were someone in the room asking
16:05:32 <dbaron> no, it's useful confirmation that the video call works -- just seems like the room can't hear the call yet, perhaps
16:06:21 <Kurt> present+
16:06:30 <liminzhu> present+
16:06:32 <miriam> present+
16:07:02 <flackr> present+
16:07:10 <Rossen> present+
16:07:42 <hoch> present+
16:07:47 <dholbert> present+
16:07:52 <dbaron> astearns, can you hear the remote folks?
16:08:18 <astearns> yes (at least you)
16:08:34 <oriol> oriol has joined #css
16:08:47 <TabAtkins> <h1>Meeting Start!</h1>
16:08:51 <rachelandrew> present+
16:08:55 <TabAtkins> ScribeNick: TabAtkins
16:09:18 <vmpstr> present+
16:09:53 <dshin> present+
16:10:03 <oriol> Oriol Brufau, Igalia
16:10:07 <oriol> present+
16:10:47 <fantasai> present+
16:10:47 <emilio> Emilio Cobos, Mozilla
16:10:49 <dbaron> audio was pretty weak until reaching florian, but seems good from florian through about alison maher, and then faded a little at the end
16:10:49 <emilio> present+
16:10:52 <fantasai> Elika Etemad aka fantasai, Apple
16:11:18 <iank_> Ian Kilpatrick, Google Chrome
16:11:29 <rachelandrew> Rachel Andrew, Google Chrome
16:11:55 <vmpstr> Vladimir Levin, Google Chrome
16:12:06 <astearns> Alan Stearns, Adobe
16:12:16 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13728
16:12:17 <github-bot> Topic: Proposal: Declarative Web Haptics
16:12:17 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13728
16:12:45 <ydaniv> present+
16:13:28 <TabAtkins> liminzhu: wanna talk about the new Web Haptics proposal
16:13:36 <ydaniv> Yehonatan Daniv, Wix
16:13:40 <TabAtkins> liminzhu: gonna go thru the explainer, and ask som eopen questions i want feedback on
16:13:45 <TabAtkins> liminzhu: free free to ask questions
16:13:51 <kbabbitt> explainer link: https://github.com/w3c/csswg-drafts/issues/13728
16:13:55 <TabAtkins> liminzhu: to set the stage, folks are somewaht familiar with haptics
16:13:59 <ChrisL> Chris Lilley, W3C
16:14:00 <TabAtkins> liminzhu: every os has it to an extent
16:14:03 <ChrisL> present+
16:14:10 <TabAtkins> liminzhu: scrolling thru date-time picker, docking windows, etc
16:14:18 <TabAtkins> liminzhu: haptics adds grounding and interest to the user epxerience
16:14:23 <TabAtkins> liminzhu: and more haptics-capable devices
16:14:38 <TabAtkins> liminzhu: right now we only have navigator.vibrate()
16:14:43 <TabAtkins> liminzhu: barely supported anywhere
16:14:49 <TabAtkins> liminzhu: so not something webdevs can rely on
16:14:58 <TabAtkins> liminzhu: it also takes a raw pattern array, as a webdev i have to handwrite the pattern
16:15:01 <TabAtkins> liminzhu: a hassle
16:15:16 <TabAtkins> liminzhu: it's also just JS, can't do it declaratively to get easier authoring and lower latency
16:15:24 <TabAtkins> liminzhu: so i'm proposing a new haptics ui that's sematnics-based
16:15:35 <TabAtkins> liminzhu: instead of expressing a pattern, you say th eintended effect. a tick, etc
16:15:45 <TabAtkins> liminzhu: UA maps intent to what the hardware wants to express it as
16:15:54 <TabAtkins> liminzhu: have a declarative form, css, and an imperative in JS
16:15:58 <Rossen> Rossen has joined #css
16:16:04 <smfr> smfr has joined #css
16:16:08 <TabAtkins> liminzhu: covers all the places where css doesn't cover well
16:16:17 <TabAtkins> liminzhu: gonna focus on the css side today but i'll intro the js one too
16:16:22 <antonp> antonp has joined #css
16:16:30 <lea> lea has joined #css
16:16:37 <TabAtkins> liminzhu: in goals, wanna get a standard cross-platform haptics capability, low latencywithout js
16:16:53 <TabAtkins> liminzhu: non-goal, not guarantee haptics are identical across platforms. UAs can decide the best native3 way to epxress intents
16:16:55 <lea> present+
16:17:22 <TabAtkins> liminzhu: we're also scopign to *reactive* haptics, direct response to user actions rather than long-term notification-style haptics to *gian* attention
16:17:32 <TabAtkins> liminzhu: also not targetting specialized hardware, too complex right now
16:17:45 <TabAtkins> liminzhu: talking thru the two parameters, an effect and an optional intensity
16:17:56 <TabAtkins> liminzhu: effect is a predefined list of effects that the UA will map to hardware
16:18:03 <TabAtkins> liminzhu: 'hint' is a light subtle cue
16:18:10 <TabAtkins> liminzhu: 'edge' is a stronger boudnary signal
16:18:23 <TabAtkins> liminzhu: 'tick' is a firm pulse like when scrolling a date-time picker
16:18:23 <Rossen> q?
16:18:29 <TabAtkins> liminzhu: 'align' when snapping shapes, etc
16:18:34 <lea> q?
16:18:36 <TabAtkins> liminzhu: crisp confirmation two things are locking together
16:18:59 <TabAtkins> liminzhu: this table shows some guidelines for how various OSes can map the hints to existing effects
16:19:13 <TabAtkins> liminzhu: Intensity is a 0-1 values. it compounds with system-level intensity.
16:19:24 <SebastianZ> SebastianZ has joined #css
16:19:36 <TabAtkins> liminzhu: imperative API is is `navigator.playHaptics(effect, intensity)`
16:19:53 <TabAtkins> liminzhu: note that it doesn't return a signal on whether it played or not. shoudl alleviate some fingerprinting
16:20:02 <TabAtkins> liminzhu: and it's intended to be an optional upgrade, not something you depend on
16:20:20 <TabAtkins> liminzhu: 'haptic-feedback' property: effect intensity?
16:20:38 <TabAtkins> liminzhu: can do `button:active { haptic-feedback: align; }` etc
16:21:02 <TabAtkins> liminzhu: i don't think there's any existing css mechanism where something fires for some pseudoclass changes but not all
16:21:18 <TabAtkins> liminzhu: but for haptics it probably only makes sense to fire for user-behavior ones
16:21:20 <emilio> q+
16:21:23 <TabAtkins> liminzhu: not meaningful for :first-child or whatever
16:21:26 <TabAtkins> liminzhu: i'll get to that later
16:21:27 <TabAtkins> q+
16:21:32 <sgill_> sgill_ has joined #css
16:21:40 <TabAtkins> liminzhu: there's another alt form we're thinking about mapping haptics to transitions, etc
16:21:42 <fantasai> Probably just fire it when we fire a transition...?
16:21:45 <TabAtkins> liminzhu: so q about which appraoch
16:21:47 <astearns> is this analogous to animations firing on pseudo-class activation?
16:21:47 <TabAtkins> (yes)
16:22:03 <TabAtkins> liminzhu: also, `scroll-snap-haptic: effect intensity?`
16:22:09 <TabAtkins> liminzhu: triggers each time a snap happens
16:22:27 <TabAtkins> liminzhu: getting a tick when scrolling past stories on insta, for example
16:22:28 <flackr> q+
16:22:37 <TabAtkins> liminzhu: property is on snap container, not child
16:22:46 <TabAtkins> liminzhu: kbabbitt also told me about :snapped pseudoclass in the works
16:23:05 <TabAtkins> liminzhu: so we might want to just use that instead, another open q
16:24:00 <TabAtkins> liminzhu: [technical difficulties]
16:24:11 <lea> q+
16:24:46 <yanling> yanling has joined #css
16:26:30 <TabAtkins> emilio: the use of pseudo-classes... i'd like to get a better sense of hwo this integrates with transitions
16:26:49 <TabAtkins> emilio: the current appraoch of, presumably when the element gets this property it triggers the feedback
16:27:06 <TabAtkins> emilio: i think that's fine, but it raises the question - if you apply this prop to a thousand elements at once, what happens
16:27:39 <TabAtkins> emilio: so it feels like that needs a little more fleshing out. you toggle a class, suddenly multiple elements get this property with opposing values
16:27:50 <TabAtkins> emilio: i suppose youd' limit to what's under the pointer... but multiple coudl be there too
16:28:32 <TabAtkins> liminzhu: [is back]
16:28:47 <koji> koji has joined #css
16:29:04 <liminzhu> liminzhu has joined #css
16:29:40 <TabAtkins> liminzhu: so the q about pseudoclasses
16:29:45 <TabAtkins> liminzhu: it's a bit of a novel appraoch
16:29:51 <TabAtkins> liminzhu: an alternative is a transition-based haptics
16:30:01 <TabAtkins> liminzhu: you tie the haptics to a transition
16:30:14 <TabAtkins> liminzhu: fairly clean if you alreayd have a transition set up
16:30:14 <arronei> arronei has joined #css
16:30:42 <TabAtkins> liminzhu: but this is also tying a haptic to a transition. if all i care about is a bit of a haptic on a button click, artificially i need to add a transition to the element. maybe not what i want
16:31:08 <mjackson> mjackson has joined #css
16:31:10 <TabAtkins> liminzhu: i'm open to either doing transitions as a replacement or a future extension, both are okay
16:31:22 <TabAtkins> liminzhu: the rest of the alternative
16:31:43 <florian> q+
16:31:48 <TabAtkins> Zakim: html attributes, `<button haptic-on-activate=hint>` etc. so manya ttributes tho, not really better than css approach
16:32:06 <TabAtkins> liminzhu: haptic-on-snap, consider just using :snapped instead
16:32:18 <TabAtkins> liminzhu: priv/sec things
16:32:26 <TabAtkins> liminzhu: trying to avoid a new fingerprinting vector
16:32:31 <TabAtkins> liminzhu: so no querying about device functionality
16:32:38 <TabAtkins> liminzhu: or whether the haptic played
16:32:49 <TabAtkins> liminzhu: for security, people have been concerned about vibrate api
16:33:03 <TabAtkins> liminzhu: so i think UAs should be allowed in the spec to throttle as appropriate. UA-defined
16:33:19 <TabAtkins> liminzhu: shutting down bad websites entirely, or limit how often a normal website can do it
16:33:31 <TabAtkins> liminzhu: but also haptics aren't long-term harm. if a website vibes my mouse a lot, i can just close the site
16:33:41 <TabAtkins> liminzhu: assume people will just avoid harassing sites
16:34:04 <astearns> "just don’t use that site" isn’t a valid solution when sites are required (govt, etc.)
16:34:08 <TabAtkins> liminzhu: so i'm looking for feedback on proposal, on pseudoclass, on scroll-snap-haptic vs :snapped, etc
16:34:37 <TabAtkins> emilio: key thing to be defined is when exactly do you apply the haptic
16:35:01 <TabAtkins> emilio: other issue with this, say you do `*:focus { haptic-feedback: ...}|` and you're tabbing the document, you probably don't want haptic since you're using the keyboard
16:35:17 <TabAtkins> liminzhu: i think this is important, i might have buried this accidentally
16:35:39 <TabAtkins> liminzhu: especially for imperative, only want to play haptics when the user interaction si coming from a a haptic-capable input device
16:35:55 <TabAtkins> liminzhu: so if i'm tabbing, and my keyboard doesn't vibrate, i don't want to trigger a haptic on the mouse
16:36:18 <TabAtkins> liminzhu: haven't given enough thought to how that applies to the css version
16:36:23 <Rossen> ack emilio
16:36:29 <TabAtkins> emilio: that ties into my other feedback, what if mutliple haptics happen at the same time with different values
16:36:52 <TabAtkins> emilio: feels weird to access a global device (your haptic device) with something that can be activated from a bunch of palces independently
16:37:09 <TabAtkins> emilio: so if document style  changes in a way where two elements both get haptic feedback values, which do you take into account
16:37:35 <TabAtkins> liminzhu: don't have a great answer yet. restating: handle the triggering device well. And when multiple haptics trigger at once, which one wins.
16:37:38 <fantasai> scribe+
16:38:05 <Rossen> ack florian
16:38:10 <Rossen> ack flackr
16:38:14 <Rossen> q+ florian
16:38:19 <TabAtkins> flackr: i don't understand what it measn to say "this is a pseudoclass property"
16:38:34 <TabAtkins> flackr: this is just a css property. maybe it can onlyb e set in some pseudoclasses, but that's a different detail
16:38:39 <ydaniv> q+
16:39:01 <TabAtkins> flackr: if someone sets a haptic from one class, and another haptic from another class, is that a haptic trigger? or is like a transition and it might not go?
16:39:19 <TabAtkins> flackr: in the longterm people might write custom haptics, woudl be good to make sure we can do --name that hook into that
16:39:21 <dbaron> s/might not go/might not go if the computed value stays the same/
16:39:45 <TabAtkins> flackr: a lot of this sounds like css animations, when this property starts up we start an "animation". maybe we can lean on that. but emilio raised issues about it applying to too many elements
16:39:59 <Rossen> ack TabAtkins
16:40:07 <fantasai> TabAtkins: First point from flackr, about what exactly the triggering mechanism is
16:40:15 <fantasai> TabAtkins: Is it the existing transition machinery or something else
16:40:46 <fantasai> [flackr pointed out that if you have a haptic value on two different pseudo-classes, that won't trigger a transition so wouldn't be able to tell that there should be a change]
16:40:58 <fantasai> TabAtkins: ...
16:41:08 <fantasai> TabAtkins: Probably can't rely on transitions. Need something more like automatically determined animation name
16:41:22 <fantasai> TabAtkins: So you can distinguish distinct intents and trigger those even if property is applying?
16:41:26 <fantasai> TabAtkins: idk
16:41:55 <Rossen> ack lea
16:41:58 <TabAtkins> lea: first, huge +1 for the problem
16:42:09 <TabAtkins> lea: there was recent library that used horrible hacks for this, devs were v excited
16:42:22 <TabAtkins> lea: agree with flackr and tab about reusing animation machiner, that's closest precedent
16:42:36 <TabAtkins> lea: i don't think transitions are a good fit, not always changing other values
16:42:36 <fantasai> s/animation/animation-triger/
16:42:43 <fantasai> s/triger/trigger/
16:42:51 <TabAtkins> lea: i think it's weird matching on syntax and require authors to use a particular pseudoclass, don't have precedent for that
16:43:04 <TabAtkins> lea: authors also might be using JS-added classes to manage their states, don't want to rule that out
16:43:13 <liminzhu> liminzhu has joined #css
16:43:22 <TabAtkins> lea: for abuse we can rely on the sticky/throttle safeguards. authors shoudl bea ble to use what selectors they want
16:43:44 <TabAtkins> lea: i have some minor resolutions about the keywords, seem a little arbitrary and tied to what OSes currently do. a little concerned about how they extend into the future
16:44:00 <TabAtkins> lea: agree with flackr about custom haptics in the future. dunno if existing haptics are too different across OSes
16:44:06 <arronei> q+
16:44:13 <TabAtkins> lea: i'm not too worried about emilio's conflict resolution. i think we can come up with something reasonable.
16:44:25 <TabAtkins> lea: "haptic capable" was mentioned in passing, might need an MQ to detect that
16:44:38 <ydaniv> +1 to lea
16:44:39 <TabAtkins> lea: haptics might not be available for all sorts of reasons beyond the device itself being incapable
16:44:40 <ydaniv> q-
16:44:54 <TabAtkins> lea: woudl really like haptics to work without a separate snapping pseudo
16:44:55 <TabAtkins> q+
16:45:01 <TabAtkins> lea: so i like the :snapped idea
16:45:07 <ydaniv> q+
16:45:09 <lea> https://github.com/w3ctag/design-principles/issues/448
16:45:13 <TabAtkins> lea: i recall a TAG discussiona bout when APIs shoudl be hung on navigator
16:45:20 <TabAtkins> lea: the consensus was generally "don't"
16:45:30 <TabAtkins> (we don't have to stick with foolish consistency tho)
16:45:37 <TabAtkins> lea: but current .vibrate() is on nav
16:45:50 <flackr> q+
16:45:52 <TabAtkins> lea: another reason to not restrict to particular pseudoclass is we keep introducing new ones
16:45:57 <TabAtkins> lea: guaranteed to go out of sync
16:46:06 <TabAtkins> lea: but these are all nits, big +1
16:46:17 <TabAtkins> florian: i agree with various reasons for how this wouldn't work well as a transition effect
16:46:38 <TabAtkins> florian: also limiting to pseudoclasses is weird, for already stated reasons. but also might want a haptic when you transition *out*
16:47:20 <TabAtkins> florian: so leaning on more animation-like, might want to split it into an at-rule that defines an effect, conflict resolution, if it's a state you enter once (regardless of hwo many elements) or if it needs to fire each time, etc
16:47:27 <TabAtkins> florian: this is early, agree it's worth solving
16:47:34 <TabAtkins> flackr: need iteration on how to trigger it
16:47:39 <TabAtkins> s/flackr/florian/
16:47:40 <Rossen> ack flackr
16:47:45 <Rossen> ack florian
16:47:51 <TabAtkins> dbaron: one thought aobut triggering
16:47:51 <Rossen> ack dbaron
16:47:58 <Rossen> q+ flackr
16:48:25 <TabAtkins> dbaron: a problem Lea and Rob mentioned, maybe you want to trigger more than once as an element switches between states, no way to do that if it's about a property's computed value that jus tstays the same
16:48:42 <TabAtkins> dbaron: one thought it coudl give author a space to give a name, that name changing would be a computed-value change
16:48:54 <florian> +1
16:49:09 <TabAtkins> dbaron: that would probably let authors make choices about how often something triggers, what classes are same or different
16:49:33 <TabAtkins> dbaron: maybe there are some parallels with random()...
16:49:41 <TabAtkins> (this is what I was thinking...)
16:49:50 <TabAtkins> dbaron: some authors might want names per-element, others not
16:50:00 <TabAtkins> dbaron: maybe that's overboard. but occurred to me there might be a similarity there
16:50:23 <TabAtkins> arronei: as i was looking at this, i was thi8nking it's easy for a user to say "apply this to every element", how do we scope it down
16:50:40 <Rossen> ack arronei
16:50:48 <TabAtkins> arronei: some ways to think about this is, MQs can help scope it down. expanding it with... not using @keyframes but using something similar.
16:50:59 <TabAtkins> arronei: defining in vs out haptic firing, etc
16:51:27 <TabAtkins> arronei: last thing is the vocab - hint/edge/tick/align
16:51:48 <TabAtkins> arronei: these are similar concepts to border... something that is more in line with other properties. maybe a rename opportunity
16:52:04 <Rossen> ack TabAtkins
16:52:13 <fantasai> TabAtkins: I had a question, mentioned scroll snap haptic use case
16:52:21 <fantasai> TabAtkins: scrolling through a feed and getting ticks
16:52:29 <fantasai> liminzhu: Or scrolling through an album
16:52:36 <lea> q?
16:52:37 <fantasai> TabAtkins: We can't use :snapped pseudo-class for that
16:52:45 <fantasai> TabAtkins: This is more like scroll-snap-stop
16:53:07 <fantasai> TabAtkins: :snapped applies to the item
16:53:21 <fantasai> flackr: We apply :snapped as we scroll through
16:53:28 <fantasai> TabAtkins: We do? That ... seems ... strange
16:53:33 <fantasai> TabAtkins: If that's the case then that would work
16:53:45 <Rossen> ack ydaniv
16:53:49 <TabAtkins> ydaniv: Lea mentioned MQs for checking whether haptics are supported
16:54:10 <TabAtkins> ydaniv: didn't see in proposal an MQ checking for a user preference, whether they want haptics at all
16:54:13 <florian> q+ to comment on mediaqueries
16:54:16 <TabAtkins> `(prefers-haptics)`
16:54:24 <Rossen> ack florian
16:54:24 <Zakim> florian, you wanted to comment on mediaqueries
16:54:29 <Rossen> ack flackr
16:54:33 <Rossen> q+ florian
16:54:41 <TabAtkins> flackr: :snapped pseudo is impl'd in Chrome, might alreayd work
16:54:51 <TabAtkins> flackr: there's a non-interaction use-case i didn't see discussed
16:55:06 <TabAtkins> flackr: for notification-like haptics, a vibrate when a new message is added to a chat, or mentions you...
16:55:17 <TabAtkins> flackr: is that something we shoudl be discouraging, or supporting?
16:55:32 <TabAtkins> flackr: so are we allowing for just interaction-based, or allowing for attention-call?
16:55:55 <TabAtkins> liminzhu: in the explainer right now i'm scoping to interaction. attention is a lot more complexity, what haptic devices are available and what to fire on
16:56:03 <TabAtkins> liminzhu: i think we're not ready for that in v1
16:56:10 <TabAtkins> liminzhu: but if we see dev interest we can reconsider
16:56:20 <Rossen> ack florian
16:56:23 <TabAtkins> florian: the suggestion to use MQ is interesting
16:56:31 <lea> q?
16:56:33 <lea> q+
16:56:35 <TabAtkins> florian: if peopel are relying on haptics as *the* mechanism, kinowing that is good
16:56:49 <Rossen> Zakim, close queue
16:56:49 <Zakim> ok, Rossen, the speaker queue is closed
16:56:51 <TabAtkins> florian: but the presentation hiighlighted that on the JS side they deliberating don't give you a return value so you don't know if it worked, so there's a bit of tension
16:57:02 <lea> qq+
16:57:13 <TabAtkins> florian: but maybe we shouldn't encourage people to use haptics as primary. should maybe tell them to never rely on it being there, and always have some additional way to signal important things
16:57:19 <Kurt> Kurt has joined #css
16:57:25 <TabAtkins> florian: but there is indeed tension betwee convenience and the fingerprinting
16:57:31 <Rossen> ack lea
16:57:42 <TabAtkins> lea: the arg for the MQ isn't that authors would rely on it, but it's additiaonl point of feedback
16:57:53 <TabAtkins> lea: if the haptic isn't there they might need to provide other UI signals
16:58:03 <TabAtkins> lea:  if you know you can use haptics you can be more subtle in the UI
16:58:16 <TabAtkins> lea: another point mentioned earlier, extending .vibrate() was mentioned as an alt
16:58:32 <TabAtkins> lea: was rejected because it's a different signature. we could overload the signature, not insurmountable
16:58:36 <Rossen> ack fantasai
16:58:37 <TabAtkins> lea: might be good to reduce api surface
16:59:06 <TabAtkins> fantasai: i think webkit ahs concerns around abuse of the api, either harassing with too much
16:59:26 <TabAtkins> fantasai: so in addition to figuring out how it works with css, also concern with how to prevent websites causing problems for users
16:59:29 <TabAtkins> Rossen: +1
16:59:53 <lea> fantasai: Users are currently toggling hidden switches to emulate haptics in Safari. The fact that this is possible makes the argument a bit iffy
16:59:59 <TabAtkins> Rossen: do we want to resolve to take this as an ED?
17:00:11 <lea> +1 to take up as ED
17:00:21 <TabAtkins> Rossen: so proposed resolution is to add this to the charter
17:00:45 <TabAtkins> fantasai: want to get more feedback from my team
17:01:07 <TabAtkins> fantasai: proposal will need some reworking. not ready for an ED right now, but happy to keep working on it
17:01:26 <TabAtkins> florian: rossen do you mean "agree to work on it" or actually udpate the charter?
17:01:33 <TabAtkins> Rossen: agree to work on it
17:01:43 <astearns> +1 to agreeing to continue work on this, too soon for an ED imo
17:01:46 <TabAtkins> florian: agree with elika that accepting a draft is a little premature, but agreeing to work on it is good
17:01:54 <romain> romain has joined #css
17:02:04 <TabAtkins> liminzhu: sounds reasonable, lot of things to work on
17:02:13 <kbabbitt> +1
17:02:24 <TabAtkins> RESOLVED: accept haptics as a work item
17:02:32 <TabAtkins> (we should just add a github lable for it)
17:02:37 <liminzhu> thanks everyone!
17:02:45 <TabAtkins> (astearns could you add one)
17:02:55 <fantasai> SUMMARY: Proposal needs reworking based on points raised in the discussion, but there's interest in the topic.
17:03:05 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13689
17:03:05 <github-bot> Topic: Proposal: CSS Text Transitions & Animations
17:03:05 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13689
17:03:08 <Rossen> Zakim, open queue
17:03:08 <Zakim> ok, Rossen, the speaker queue is open
17:03:24 <TabAtkins> kbabbitt: basic problem i'm looking to solve is being able to do aniamtions/transitions at sub-element level
17:03:33 <TabAtkins> kbabbitt: becom epopular with some streaming text interfaces
17:03:39 <TabAtkins> kbabbitt: or loading animations with a shimmer effect
17:03:47 <TabAtkins> kbabbitt: authors have done this by dividing all the content into spans
17:03:55 <TabAtkins> kbabbitt: not great for perf, lots of excess style calc
17:04:00 <TabAtkins> kbabbitt: not good for a11y
17:04:14 <TabAtkins> kbabbitt: would be simpler for authors to have a few simple properties that achieve these effects
17:04:28 <TabAtkins> kbabbitt: alan pointed out this is a lot of work, yehonatan pointed out proposals for some of these things
17:04:32 <flackr> q+
17:04:40 <TabAtkins> kbabbitt: specifically grouping effects on element-by-element basis and sequencing these things
17:04:48 <TabAtkins> kbabbitt: syncing and choreographing animations
17:04:52 <TabAtkins> kbabbitt: can start with those
17:04:56 <TabAtkins> kbabbitt: need a few pieces still
17:05:01 <TabAtkins> kbabbitt: ref boxes for positional animations.
17:05:20 <TabAtkins> kbabbitt: transforms, if you blockify they're animating relative to the postiion of their block not their original position
17:05:27 <TabAtkins> kbabbitt: another, implicit assingment of group effects
17:05:38 <TabAtkins> kbabbitt: proposal was assinging ordinals to these elements
17:05:49 <ydaniv> q+
17:05:51 <TabAtkins> kbabbitt: would b enice to say "all of my children, assign everyone this animation"
17:05:59 <TabAtkins> kbabbitt: and the other effect is some way to segment text
17:06:17 <TabAtkins> kbabbitt: i don't want to get into a world where we're addressing text uinits with selectors. back where we started with style expense
17:06:25 <florian> q+
17:06:42 <TabAtkins> kbabbitt: so think we need some way of talking about text more generally that just applies transforms or animations
17:06:49 <TabAtkins> kbabbitt: addressing some issues, nested elements
17:06:59 <TabAtkins> kbabbitt: want animations to apply thru descendent elements to all text bits
17:07:13 <TabAtkins> kbabbitt: mutations of the text while animation is in progress...
17:07:20 <lea> q?
17:07:22 <lea> q+
17:07:24 <TabAtkins> kbabbitt: appending content is easy enough, replacing is trickier
17:07:30 <TabAtkins> kbabbitt: i'd probably just treat as a brand neew anim
17:07:44 <mjackson> mjackson has joined #css
17:07:45 <TabAtkins> kbabbitt: qs about generated content, and animation/transition events
17:07:55 <TabAtkins> kbabbitt: i think for compat sake we keep the events firing
17:08:23 <TabAtkins> kbabbitt: they'll fire at the end of all the text units
17:08:32 <TabAtkins> kbabbitt: so want to hear about concerns, if we're in the right direction, etc
17:08:35 <Rossen> ack flackr
17:08:48 <TabAtkins> flackr: we already have pseudo-elements for some pieces of text, ::first-letter/::first-line, etc
17:08:56 <TabAtkins> flackr: have you thought thru those? havne't considered expense
17:09:01 <TabAtkins> kbabbitt: expense is my main concern
17:09:17 <TabAtkins> kbabbitt: avoid ahving to do a full cascade, like ::nth-word(). even in non-animation potentially v expensive
17:09:20 <astearns> q+
17:09:28 <Rossen> ack ydaniv
17:09:35 <TabAtkins> ydaniv: i gave a few comments in the issue.
17:09:53 <TabAtkins> ydaniv: like kevin said, regarding sync/staggering/sequencing, i think it's something we want to solve more generally for animations
17:10:06 <TabAtkins> ydaniv: nothing currently regarding transitions, but we probably want to solve it there as well
17:10:26 <TabAtkins> ydaniv: regarding targeting text parts. all these libraries today split the text (hopefully with Intl.segmenter)
17:10:38 <TabAtkins> ydaniv: and then they wrap each part in a span
17:10:44 <TabAtkins> ydaniv: then make it inline-block
17:10:51 <TabAtkins> ydaniv: need to blockify everything so you get transforms
17:11:12 <TabAtkins> ydaniv: if we want to solve these effects we need to somehow blockify the components. then can do something like what rob suggested, have a way of targetting these parts
17:11:25 <TabAtkins> ydaniv: i know webkit jsut released a new inline-block engine
17:11:36 <fantasai> no, it was new implementation of block-splitting-inline-boxes code ...
17:11:37 <TabAtkins> ydaniv: i suggested something in the issue something like 'will-change:text-effects'
17:11:40 <fantasai> much less interesting :)
17:12:01 <TabAtkins> ydaniv: something that authors will use sparingly and UAs can maintain. if it's overused, maybe something the UA can control
17:12:10 <Rossen> ack florian
17:12:14 <TabAtkins> florian: havne't thought deeply, but i like the concept
17:12:28 <TabAtkins> florian: from i18n pov, there's considerable variation about letter vs word, especially word
17:12:47 <TabAtkins> florian: but word in english, chinese, japanese, thai all different. probably want to set it up so authros don't have to think too hard.
17:13:06 <TabAtkins> florian: a bunch of langs have space-seaprate words, not all. thai space-separates setnences, don't wnat to get sentences when you say "word"
17:13:28 <TabAtkins> florian: "word-level" is tricky but useful. do we want to spend time deffining this well, or is it too complex?
17:13:53 <TabAtkins> kbabbitt: one other reason i think about it this way, layout engine alreayd needs to know graphemes, ligatures, word breaks, line breaks
17:14:03 <TabAtkins> kbabbitt: so i'm hoping by using a higher-level concept we can just reuse that logic
17:14:25 <ntim> ntim has joined #css
17:14:26 <Rossen> ack lea
17:14:37 <ntim> p
17:14:38 <ntim> p+
17:14:45 <TabAtkins> lea: to florian, there is Intl.segmenter, UA already has these mechanics and exposes it to authors. presumably would do the same
17:15:21 <TabAtkins> lea: for transofrm effects, was mentioned it need to be blockified. a lot of effects weren't using transofrms, today could use highlight API, doens't need blockification
17:15:23 <ntim> present+
17:15:23 <castastrophe> florian: what would you think about alternative naming like “chunk” or “set”?
17:15:39 <TabAtkins> lea: am wondering if we can reduce the number of primitives, complexity is a common complaint
17:15:41 <fantasai> s/florian:/florian,/
17:15:54 <TabAtkins> lea: there is precedent today where we have pseudo-elements restricted to an allowlist of props
17:16:14 <TabAtkins> lea: wonder if it would alleviate perf concenrs to heavily limit the props allowed
17:16:34 <TabAtkins> lea: would be more extnesible in the future, while new primitives require us to edit the feature when we want to do mor epowerful
17:16:43 <TabAtkins> q+
17:16:45 <Rossen> ack astearns
17:16:55 <TabAtkins> astearns: i don't like thi sproposal, animating text is wrong and you shouldn't do it
17:17:06 <romain> +1
17:17:17 <TabAtkins> astearns: i do worry we could get into a sitaution where we're chasing a popular effect, and by the time it's specified/implemented the effect will be out of vogue
17:17:47 <TabAtkins> astearns: i did mention in the issue we should talk to the people with those libraries, might be low-hanging fruit that could make their scripting solution better
17:18:03 <ydaniv> +1 to astearns but I think text effects in general have been around for quite a while (:
17:18:05 <Rossen> ack fantasai
17:18:05 <Zakim> fantasai, you wanted to point at fill-stroke
17:18:15 <fantasai> https://drafts.csswg.org/fill-stroke/
17:18:27 <TabAtkins> fantasai: there is a fill-stroke spec that hans't seen much attention but would allow for some of the animation effects
17:18:39 <TabAtkins> fantasai: allows image fills, etc. might address some use-cases
17:19:11 <Rossen> ack TabAtkins
17:19:12 <ntim> brain dumping an idea: `text-effect: name 0.3s ease;`, `@starting-style { p::text-effect(name) { transform: scale(0); } }`
17:19:39 <fantasai> TabAtkins: Multiple people talked about :nth-word. I agree with kbabbitt, even if there weren't perf issues, I think the usability of the feature is better by having a dedicated system
17:19:49 <fantasai> TabAtkins: because of cases like appending vs adding, etc. We can't address in selectors.
17:19:58 <fantasai> TabAtkins: but a UA could handle how it wants to do all the animations in these cases
17:20:14 <fantasai> TabAtkins: So if we want to do this feature, it is best done with a special-case word animator, not via generic animations + pseudos
17:20:19 <Rossen> q?
17:20:38 <TabAtkins> (not disagreeing with what Tim just suggested, fwiw)
17:20:57 <TabAtkins> arronei: not disagreeing with Alan that the effect might be overused currently. but think we should continue with it to see what problems we run into
17:21:25 <TabAtkins> arronei: as we do, should make very careful to consider intl text. probably where we'll hit the most problems, not necessarily from impl concerns but from a user
17:21:42 <Kurt> prefers-reduced-motion should respect this, which should address a lot of concerns
17:21:52 <TabAtkins> +1 to Kurt
17:22:33 <TabAtkins> astearns: one comment on pref for solution that doen't use ::nth-word()/etc. could be fine but risks getting half the use-cases, but other half can't be extended to fit. so some amount of plumbing needs to be exposed, i think
17:23:03 <TabAtkins> Rossen: Hearing interest and concerns
17:23:27 <TabAtkins> Rossen: were you looking for a resolution, or just introing the concept?
17:23:34 <TabAtkins> kbabbitt: just presenting for now
17:23:53 <TabAtkins> <br dur=17min>
17:28:52 <sgill> sgill has joined #css
17:31:30 <Kurt> Kurt has joined #css
17:31:43 <hoch> hoch has joined #css
17:41:37 <Kurt> Kurt has joined #css
17:41:53 <Rossen> Rossen has joined #css
17:42:59 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13579
17:42:59 <github-bot> Topic: [animation-triggers-1] Proposal: toggle Custom States using Animation Triggers (`state-trigger`)
17:42:59 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13579
17:43:16 <sgill> sgill has joined #css
17:43:43 <TabAtkins> ydaniv: we've started work on animation-triggers. have timeline-trigger in chrome, working on event-trigger
17:43:55 <TabAtkins> ydaniv: these only allow us to change animation playback
17:44:22 <TabAtkins> ydaniv: there was previously work on state management with triggers, using CSS toggles. this didn't mature into an accepted proposal
17:44:36 <TabAtkins> ydaniv: this is trying to revive a similar concept, but building on things we already have accepted, like animation-triggers
17:45:00 <TabAtkins> ydaniv: idea is simple. we already have element stages, select via :state(), for custom elements
17:45:21 <TabAtkins> ydaniv: using JS you can add/remove strings from the state set, changes how :state() matches
17:45:29 <TabAtkins> ydaniv: proposal from Lea to extend this fucntional pseudo to all elements
17:46:08 <flackr> q+
17:46:10 <TabAtkins> ydaniv: building on that, this proposal suggests using triggers to have additional actions, a new property state-trigger
17:46:36 <TabAtkins> ydaniv: jumping to examples, lets you connect the name of a trigger and adjust states
17:47:06 <TabAtkins> ydaniv: `timeline-trigger: --on-screen view(); state-trigger: --on-screen add-state(--visible);`
17:47:13 <TabAtkins> ydaniv: then `:state(--visible)` will work
17:47:19 <lea> q+
17:47:29 <TabAtkins> ydaniv: today people use classes for this, or custom elements. this connects all of this together into a declarative api
17:47:45 <TabAtkins> ydaniv: proposal for three new actions - add-state(), remove-state(), toggle-state()
17:48:12 <TabAtkins> ydaniv: could also trigger these via an event-trigger
17:48:24 <TabAtkins> ydaniv: today you'd hack around this with animation triggers, or container state queries, etc.
17:48:35 <TabAtkins> ydaniv: so i think this i smore straightforward for binding these together
17:48:38 <TabAtkins> ydaniv: some open issues
17:48:57 <TabAtkins> ydaniv: biggest from a convo yesterday was there might be big a11y concerns, same as css toggle
17:49:16 <TabAtkins> ydaniv: but since people can do all this today with JS, probably still worth solving easier rather than blocking
17:49:33 <kbabbitt> q+
17:49:50 <TabAtkins> ydaniv: everything is bikesheddable
17:49:59 <TabAtkins> ydaniv: some questions about custom-ident vs dashed-ident...
17:50:11 <TabAtkins> ydaniv: whether we want later an imperative API like we have for animation triggers
17:50:12 <TabAtkins> q+
17:50:27 <Rossen> ack flackr
17:50:44 <TabAtkins> flackr: i believe this can be completely done with triggers and fill-forward animations, especially a once() trigger
17:50:53 <TabAtkins> flackr: so given that, is there a big ergonomic advantage to adding new stuff
17:51:11 <Rossen> ack lea
17:51:12 <TabAtkins> flackr: two, would like to see how people would buiold it today, don't thin kit's that much harder and i think it would help inform future solutions
17:51:20 <TabAtkins> lea: might have missed it - what about cycles?
17:51:45 <TabAtkins> lea: it seems state-trigger can set a state, then you can select base don the state, how do we avoid a cycle?
17:52:09 <TabAtkins> ydaniv: currently i started very simple to see if there are blocks in the way,
17:52:26 <lea> Avoiding cycles was the motivation for the design in #12502 btw, otherwise this is much more elegant
17:52:46 <lea> Sorry, https://github.com/w3c/csswg-drafts/issues/12502
17:52:51 <TabAtkins> ydaniv: to answer Rob, today it can even be a one-liner to hook up classes or data attributes in response to events. so it's easy today, but this is more declarative and easier
17:53:09 <TabAtkins> flackr: specifically waht i meant is, it's already easy to make a declarative animation trigger that applies a state when the naimation trigger happens.
17:53:13 <lea> q+
17:53:34 <TabAtkins> flackr: so they won't need to use JS anyway once we ship that. so the q is how much this is needed if we can just change styles with an animation
17:53:54 <TabAtkins> ydaniv: there are cases where you just want to change styles, not run an animation. entire animation api is sometimes a bit much
17:54:18 <TabAtkins> ydaniv: another use-case for the future is to have this as a declarative mechanism for trigger scoped view-transitions, maybe
17:54:29 <TabAtkins> kbabbitt: same question as Lea for cycles
17:54:32 <Rossen> ack kbabbitt
17:54:45 <TabAtkins> kbabbitt: there is some precedent for how we scope this in CQs to guard against that... maybe it won't solve the use-cases here
17:55:08 <fantasai> TabAtkins: I don't believe from this presentation that there's potential for cycles, but confusing from presentation
17:55:10 <Rossen> ack TabAtkins
17:55:22 <fantasai> TabAtkins: This isn't a property like animation-trigger that defines stuff for other things to rely on.
17:55:38 <fantasai> TabAtkins: This is just, "when some other trigger occurs, then we can adjust states on the element". Doesn't respond to a state changing.
17:55:46 <fantasai> TabAtkins: The property is not named correctly for that.
17:55:58 <fantasai> TabAtkins: It doesn't define a trigger. It defines a response, like animation-trigger listens for triggers.
17:56:08 <fantasai> TabAtkins: It's like animation-trigger, not the trigger-defining properties.
17:56:43 <castastrophe> q+
17:56:47 <fantasai> ydaniv: Exactly, state-trigger property is analogous to animation-trigger
17:56:56 <fantasai> ydaniv: i.e. where you *reference* the trigger
17:57:03 <fantasai> ydaniv: and define the reaction to it
17:57:23 <Rossen> ack lea
17:57:38 <fantasai> lea: Does this affect :state() ?
17:57:44 <yanling> yanling has joined #css
17:57:50 <fantasai> TabAtkins: Yes, it does, but it's not cyclic in the same way that timeline-triggers are not cyclic
17:58:08 <fantasai> TabAtkins: What do you think is cyclic about this? What's the scenario that would cycle?
17:58:25 <fantasai> Lea: Thought you could set state foo via selector, and then use that to remove it
17:58:40 <fantasai> TabAtkins: It's not defining a trigger. It's responding to a trigger that has been defined.
17:59:02 <fantasai> TabAtkins: When an existing trigger source happens. Currently you can run an animation in response to that.
17:59:07 <fantasai> TabAtkins: This would allow us to also adjust the state-set.
17:59:19 <fantasai> TabAtkins: It is not causing an event trigger, it is saying how do I respond to a timeline or event trigger.
17:59:32 <fantasai> TabAtkins: Several people confused, so wanted to clarify!
17:59:34 <ydaniv> thanks TabAtkins!
17:59:53 <TabAtkins> fantasai: this seems cool, but also i'm not sure CSS changing the state is at the right level of abstraction
18:00:08 <TabAtkins> fantasai: there was a concern about authors being able to modify the state set in a way that CE devs aren't expecting
18:00:09 <Zakim> fantasai, you wanted to raise https://github.com/whatwg/html/issues/11466#issuecomment-3386922777
18:00:13 <fantasai> https://github.com/whatwg/html/issues/11466#issuecomment-3386922777
18:00:26 <TabAtkins> fantasai: this was raised on previous proposal, think it still applies
18:00:29 <mjackson> mjackson has joined #css
18:01:02 <Rossen> ack castastrophe
18:01:08 <TabAtkins> castastrophe: I think there needs to be more use-cases described for this, but i'm intrigued from design system perspective
18:01:29 <TabAtkins> castastrophe: many times we were building component UI, wanted to assign state that doesn't exist in HTML in styles, but didn't want to to be responsible for the JS
18:01:44 <ydaniv> q+
18:02:03 <TabAtkins> castastrophe: so don't necessarily want to manage a bunch of classes, just want a view component to trigger that state
18:02:29 <TabAtkins> castastrophe: so i think this is very clean for design systems, engineers never want to add a million state-based classes but i do want to acknowledge there is state
18:02:34 <TabAtkins> castastrophe: but i do think we need more use-cases, yeah
18:02:41 <TabAtkins> castastrophe: figure out where JS plays into it
18:02:44 <Rossen> ack ydaniv
18:02:54 <TabAtkins> ydaniv: def agree with Cass
18:03:13 <TabAtkins> ydaniv: we've had a lot of these features built for a long time, rolling it out now packaged as design system states
18:03:35 <TabAtkins> ydaniv: so this is based on existing design system use-cases, just declarative way to avoid having to maintain state separately or with JS
18:04:09 <TabAtkins> fantasai: so i think i understood from the discussion...
18:04:16 <TabAtkins> fantasai: there was a concern aobut cyclic, appears there sin't
18:04:29 <TabAtkins> fantasai: concern about CEs ability to reason about themselves, since this is coming from a different source
18:04:38 <hoch> q+
18:04:44 <TabAtkins> fantasai: and the ability to have a declarative way to manage state you can select off of is useful
18:05:00 <Rossen> ack hoch
18:05:01 <TabAtkins> hoch: one q abuot conflict resolution
18:05:25 <TabAtkins> hoch: can have multiple triggers, would be good to clarify the behavior if the same trigger says to add and remove a state, etc
18:05:31 <arronei> q+
18:05:38 <Rossen> ack arronei
18:06:11 <TabAtkins> arronei: a little concerned about the bikeshedding that may need to happen to clarify these names to amke sure people udnerstand this *isn't* cyclic
18:06:21 <TabAtkins> (agree, the use of *-trigger for both sides fo the equation is kinda bad actually)
18:06:30 <TabAtkins> arronei: so might be good to bikeshed the names)
18:06:41 <fantasai> TabAtkins: How locked-in are we on the name 'animation-trigger'?
18:07:02 <fantasai> TabAtkins: it's confusing that it's the opposite side of 'event-trigger' and 'timeline-trigger'
18:07:14 <fantasai> TabAtkins: The more we do stuff in this space the more confusing it's going to be
18:07:28 <fantasai> TabAtkins: We should come up with a better naming system
18:07:44 <arronei> random bikeshedding, *-hook, *-link, *-use, .....
18:07:57 <fantasai> TabAtkins: that makes it clearer whether we are defining or using the trigger
18:08:05 <astearns> *-trigger-response
18:08:17 <TabAtkins> Rossen: so there's clearly some interest in this
18:08:28 <TabAtkins> Rossen: and everything is bikesheddable, so that's ncie
18:08:35 <fantasai> I wonder if just swapping between trigger- and -trigger would help?
18:08:36 <TabAtkins> Rossen: how do we want to take this forward?
18:08:57 <kbabbitt> triggers-animation / triggers-state-change ?
18:08:58 <fantasai> ydaniv: good feedback. I was more concerned wrt a11y stuff, but nothing concrete yet
18:09:00 <TabAtkins> ydaniv: i guess we can continue on the issue
18:09:13 <TabAtkins> (we really want animatino-trigger to live in the animation-* namespace if possible)
18:09:24 <fantasai> ydaniv, might be useful to reach out to the a11y group?
18:09:27 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13733
18:09:27 <github-bot> Topic: Can we enable polls in this repo?
18:09:27 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13733
18:09:38 <astearns> q+
18:09:45 <TabAtkins> lea: we've often done social media polls. github actually supports polls in Discussions
18:09:58 <TabAtkins> lea: then we could send people to vote there instead of having separate polls
18:10:01 <castastrophe> +1
18:10:13 <TabAtkins> lea: woudl make it easier, and add some legitimacy to the polls too
18:10:13 <kbabbitt> +1
18:10:22 <TabAtkins> lea: could enable it, but wanted group feedback first
18:10:38 <TabAtkins> lea: nicer than social media polls too, can add a lot more context and aren't length limited
18:10:39 <TabAtkins> +1
18:11:12 <TabAtkins> astearns: I went looking at what we need to do, seems I have the power to enable discussions
18:11:18 <TabAtkins> astearns: they were disabled, dont' recall why
18:11:26 <Rossen> ack astearns
18:11:29 <TabAtkins> ChrisL: I think they were disaabled deliberately after repo was started
18:11:46 <TabAtkins> ChrisL: there's a dark pattern where people don't want issues, so they turn them off and open discussions. as long as we don't do that it's fine
18:12:06 <TabAtkins> fantasai: let's just make sure to keep discussion in issues, not in discussions
18:12:32 <TabAtkins> Rossen: with caveat about needing a GH account...
18:12:35 <miriam> some social media platforms (like bluesky) don't even have a poll feature
18:12:51 <TabAtkins> TabAtkins: they need a GH account to comment on issues anyway
18:12:55 <TabAtkins> Rossen: quick vote
18:12:56 <ChrisL> +1
18:12:59 <castastrophe> +1
18:12:59 <lea> +1
18:13:01 <Kurt> +1
18:13:02 <ydaniv> +1
18:13:02 <miriam> +1
18:13:02 <fantasai> +1
18:13:04 <dshin> +1
18:13:21 <TabAtkins> RESOLVED: Turn on polls in github
18:13:33 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13663
18:13:33 <github-bot> Topic: [css-gaps-1]:  Assigning multiple decoration values to flex containers
18:13:33 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13663
18:14:57 <TabAtkins> javierct: [shows issue pictures]
18:15:02 <TabAtkins> javierct: we ahd a gap breakout recently
18:15:21 <TabAtkins> javierct: to recap, several properties that let us declare style/width/color to gap decos as a list
18:15:29 <TabAtkins> javierct: for flex specifically, how do we want them to apply
18:15:52 <TabAtkins> javierct: assume column-rule-color: red, blue, green, yellow
18:16:13 <TabAtkins> javierct: first assumption was that each rule in order cycled those values
18:16:20 <TabAtkins> javierct: another possiblity is we reset the count on each line
18:16:44 <TabAtkins> javierct: lots of discussion in the issue
18:16:45 <mjackson> mjackson has joined #css
18:16:48 <TabAtkins> javierct: wanted more feedback
18:16:53 <sgill> sgill has joined #css
18:17:02 <TabAtkins> javierct: i think convo pointed to linear behavior (continuous count across lines)
18:17:08 <TabAtkins> javierct: wanted more thoughts
18:17:12 <kbabbitt> q+
18:17:21 <Rossen> ack kbabbitt
18:17:25 <arronei> q+
18:17:34 <TabAtkins> kbabbitt: i think all the comments we got on social media were in favor of linear, not per-line reset. happy to resolve on that
18:17:36 <fantasai> sgtm, kbabbitt
18:17:42 <TabAtkins> linear sounds fine to me
18:17:42 <Rossen> ack arronei
18:17:52 <TabAtkins> arronei: hm, i was thinking i woudl want reset as a user...
18:18:01 <TabAtkins> arronei: if we define it one way someone will want the other
18:18:06 <TabAtkins> arronei: could we control it?
18:18:14 <miriam> q+
18:18:31 <TabAtkins> kbabbitt: we could indeed add a toggle, just use linear by default
18:18:32 <Rossen> ack fantasai
18:18:42 <TabAtkins> fantasai: one, i'd prefer to avoid a toggle if we can. one more thing to deal with
18:19:01 <TabAtkins> fantasai: advantage of linear, if you do want per-line you can often use grid instead
18:19:12 <TabAtkins> fantasai: so going with linear for flexbox seems reasoanble, especially if feedback was strong for it
18:20:06 <TabAtkins> fantasai: two, if we're going with linear... if you have five items all in one line, gaps are red, orange, yellow, green. If you break between items 2 and 3, is orange gap moved to the next gap or is it dropped?
18:20:24 <TabAtkins> fantasai: i feel like you'd want it dropped, so a color association wouldn't break depending on the break point
18:20:49 <TabAtkins> fantasai: so aka, if a "gap" is actually a break, we still consume that entry in the gap styling
18:20:50 <Rossen> ack miriam
18:21:07 <TabAtkins> miriam: i was also gonna say i think there's an advantage to not matching grid, because we already have grid if you need it.
18:21:13 <TabAtkins> miriam: i like the linear appraoch
18:21:15 <kbabbitt> q+
18:21:28 <astearns> “just use grid” … “But I want per-line resets *and* flex sizing!!”
18:21:37 <TabAtkins> miriam: i'm a little worried about people trying to corrleate a gap with an item. they aren't actually correlated, if that's what you want you shoudl use a border or something
18:21:46 <Rossen> ack kbabbitt
18:21:50 <TabAtkins> miriam: but i agree with fantasai that if that's what you want you probably do want to drop at the wrap
18:22:17 <TabAtkins> kbabbitt: yeah, style is assigned to the gap itself, not the item... shoudl use a border or something
18:22:21 <dholbert> q+
18:22:37 <TabAtkins> fantasai: problem is border is never dropped
18:22:46 <TabAtkins> fantasai: you still just want to render gaps when actually needed
18:22:53 <TabAtkins> fantasai: but maintain the style association
18:23:00 <sgill> sgill has joined #css
18:23:13 <TabAtkins> kbabbitt: i think if you want the deco associated with the item, i'm unsure about th euse-case for dropping it
18:23:49 <TabAtkins> fantasai: say you ahve a toolbar, and you ahve sections. first two items are together, next three are togeether. so you want a larger gap  between the groups. You make a size pattern that's thin, thick, thin, thin
18:24:11 <TabAtkins> fantasai: and if it breaks, you don't want the thick gap to show up in the middle of a group instead
18:24:27 <TabAtkins> fantasai: to the extent that we're creating this association and wrapping it, i think we need to maintain that. don't see a reason to not do it
18:24:53 <TabAtkins> fantasai: if we were doing line reset model, then yeah, doesn't matter. but since we are continuing across lines, we should keep them associated
18:25:08 <TabAtkins> kbabbitt: so you're suggesting that at the end of each line there's a decoaration *assigned* but not painted (since there's no gap)
18:25:12 <TabAtkins> fantasai: yes
18:25:18 <TabAtkins> dholbert: I'm in favor of linear model.
18:25:18 <Rossen> ack dholbert
18:25:33 <TabAtkins> dholbert: i see the use-case fantasai is describing but it seems strange to want that behavior....
18:25:49 <TabAtkins> dholbert: if i just want these four colors to repeat between my items, and one is missing due to a break, i'm gonna be somewhat confused
18:26:08 <oSamDavis> oSamDavis has joined #css
18:26:11 <alisonmaher> q+
18:26:17 <TabAtkins> dholbert: so if a color is associated with each item, sure, it makes sense, but just a pile of flex items with a pile of colors, i think it would be weird if a color gets mysteriously consumed
18:26:30 <TabAtkins> fantasai: i think we need to udnerstand better what people want different gap decos for in a flexbox
18:26:38 <TabAtkins> fantasai: so we can decide waht they actually want
18:26:41 <Rossen> ack alisonmaher
18:26:55 <TabAtkins> alisonmaher: +1 to dholbert . if you have the same number of items per line so the same one gets dropped each time, that might be confusing...
18:27:02 <TabAtkins> alisonmaher: but we could have it as an opt-in
18:27:16 <TabAtkins> fantasai: i'm open to doing whatever behavior but i think we're tlaking a lot in theory here
18:27:20 <kbabbitt> q+
18:27:27 <Rossen> ack kbabbitt
18:27:36 <TabAtkins> fantasai: we've seen demos of how it works, but not real use-cases where authors would acctually want gap decos to repeat in a flexbox
18:27:51 <TabAtkins> kbabbitt: i do think having varying decos makes more sense in grid, like separating heading columsn from body
18:27:58 <TabAtkins> kbabbitt: we just have to answeer what it means on a flexbox
18:28:02 <TabAtkins> q+
18:28:12 <TabAtkins> fantasai: right so i think we do need real use-cases for an answer
18:28:22 <TabAtkins> arronei: i don't, myself, see myself ever using different colors really
18:28:32 <Rossen> ack TabAtkins
18:28:38 <fantasai> TabAtkins: I think this is best answered with real-world cases
18:28:56 <fantasai> TabAtkins: But also the use-case for grid does indicate that, to the extent that you're varying the decorations, it's a semantic association with the stuff in the grid
18:29:08 <fantasai> TabAtkins: other than zebra-striping, often you want to set up different styling based on the content
18:29:15 <fantasai> TabAtkins: which suggests to me that we should lean in fantasai's decoration
18:29:28 <fantasai> TabAtkins: and assume that if the gaps vary, there is likely to be a semantic association
18:29:33 <fantasai> TabAtkins: such that we should maintain that association across breaks
18:29:38 <arronei> +1 for more real use case examples
18:29:43 <fantasai> TabAtkins: But looking for more legitimate use cases would help answer that question
18:30:18 <TabAtkins> kbabbitt: shoudl we just resolve on the issue question - per line vs linear?
18:30:22 <TabAtkins> Rossen: that we can do
18:30:33 <fantasai> PROPOSED: Adopt linear assignment. Investigate whether to drop the gap coinciding with the break.
18:30:44 <fantasai> RESOLVED: Adopt linear assignment. Investigate whether to drop the gap coinciding with the break.
18:31:01 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13477
18:31:02 <github-bot> Topic: [css-gaps-1] Decorations between empty areas: default behaviors
18:31:02 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13477
18:31:24 <TabAtkins> javierct: similar to previous, we discussed this earlier and want more feedback now for the default behavior
18:31:42 <TabAtkins> javierct: so for context, we have empty-areas behavior,
18:32:01 <TabAtkins> javierct: multicol currently the default beahvior is "between", only gaps between filled columns will show up
18:32:15 <TabAtkins> javierct: currently spec default is "all", which conflicts
18:32:24 <TabAtkins> javierct: two things to resolve.
18:32:32 <TabAtkins> javierct: first, should initial bheavior be "between" also for grid?
18:32:35 <TabAtkins> javierct: if yes, that's easy
18:32:42 <TabAtkins> javierct: if no, we might need an "auto" keyword
18:32:53 <TabAtkins> javierct: so we need to decide on whether grid's default bheavior is "all" or "between"
18:33:09 <TabAtkins> javierct: [shows example of "all" and "between" in variously-filled grids]
18:33:25 <TabAtkins> javierct: currently our default is "all", author feeedback suggests it's useful
18:33:38 <miriam> q+
18:33:40 <TabAtkins> javierct: but there was a lot of discussion about possibly wanting "between", the multicol behavior
18:33:43 <Rossen> ack miriam
18:34:04 <kbabbitt> +1 miriam
18:34:09 <TabAtkins> miriam: I think i've come around to "all", not becuase I think it's most often used, but becaus ei'm not sure there is a most often value. "all" is visible in an empty grid, which is useful visually
18:34:31 <TabAtkins> (i weakly agree)
18:34:42 <TabAtkins> Rossen: proposal for Grid's default beahvior is "all"
18:34:44 <TabAtkins> Rossen: objections?
18:34:59 <TabAtkins> RESOLVED: Default Grid behavior for grid empty spaces is "all"
18:35:13 <TabAtkins> javierct: so then the initial value needs to be "auto" so it can be "all" vs "between"
18:35:35 <TabAtkins> fantasai: should probably be "normal", we use that to vary gap insets too
18:35:39 <kbabbitt> sgtm
18:35:56 <TabAtkins> RESOLVED: Change the initial value to "normal", resolves similarly to the other property
18:36:04 <github-bot> Topic: [css-gaps-1] `overlap-join` with `between` rule visibility
18:36:35 <TabAtkins> kbabbitt: at gap breakout we resolved to add overlap-join keyword
18:36:45 <TabAtkins> kbabbitt: when you have decos in crossing directions they overlap
18:37:05 <TabAtkins> kbabbitt: while implementing that, there's a weird edge cases about "between"
18:37:19 <TabAtkins> kbabbitt: because overlap-join takes you to the intersection, you get a little bit sticking out
18:37:34 <TabAtkins> kbabbitt: my reaction when I saw it is this is wrong, and we should leave the deco flush with the remaining items
18:37:46 <TabAtkins> kbabbitt: do people think authors would want this sticking out, or should we trim?
18:37:53 <TabAtkins> kbabbitt: when there's no intersecting deco?
18:37:53 <miriam> q+
18:38:03 <TabAtkins> fantasai: I think your heuristic makes sense to me
18:38:09 <Rossen> ack miriam
18:38:11 <TabAtkins> miriam: would trimming be the same as what you do at the edge of the grid?
18:38:16 <TabAtkins> kbabbitt: yes, effectively
18:38:20 <florian> q?
18:38:27 <TabAtkins> miriam: if so, yeah, doesn't feel as magical
18:38:32 <fantasai> But it gets weird here: https://github.com/w3c/csswg-drafts/issues/13697#issuecomment-4101453468
18:38:54 <TabAtkins> kbabbitt: specifically, it means that overlap-join extends the decoration when there is a decoaration to join with, and doesn't when there's not
18:39:07 <hoch> q+
18:39:07 <florian> q+
18:39:31 <TabAtkins> kbabbitt: [shows another example of the gaps extending or not]
18:39:55 <TabAtkins> fantasai: given this illustration i think we don't want to trim it flush
18:40:04 <TabAtkins> TabAtkins: i disagree, i htink trimming would look good
18:40:53 <TabAtkins> kbabbitt: [shows an example of what it would actually look like]
18:41:17 <astearns> +1 to trimming (treating gap-less sections as grid edges makes sense to me)
18:41:22 <TabAtkins> miriam: going back to the previous image, there was a q about top and bottom... you said it would trim the top and not the bottom?
18:41:39 <TabAtkins> kbabbitt: it would trim the tops of all lines, and the bottom of this lone line, but not the bottom of these others that area cctually joining
18:41:44 <Rossen> ack hoch
18:42:01 <TabAtkins> hoch: i'm wondering if this beahvior... would it be better to address this by changing the definition of what the outside is?
18:42:25 <TabAtkins> hoch: if we make this magic only apply to the join keyword, if authors want it for a not-quite-overlapping join they can't get it
18:42:47 <TabAtkins> hoch: so what if we defined this as making these edges count as "outside" edges?
18:43:10 <TabAtkins> kbabbitt: we can indeed define edges from interior insets
18:43:26 <fantasai> +1 hoch
18:43:27 <TabAtkins> hoch: right so what if instead of changing this keyword, we change the definition of which corners are edge vs interior
18:43:44 <TabAtkins> hoch: in these cases they are "edge" insets rather that interior ones
18:43:49 <miriam> +1 that's what I was trying to get at as well
18:44:06 <TabAtkins> kbabbitt: let me restate
18:44:27 <TabAtkins> kbabbitt: suggestion is to have differentiated inset properties based on whether there's an intersection or not?
18:44:30 <TabAtkins> hoch: yes
18:44:35 <Rossen> ack florian
18:44:41 <TabAtkins> florian: havne't thought about this latest variant... but until that point i think it made sense
18:45:05 <TabAtkins> florian: the various examples differed in how wrong they felt, some could go either some were def wrong, but they were all at least somewhat better with the "fixed" behavior
18:45:12 <Rossen> ack fantasai
18:45:12 <Zakim> fantasai, you wanted to say this also allows more control
18:45:25 <TabAtkins> fantasai: i think hoch's propopsal makes sense for antoher reason, you might not want those perfectly flush, might want them inset or outset a bit
18:45:33 <TabAtkins> fantasai: by defining them as an exterior join you get that control
18:46:14 <TabAtkins> arronei: i think it could lend to future designs we were talking about during break, corner joins being defined differently (rounded, chamfered, etc)
18:46:22 <fantasai> PROPOSED: Define ends of segments that do not join to an intersection to be "exterior" insets (which can be controlled as such).
18:46:24 <TabAtkins> arronei: so as we separate this out a bit it might lead to taht future work
18:46:57 <fantasai> TabAtkins: overlap-join keyword, which property?
18:47:03 <fantasai> kbabbitt: the inset properties
18:47:17 <fantasai> TabAtkins: those have edge/interior/start/end?
18:47:18 <fantasai> kbabbitt: yeah
18:47:31 <fantasai> TabAtkins: So if we have this behavior, then this wouldn't be controlled by the inset property
18:47:34 <fantasai> fantasai: It could be
18:47:54 <fantasai> kbabbitt: If we want a different offset, then it may be a separate property. Or maybe a separate ?
18:48:12 <TabAtkins> fantasai: if you already ahve edge vs interior, you'd set interior to overlap-join and the exterior to 3px
18:48:31 <fantasai> TabAtkins: Ah, thought we would add a new property to enable that
18:48:36 <fantasai> TabAtkins: but if they're always exterior joins ...
18:48:52 <fantasai> TabAtkins: and then overlap-join would be specifiable for any interior join then that's ok
18:49:08 <TabAtkins> fantasai: so if you set interior and exterior to overlap-join, you'll get an outset at the edges
18:49:46 <TabAtkins> alisonmaher: would you really want the exterior edge to extend out?
18:49:56 <TabAtkins> fantasai: yes. i imagine you'd want that?
18:50:43 <TabAtkins> fantasai: i think if you want an outset of 3px at these "no item" "interior" corners, you probably want it on the actual exterior corners too
18:51:25 <TabAtkins> fantasai: i can imagine for the shorthand, if you just said "overlap-join" we'd default that to the interior and give exterior a 0 default
18:51:35 <fantasai> TabAtkins: and then overlap-join would be specifiable for any interior join then that's ok
18:51:55 <fantasai> (oops sorry mispasted)
18:52:10 <TabAtkins> (this is definitely running into my "there are about 20 types of joins" problem with defining gap-image)
18:52:29 <TabAtkins> kbabbitt: i see where the train of thought is going... i think i need to whiteboard this out and think about it
18:52:53 <fantasai> Rossen: So proposal: define ends of segments that do not join to an intersection to be "exterior" insets (which can be controlled as such).
18:53:01 <fantasai> TabAtkins: Maybe just "trim those by default"?
18:53:03 <oSamDavis> I think the issue is that there's no separate edge-interior property, so controlling edge controls all edges
18:53:13 <TabAtkins> yeah that's my concern too, oSamDavis
18:53:33 <TabAtkins> there is https://drafts.csswg.org/css-gaps/#insets-edge-interior for inside vs outside
18:53:36 <alisonmaher> +1 we'd need separate controls for that likely
18:53:51 <TabAtkins> fantasai: if all your other edges aren't flush it's unlikelly you want these to be flush
18:54:07 <TabAtkins> kbabbitt: I think i'm good with TAb's higher-level resolution
18:54:20 <fantasai> PROPOSED: Trim the unjoined segments. TBD how exactly that should work.
18:54:40 <fantasai> RESOLVED: Trim the unjoined segments. TBD how exactly that should work.
18:54:54 <noamr> noamr has joined #css
18:56:09 <TabAtkins> github-bot, end topic
18:56:23 <TabAtkins> <br dur=64min>
19:03:51 <ydaniv> present-
19:24:08 <stevenspriggs> stevenspriggs has joined #css
19:33:38 <SebastianZ> SebastianZ has joined #css
19:39:32 <alisonmaher> alisonmaher has joined #css
19:58:19 <Rossen> Rossen has joined #css
19:58:31 <arronei> arronei has joined #css
19:58:37 <emilio> scribe+
19:59:02 <github-bot> Topic: [css-gaps-1]:  Assigning multiple decoration values to flex containers
19:59:12 <Rossen> Topic: https://github.com/w3c/csswg-drafts/issues/13588
19:59:13 <hoch> hoch has joined #css
19:59:26 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13588
19:59:26 <github-bot> Topic: [css-sizing][responsive-iframe] Should `frame-sizing` apply to SVG contents?
19:59:26 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13588
19:59:29 <Rossen> github, take up https://github.com/w3c/csswg-drafts/issues/13588
20:00:01 <alisonmaher> alisonmaher has joined #css
20:00:15 <emilio> koji: so frame-sizing was discussed on the last f2f, I've updated the spec in response to that discussion
20:00:30 <emilio> ... filed three issues with some investigation I did
20:01:22 <emilio> ... I didn't see clear preferences either way on whether to apply to SVG
20:01:27 <emilio> ... SVG has some magic behavior
20:01:34 <Kurt> Kurt has joined #css
20:01:43 <iank_> iank_ has joined #css
20:01:47 <emilio> ... they have use cases so I'd prefer not to mess with that
20:01:47 <emilio> q+
20:01:50 <TabAtkins> +1
20:02:09 <TabAtkins> emilio: When you  say 'applyl to SVG', I think SVG only has magic for object and embed
20:02:16 <TabAtkins> emilio: do you mean only apply it to iframe?
20:02:21 <Kurt> q+
20:02:28 <TabAtkins> emilio: or to object/embed too, but not when they're SVG?
20:02:40 <TabAtkins> koji: object/embed is another issue, i propose only iframe
20:02:40 <Rossen> ack emilio
20:02:42 <emilio> koji: my proposal is only for iframe
20:03:25 <fantasai> TabAtkins: question is about whether to apply frame-sizing to SVG in <iframe>
20:03:43 <fantasai> emilio: Currently it uses 300 x 150 default
20:03:53 <fantasai> emilio: If the overall proposal applies to iframes ...?
20:04:04 <fantasai> TabAtkins: SVG doc in an <iframe>. Not <object>
20:04:09 <fantasai> emilio: There's no magic behavior there.
20:04:17 <fantasai> TabAtkins: So should we introduce the magic behavior into the <iframe>
20:04:24 <fantasai> emilio: No it should behave like an HTML doc
20:05:00 <fantasai> emilio: I think what Koji's proposing is that SVG inside an <iframe> is not magic, so it doesn't get special behavior when `frame-sizing` is used
20:05:11 <fantasai> emilio: If SVG opted in via this method, then it would get the same behavior as HTML.
20:05:20 <fantasai> emilio: So no auto-magic measuring for SVG.
20:05:33 <Rossen> ack Kurt
20:05:34 <fantasai> PROPOSED: `frame-sizing` has the same effect on SVG in <iframe> as it does for HTML in <iframe>
20:05:36 <emilio> Kurt: I think it's best to resolve that
20:05:47 <emilio> ... SVG behaves more like images except for <iframe>
20:06:45 <emilio> PROPOSED: SVG documents in iframes don't have frame-sizing effect
20:07:09 <fantasai> TabAtkins: SVG doesn't have meta tags so can't opt into special behavior
20:07:15 <dholbert> dholbert has joined #css
20:07:16 <fantasai> emilio: You can put a meta tag into an SVG.
20:07:26 <fantasai> [ discomfort ]
20:07:33 <fantasai> emilio: Meta with color-scheme works.
20:07:36 <fantasai> TabAtkins: It does?
20:07:49 <fantasai> PROPOSED: frame-sizing on an iframe only works for HTML documents
20:07:58 <Rossen> ack fantasai
20:08:12 <emilio> fantasai: I feel like if you manage to opt it in, shouldn't it work the same way?
20:08:23 <emilio> ... why would we make SVG documents different just because it's svg?
20:08:27 <emilio> +1
20:08:35 <fantasai> TabAtkins: can't opt it in
20:08:59 <fantasai> TabAtkins: [because rules]
20:09:21 <emilio> TabAtkins: because frame sizing only applies until `</head>`
20:09:38 <emilio> fantasai: but the opt in not working is different from the property doesn't apply
20:10:04 <TabAtkins> (even with <html:meta> in SVG, the meta is "frozen" early (by the end of </head>) and there is no <head> in SVG to scope its parsing to)
20:10:04 <emilio> TabAtkins: we're resolving it's not a problem for now, i.e., there's no way for an SVG doc to get frame-sizing behavior
20:10:07 <fantasai> `frame-sizing` does not have an effect on SVG that hasn't opted in (which it currently can't)
20:10:14 <TabAtkins> (Unlike other <html:meta>s like color-scheme)
20:10:51 <emilio> PROPOSED: Currently SVG in iframe doesn't respond to frame sizing (because you can't opt it in)
20:11:08 <emilio> RESOLVED: Currently SVG in iframe doesn't respond to frame sizing (because you can't opt it in)
20:11:10 <fantasai> +1 emilio
20:11:37 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13584
20:11:37 <github-bot> Topic: [css-sizing][responsive-frame] Should `frame-sizing` apply to `<object>` elements?
20:11:37 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13584
20:12:10 <emilio> koji: so the other issue is whether it should apply on `<object>` / `<embed>`. For now we want to apply only to `<iframe>`
20:12:17 <emilio> q+
20:12:43 <emilio> Rossen: HTML seems to trend in that direction
20:12:52 <Rossen> ack emilio
20:12:59 <TabAtkins> emilio: seems fine, but can you remind me... is it frame-sizing: content?
20:13:01 <TabAtkins> TabAtkins: something liek that
20:13:21 <TabAtkins> emilio: i guess it's not a big issue to add object in the future, or do frame-sizing:none on an object/embed with SVG...
20:13:44 <TabAtkins> emilio: so should the initial value be 'auto'? so we can make 'none' work in the future?
20:13:58 <TabAtkins> emilio: 'auto' just seems more future proof
20:14:11 <TabAtkins> fantasai: i think since it's the initial value we can probably swap it in or out
20:14:14 <emilio> fantasai: we can probably swap the initial value in or out
20:14:29 <emilio> koji: there's an issue about auto from the january f2g
20:14:33 <iank_> https://drafts.csswg.org/css-sizing-4/#responsive-iframes
20:14:33 <emilio> f2f*
20:14:33 <koji> https://drafts.csswg.org/css-sizing-4/#responsive-iframes
20:14:43 <Rossen> Jan 27: RESOLVED: Define frame-sizing with various height and with keywords, with default of auto
20:14:49 <TabAtkins> (initial value is 'auto', there isn't a 'none' value at all yet)
20:15:06 <TabAtkins> emilio: okay, so if we want to add 'none' in the future that'll be safe
20:15:13 <emilio> PROPOSED: frame-sizing doesn't apply to <object> / <embed>
20:15:20 <emilio> RESOLVED: frame-sizing doesn't apply to <object> / <embed>
20:15:37 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13589
20:15:38 <github-bot> Topic: [css-sizing][repsonsive-iframe] The behavior when content navigates out
20:15:38 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13589
20:15:55 <emilio> koji: smfr pointed out that we should define what happens when content navigates
20:16:22 <emilio> ... when content navigates in the iframe gets the natural size from it
20:16:43 <emilio> ... but when navigating out we can set to initial size, or keep the previous size
20:16:52 <TabAtkins> q+
20:16:57 <emilio> ... keeping is more natural from a user POV but can leak previous content size to the new content
20:17:10 <emilio> ... resetting stops that, but it can cause the size to jump
20:17:25 <emilio> ... we think we prefer to keep the last size
20:17:27 <iank_> (note the leak already somewhat happens with polyfills of this feature)
20:17:27 <emilio> q+
20:17:47 <emilio> ... it potentially leaks some information tho
20:17:50 <Rossen> ack TabAtkins
20:18:02 <emilio> TabAtkins: You wouldn't be able to tell that the size comes from anywhere else right?
20:18:39 <emilio> ... if you resize an iframe that's the size you get so you can't distinguish it
20:18:49 <emilio> ... worst case we could distinguish same vs. cross-origin navs
20:18:58 <emilio> ... but it should be fine to preserve the size I think
20:19:20 <TabAtkins> emilio: is the risk here... if th enavigation is triggered by the frame itself, it can already communicate that info
20:19:32 <TabAtkins> emilio: if nav is triggered by parent, parent can also communicate
20:19:51 <TabAtkins> emilio: so it seems to me, the reason this is aleady exposed in the polyfill is because the parent is coordinate the size
20:19:58 <TabAtkins> emilio: and at that point the comm channel is the embedder, the parent page
20:20:17 <TabAtkins> emilio: i dont' think you can communicate something with this that you couldn't comm via the query string, if the iframe is navigating itself
20:20:28 <TabAtkins> emilio: am i missing something?
20:20:34 <TabAtkins> emilio: so whats' the risk otherwise?
20:20:39 <TabAtkins> emilio: I guess an unintentional leak
20:20:48 <TabAtkins> emilio: but then you can't distinguish it from the page setting the size
20:21:09 <TabAtkins> ian: I think if we don't do it people will add a resize to the iframe and write the values in manually anyway
20:21:12 <emilio> iank_: if we don't do this people will just write the values in with a resizeobserver so they stick
20:21:52 <emilio> emilio: seems fine to me but would be good to get smfr or someone else from Apple to confirm
20:22:13 <emilio> PROPOSED: Keep previous size from the navigated away content
20:22:14 <emilio> q+
20:22:50 <emilio> Rossen: curious about what privacy / sec teams would thing
20:23:04 <emilio> ... I see iank_'s point about people being able to do this but that's a bit of cargo culting
20:23:21 <TabAtkins> emilio: what beahvior do we want once we've loaded the incoming page, and we see it's not opted in?
20:23:29 <TabAtkins> emilio: at that point do we want to clear the previous size?
20:23:39 <TabAtkins> Rossen: the previous size coudl be partial/incomplete anyway
20:23:41 <iank_> could we resolve to keep the size then simon/etc can follow up if needed?
20:23:58 <TabAtkins> emilio: that does give you a bit of extra info...
20:24:06 <smfr> ok by me
20:24:07 <TabAtkins> emilio: q is just do we want to keep the previous size or reset
20:24:23 <TabAtkins> Rossen: does this work cross-origin?
20:24:25 <TabAtkins> TabAtkins: yeah
20:24:30 <TabAtkins> Rossen: oh then def reset, yeah
20:24:54 <TabAtkins> emilio: well the cross-origin can see the value of the previous page, so leaking to cross-origin is already there
20:25:18 <iank_> it adds visual jump when it isn't needed. the polyfills today don't have this jump
20:25:42 <TabAtkins> Rossen: I think cross-origin navs should always reset eagerly
20:25:55 <TabAtkins> iank_: what's your threat model here?
20:26:08 <TabAtkins> Rossen: it exposes info you wouldn't otherwise have
20:26:11 <emilio> ack emilio
20:26:17 <TabAtkins> iank_: you can't determine how you got that info, tho
20:26:32 <TabAtkins> iank_: if the outside page sets `height:160px`, the cross-origin frame gets that 160px
20:26:38 <TabAtkins> iank_: no different from the value coming from frame-sizing
20:27:00 <TabAtkins> iank_: so i don't think clearing the info is useful...
20:27:23 <TabAtkins> emilio: resetting gives you more info. if you embed a cross-origin and you navigate to a different origin, cna the embedder know about that navigation?
20:27:32 <TabAtkins> emilio: can you get the url of the iframe?
20:27:42 <TabAtkins> emilio: but if you reset, then the resize would expose that
20:27:46 <Adam_Page> Adam_Page has joined #css
20:28:07 <fantasai> TabAtkins: wouldn't necessarily expose, because page can request size update
20:28:24 <fantasai> TabAtkins: if can't observe cross-origin, can't tell if it's due to cross-origin change or whether page requested a resize
20:28:43 <Rossen> ack fantasai
20:28:56 <emilio> fantasai: we seem to have agreement to preserve this at least for same-origin
20:29:05 <emilio> TabAtkins: yes
20:29:09 <emilio> fantasai: we can resolve on that
20:29:36 <emilio> PROPOSED: For same-origin navigations we definitely keep the size
20:29:50 <emilio> RESOLVED: For same-origin navigations we definitely keep the size
20:30:07 <emilio> fantasai: the other interesting question is what happens if the new page doesn't opt in
20:30:17 <emilio> ... do we resize to the initial size or we roll with the previous natural size
20:31:35 <emilio> emilio: it's probably more consistent to reset it, it'd be weird for the same page to give two different renderings depending on whether the navigated-from page happened to get measured or not
20:31:49 <fantasai> emilio++
20:32:09 <TabAtkins> +1
20:32:18 <emilio> PROPOSED: Once we know the new page is not opted-in, we reset the size
20:32:54 <TabAtkins> emilio: so imagine you ahve a page that opts in, it's an interstitial page
20:33:07 <TabAtkins> emilio: everything checks out, we measure the size and adjust
20:33:35 <TabAtkins> emilio: but it would be weird if navigating *before* DOMContentLoaded gave one rendering (the initial size) and navigating *Aafter* gave another (the measured size)
20:33:53 <TabAtkins> koji: so once we hit the </head> tag, we relayout
20:34:07 <TabAtkins> emilio: Yeah, once we know the page is not opting in, you'll clear the size and probably relayout
20:34:31 <TabAtkins> fantasai: probably worse to base it on DOMCotnentLoaded, want it as fast as possible
20:34:36 <TabAtkins> emilio: right, so </head> tag
20:34:52 <TabAtkins> koji: so what does it help? the page can still see the previous size
20:34:55 <TabAtkins> fantasai: thi sisn't security
20:35:13 <TabAtkins> fantasai: just, if the page hasn't opted in, it should lay out different based on whether it was *navigated to* by an opted-in page or not
20:35:24 <TabAtkins> s/it should/it shouldn't/
20:35:54 <fantasai> fantasai: whether previous page was tall or short, shouldn't change the rendering of this page (which has not opted in)
20:35:54 <emilio> fantasai: it's not only about whether you've navigated in the middle but also about whether it's a tall or short page
20:36:36 <emilio> koji: so when the child page it closes the `</head>` it sends a message to the parent process and resize
20:36:50 <emilio> ... at that point you'd have to relayout
20:36:55 <emilio> ... but it is fine to do multiple layouts here
20:37:24 <emilio> iank_: the info leak is happening regardless right?
20:37:29 <emilio> emilio: yeah this is just about getting consistent rendering
20:38:05 <emilio> PROPOSED: Once we know the navigated-to page doesn't opt-in, we clear the intrinsic size
20:38:13 <fantasai> PROPOSED: Once we know the new page is not opted-in, we reset the size
20:38:38 <TabAtkins> (and we always keep the previous page's size until then, regardless)
20:39:20 <emilio> RESOLVED: Once we know the navigated-to page doesn't opt-in, we clear the intrinsic size
20:39:21 <fantasai> RESOLVED: Once we know the new page is not opted-in, we clear the size
20:39:40 <emilio> fantasai: now remaining question is do we reset the size for cross-origin navigations or not
20:39:53 <emilio> ... (regardless of whether it's opted in)
20:40:29 <emilio> ... I think there's several things, one is preserving the size, the other is resetting the size as soon as it's cross-origin, the other one is to pretend to reset the size so that it's laid out into a default size container
20:40:30 <emilio> q+
20:40:38 <smfr> pretending sounds complicated
20:41:02 <emilio> ... so the page is pretending to see the default viewport
20:41:10 <emilio> emilio: observable via window.innerHeight
20:41:17 <Rossen> smfr +1
20:41:19 <fantasai> s/several things/several options/
20:41:26 <TabAtkins> emilio: in the pretending version, a few options
20:41:38 <TabAtkins> emilio: one is pretending frame-sizing isn't set, the other is pretending you're fixed size 300x150
20:41:54 <TabAtkins> emilio: former is especially bad, you don't know the size you'd have without frame-sizing without rerunnign layout
20:42:12 <TabAtkins> emilio: so my pref is, if we don't have concrete attack vectors, i'd like to just preserve the previous page's size
20:42:24 <TabAtkins> emilio: if we do, i like enforcing a 300x150 size for the iframe's document
20:42:43 <TabAtkins> emilio: that does change beahvior for existing docs
20:42:48 <TabAtkins> emilio: so my prefer is just not pretend and preserve the size
20:42:56 <iank_> +1 to emilio - we don't want to trigger a layout on the main frame for this purpose.
20:42:58 <TabAtkins> emilio: i don't think there's an attack vector
20:43:21 <emilio> iank_: I'm struggling to see what the attack vector would be
20:43:28 <emilio> ... but +1 to what emilio said
20:43:54 <emilio> smfr: if this is a payment flow the site might depend on whether apple pay or other method information is in use for example
20:44:07 <emilio> iank_: but you don't know if that size was imposed by the parent page or not
20:44:24 <emilio> smfr: not sure I agree, the site can assume if it knows it's using frame-sizing
20:44:54 <fantasai> iank_: Same as polyfill case
20:44:58 <emilio> iank_: not different from a page using the polyfill and exposing this
20:45:06 <emilio> emilio: in that case it's explicit, the parent is acting as a coordinator
20:45:06 <fantasai> emilio: Yeah, but in that case it's more explicit. Parent page is doing it explicitly
20:45:16 <emilio> smfr: that sounds like a bad polyfill
20:45:38 <fantasai> TabAtkins: polyfill wouldn't do the flickering behavior, it's bad
20:46:00 <smfr> (bad for privacy, not bad for flicker)
20:46:04 <fantasai> emilio: In this case, you don't require flicker necessarily. You can layout the child page with a 300x150 viewport unconditionally without changing layout of outer frame
20:46:27 <fantasai> emilio: from pov of parent, the size hasn't changed. So flicker isn't that bad.
20:46:32 <fantasai> TabAtkins: you're talking about the pretending case
20:46:37 <fantasai> emilio: Right, that's not possible to do in a polyfill
20:46:53 <fantasai> emilio: Has Google run this through security team?
20:47:20 <fantasai> emilio: To me, I find it very hard to come up with a realistic enough case ... maybe the payment processor example from Simon
20:47:37 <fantasai> emilio: If it's sensitive, before navigating away the previous page could size itself to zero and call this API
20:47:50 <fantasai> emilio: otherwise, there's no way to distinguish whether size is set by embedder or not
20:48:11 <emilio> fantasai: a sensitive page would ideally not opt-in?
20:48:43 <emilio> koji: I think what you're saying is equivalent to the child page sending the size to the parent
20:48:53 <emilio> ... if that child page navigates to a bad page
20:49:07 <emilio> ... I don't see much difference
20:49:32 <fantasai> emilio: originating page needs to have the meta opt-in
20:49:45 <fantasai> ... there's 2 pages, A and B in different origins.
20:49:53 <fantasai> ... let's say A has different sizes depending on whether you have Apple Pay
20:49:57 <fantasai> ... and page B wants to know
20:50:06 <fantasai> ... if page B opts in via meta tag
20:50:15 <fantasai> ... The only way for page A to not expose its content size would be
20:50:26 <fantasai> ... before navigating to clear the size
20:50:34 <fantasai> ... It is possible not to leak it, but do we want that to be the behavior.
20:50:53 <fantasai> ... In polyfill the parent page is coordinating between both
20:51:04 <Rossen> q?
20:51:07 <Rossen> ack emilio
20:51:57 <emilio> Rossen: what if we take the conservative resolution to pretend 300x150 and then based on conversations with experts we can come back and change it
20:51:58 <emilio> q+
20:52:33 <Rossen> ack emilio
20:53:16 <emilio> emilio: My concern with that is that unless we do the same for /all/ cross-origin iframes, then you're exposing different information (whether you were navigated from or not, or whether or not your parent uses frame-sizing)
20:54:00 <fantasai> emilio: Would be good to check with security folks whether they thing this is a real attack vector
20:54:02 <emilio> ... and doing it for all cross-origin iframes is a behavior change / performance issue
20:54:21 <fantasai> PROPOSED: Check with security folks whether cross-origin case leaking info is a real concern
20:54:42 <fantasai> PROPOSED: Check with security folks whether cross-origin case leaking info is an issue that needs mitigation
20:55:11 <fantasai> RESOLVED: Check with security folks whether cross-origin case leaking info is an issue that needs mitigation
20:55:56 <fantasai> Topic: Rainbows
20:56:04 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13157
20:56:04 <github-bot> Topic: [css-conditional-5][css-color] Define `style()` color comparison in more precise terms
20:56:04 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13157
20:56:35 <emilio> lea: we have handwavy prose about how `style()` matching
20:56:43 <emilio> ... for color each UA does its own thing
20:56:45 <Kurt> Kurt has joined #css
20:57:00 <emilio> ... you can have black matching across different (old color formats) but doesn't match black for new color formats
20:57:09 <emilio> ... I think we can do better
20:57:29 <emilio> ... one challenge is we generally don't want to gratuitously convert to color spaces
20:57:39 <emilio> ... and comparing using oklab with some epsilon
20:57:46 <emilio> ... we want to limit them because they're not lossless
20:57:53 <emilio> ... not also about precission but also missing values
20:58:02 <emilio> ... so I think we might need to be a little smarter
20:58:11 <emilio> ... maybe we pick one of the two color spaces based on some hierarchy
20:58:22 <emilio> ... and if you end up getting a conversion to zero this wouldn't match
20:58:29 <emilio> ... also should `none` match any number?
20:58:33 <emilio> q+
20:58:35 <TabAtkins> q+
20:58:42 <emilio> ... do we say that matches or does it only match none?
20:58:52 <ChrisL> q+ to aree none only matches none
20:58:53 <emilio> ... if you want to resolve the none you can interpolate but they mean different things
20:59:23 <emilio> ... and within that framework we're going to lose some nones but those wouldn't have matched anyways
20:59:24 <kbabbitt> q+
20:59:28 <emilio> ... anything to add ChrisL?
20:59:34 <emilio> ChrisL: agree none should only match none
20:59:49 <Rossen> ack emilio
20:59:56 <TabAtkins> emilio: whatever we do here, we need it to be consistent with transitions
21:00:02 <ChrisL> qq+
21:00:03 <TabAtkins> emilio: I want to keep color comparisons basically the same
21:00:17 <TabAtkins> emilio: it woudl be good to have the exact same test case and see if you get a transitionstart event
21:00:40 <TabAtkins> emilio: so i think defining style() queries to match transitions makes sense, it's doing the same thing
21:01:30 <TabAtkins> ChrisL: in the issue we're talking about adding a new section to Color called "comparing colors" which'll have the same sorts of algos as converting/etc and everyone will refer to that
21:01:33 <TabAtkins> emilio: that sounds fine, yeah
21:01:53 <TabAtkins> lea: i think the way nones behave in transitions now, if you transition from none to non-none, the component gets the same value along the entire transition
21:02:07 <TabAtkins> emilio: that's different, that's interpoaltion behavior. we're worrying about whteher you *start* a transition or not
21:02:10 <TabAtkins> lea: i agree
21:02:20 <emilio> ack ChrisL
21:02:20 <Zakim> ChrisL, you wanted to react to emilio
21:02:23 <miriam> q+
21:02:23 <emilio> ack TabAtkins
21:02:29 <emilio> TabAtkins: wanted to say the same thing as emilio
21:02:31 <emilio> ack ChrisL
21:02:31 <Zakim> ChrisL, you wanted to aree none only matches none
21:02:37 <Rossen> ack kbabbitt
21:02:46 <emilio> kbabbitt: Agree that none should only equal none
21:03:03 <emilio> ... also think we should minimize the number of color-space conversions we do
21:03:06 <ChrisL> qq+
21:03:12 <emilio> ack ChrisL
21:03:12 <Zakim> ChrisL, you wanted to react to kbabbitt
21:03:33 <emilio> ChrisL: a recent color-4 edit splits conversion between two steps
21:03:45 <emilio> ... preparing and conversing
21:04:10 <emilio> kbabbitt: my only observation is that the definition of "need to convert" might be different for interpolation vs equality
21:04:27 <emilio> ChrisL: when you interpolate, before you start you look for missing analogous components
21:04:37 <emilio> ... so there's an extra carrying forward step but otherwise identical
21:04:43 <Rossen> ack miriam
21:05:24 <emilio> miriam: I support this, in sass there's two type of color equality, same color in same format, and whether they resolve to the same when converted (equals and same)
21:05:49 <emilio> ... seems we're looking for equals() and same()
21:06:12 <emilio> ... for lengths whether they convert to pixels depends on whether you use `=` or `:`
21:06:34 <emilio> ... the old syntax uses `--prop: <value>`, range uses ` = `
21:06:41 <emilio> ... I believe with `<length>`s we treat them differently
21:06:42 <emilio> q+
21:07:11 <astearns> not sure if we should follow that precedent…
21:07:26 <lea> q?
21:07:29 <emilio> ... I wonder if we need to do the same thing there
21:07:35 <emilio> TabAtkins: that's not right, they're the same
21:07:48 <TabAtkins> emilio: the difference is whether the proeprty is registered or not
21:08:03 <TabAtkins> emilio: if it's registered, the values are compared as length; if not they're compared as tokens
21:08:10 <TabAtkins> emilio: same will apply to color properties
21:08:22 <TabAtkins> miriam: there was an issuea bout unitless zeros... never mind
21:08:24 <Rossen> ack emilio
21:08:37 <lea> PROPOSED: When comparing colors, `none` is only equal to `none`
21:08:40 <lea> PROPOSED: Whatever we resolve for comparing colors is also used to determine whether a transition starts
21:08:43 <lea> PROPOSED: Minimize color space conversions when comparing colors in different color spaces, to preserve missing components to the extent possible. Do not convert both to a third color space, but convert only one of the two (exact algorithm TBD)
21:09:28 <ChrisL> q+
21:09:40 <lea> scribe+
21:09:46 <Kurt> Kurt has joined #css
21:09:50 <lea> emilio: Even in the same color space, what about clamping?
21:10:29 <emilio> ChrisL: hsl() gets stored as rgb anyways
21:10:42 <lea> lea: Oh no, what happens with nones then?
21:10:44 <emilio> (without none)
21:11:20 <emilio> Rossen: first one should not be controversial
21:11:32 <emilio> RESOLVED: When comparing colors, `none` is only equal to `none`
21:11:42 <emilio> PROPOSED: Whatever we resolve for comparing colors is also used to determine whether a transition starts
21:11:52 <emilio> RESOLVED: Whatever we resolve for comparing colors is also used to determine whether a transition starts
21:12:06 <TabAtkins> Both style() queries and "does a transition start" use the same comparison logic
21:12:07 <emilio> PROPOSED: style() and transitions use the same color comparison method
21:12:16 <fantasai> +1
21:12:18 <emilio> RESOLVED: style() and transitions use the same color comparison method
21:12:36 <emilio> PROPOSED: Minimize color space conversions when comparing colors in different color spaces, to preserve missing components to the extent possible. Do not convert both to a third color space, but convert only one of the two (exact algorithm TBD)
21:12:46 <emilio> ChrisL: is hsl() and rgb() the same color space?
21:13:09 <fantasai> emilio: for legacy colors, some of the hsl() stuff gest stored as rgb
21:13:13 <fantasai> emilio: doesn't trigger transitions
21:13:25 <fantasai> emilio: Personally would be fine with converting to a third color space if needed, as long the color spaces are different
21:13:34 <fantasai> emilio: We don't need to complicate things a lot
21:13:38 <fantasai> lea: if non-none?
21:13:47 <fantasai> lea: If none of the colors has a 'none'. Otherwise that would be lossy.
21:14:09 <TabAtkins> (aka, if they're different color spaces and either has a 'none' they're *guaranteed* to be different colors
21:14:10 <TabAtkins> )
21:14:11 <lea> `oklch(0.9 0.2 none)` would not be equal to itself
21:14:16 <fantasai> emilio: If you have 'none's in different coor spaces, can we just assume they're differnet colors
21:14:29 <fantasai> ChrisL: Yes. Don't even need to do the conversion then.
21:14:40 <fantasai> TabAtkins: When in the same color space, just compare components
21:14:43 <fantasai> lea: Yes.
21:14:56 <fantasai> emilio: If they're different color spaces and there's a none, they're not the same.
21:15:09 <lea> `oklab(.9 none none)` and `oklch(.9 none none)`
21:15:20 <Rossen> ack ChrisL
21:15:24 <emilio> if a.color_space != b.color_space { if a.has_nones() || b.has_nones() { return false; } return a.to_oklab() == b.to_oklab() }
21:15:24 <TabAtkins> 1. If in same oclor space, compare components. 2. If in different color sapce and there's a "none", not equal. 3. If in different color space and no "none"s, convert to oklab and do epsilon comparison
21:15:41 <cwilso> present+
21:15:44 <fantasai> lea: What you're proposing, ? would be lost
21:15:57 <fantasai> ... although maybe not in this example because oklab
21:16:02 <kbabbitt> s/? would be lost/`none`s would be lost/
21:16:09 <TabAtkins> lea: we have rules about carrying nones between color spaces, component mappings. in your logic this would be lost here, these two would be treated as different
21:16:30 <TabAtkins> emilio: for interpolation, yes, it's important those aren't lost and they're properly none-trnaistioned
21:16:35 <TabAtkins> emilio: but for comparison, not as important
21:16:51 <TabAtkins> emilio: i'm okay with more complicated if needed, but think it's just easier to compare in oklab when there's no none
21:17:06 <TabAtkins> ack TabAtkins
21:17:52 <Rossen> ack fantasai
21:18:04 <emilio> fantasai: if we don't have a specific proposal maybe we take it back to the issue?
21:18:21 <emilio> fantasai: TabAtkins has a couple points that he put on irc, #3 has some nuance
21:18:37 <emilio> TabAtkins: same algorithm, effectively the same emilio wrote above
21:18:50 <fantasai> astearns: Suggest we adopt that and tweak fro mthere.
21:18:51 <TabAtkins> proposed comparison algo: . If in same oclor space, compare components. 2. If in different color sapce and there's a "none", not equal. 3. If in different color space and no "none"s, convert to oklab and do epsilon comparison
21:18:55 <kbabbitt> sgtm
21:19:06 <ChrisL> +1 for that
21:19:10 <florian> q?
21:19:12 <florian> q+
21:19:15 <fantasai> lea: Can we continue to explore better alternatives?
21:19:17 <emilio> lea: can we continue to explore better alternatives if we resolve on that?
21:19:28 <fantasai> Rossen: keep improving!
21:19:37 <emilio> TabAtkins: this is technically a behavior change to transitions right now, it's web observable already, presumably we'd be ok doing otherwise
21:20:11 <emilio> florian: I support tab's proposal, but does color-space mean color-space or notation?
21:20:21 <emilio> TabAtkins: don't care
21:20:25 <emilio> ChrisL: colorspace
21:20:33 <fantasai> lea: depends...
21:20:59 <TabAtkins> Tallest citation wins
21:21:14 <emilio> RESOLVED: If in same color space, compare components. 2. If in different color space and there's a "none", not equal. 3. If in different color space and no "none"s, convert to oklab and do epsilon comparison
21:21:22 <fantasai> "different color space" TBD
21:21:46 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10280
21:21:46 <github-bot> Topic: [css-color-5] RCS channel keywords interaction with calc() is underspecified
21:21:46 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10280
21:22:17 <emilio> ChrisL: we don't say when it resolves right now
21:22:41 <TabAtkins> q+
21:22:43 <emilio> ... we already have resolutions that there are no `none`s in `calc()
21:22:48 <Rossen> ack florian
21:22:48 <florian> q-
21:22:49 <emilio> ... kinda forgot about this one
21:23:11 <emilio> ... we concluded that we don't let `none` escape `calc()` and that answers most of the questions
21:23:23 <emilio> TabAtkins: that's a reasonable possibility I remember discussing
21:23:32 <Rossen> ack TabAtkins
21:23:38 <emilio> ... the other possibility is to define a channel keyword as an analogous component
21:23:41 <emilio> ... infectious
21:24:09 <emilio> emilio: ISTR discussing both options and deciding the former but might be misremembering
21:24:44 <dbaron> (leaving for the rest of the day)
21:24:58 <emilio> ChrisL: I think with that we answer all of weinig's questions
21:25:43 <emilio> TabAtkins: looking back at the preceding argument and lea didn't like convert to 0
21:25:49 <emilio> ... did she change her mind
21:25:53 <emilio> ChrisL: she didn't
21:26:15 <ChrisL> https://github.com/w3c/csswg-drafts/issues/10211#issuecomment-3807032366
21:28:00 <emilio> emilio: lea, would you be cool defining `none` as `0` in `calc`? Or make `none` infectious?
21:28:14 <emilio> TabAtkins: you argued against `0`
21:28:34 <emilio> lea: I don't like losing `none`, but I don't have anything better to propose in the general case, if we can avoid it in some cases
21:28:47 <emilio> ChrisL: we have that
21:29:55 <emilio> ... converting colors converts powerless to missing, and the other only happens in for different color spaces
21:30:33 <emilio> lea: so if you use `calc(r * 2)` and `r` is `none`, then does it get converted to `0` or kept as `none * 1.2`?
21:30:37 <emilio> ChrisL: with this proposal, `0`
21:30:50 <emilio> emilio: so you're arguing for infectious (`none * 1.2` is `none`)?
21:30:54 <emilio> lea: no
21:31:26 <emilio> ... I want them to get preserved as `none * 1.2` and then resolved when `none` gets a value
21:31:39 <lea> lea: `none` is not `NaN`. `none * 1.2` means "whenever that color gets interpolated, `none` resolves to that component in the other color and then multiplied by 1.2"
21:31:51 <lea> lea: That preserves intent the best, but it may be too complex
21:32:49 <lea> That said, `calc(l * 1.1)` in L expecting to get a slightly lighter tint, and with this, it would get black. That can have a11y implications
21:35:10 <lea> Option 1: none = 0 in `calc()`, always
21:35:13 <emilio> emilio: recap: 1. none = 0 in calc. 2. none behaves infectiously (like NaN), 3. none gets preserved (harder to implement)
21:35:21 <lea> Option 2: calc(something with none) = none, always
21:35:39 <lea> Option 3: none gets preserved, iff same color space
21:36:36 <emilio> TabAtkins: just making sure that there's no difference between calc(r) and r in a relative color
21:36:39 <emilio> [general agreement]
21:36:40 <Kurt> Kurt has joined #css
21:36:42 <ChrisL> calc here meaning math functions
21:36:53 <lea> My worry is that none happens organically for certain conversions and Options 1 & 2 break expectations around contrast quite dangerously
21:37:03 <Rossen> 1, 3, 2
21:37:14 <TabAtkins> 1 or 2 (no opinion between them)
21:37:16 <ChrisL> 3, 2, 1
21:37:20 <lea> 3, 1, 2
21:37:28 <astearns> abstain
21:37:33 <kbabbitt> abstain
21:37:34 <kizu> 2, 3, 1
21:37:37 <hoch> abstain
21:37:38 <dshin> abstain
21:37:44 <alisonmaher> abstain
21:37:46 <arronei> 1, 3, 2
21:37:52 <oriol> Maybe 2, but no strong opinion
21:37:56 <Kurt> abstain
21:38:02 <emilio> 1 or 2 indistinctly, 3
21:38:58 <florian> abstain
21:39:00 <miriam> abstain
21:39:55 <javierct> javierct has joined #css
21:40:44 <emilio> lea: with (1) at least you have clamp() and apply guardrails
21:40:58 <emilio> RESOLVED: none in calc gets turned to 0
21:46:20 <alisonmaher> alisonmaher has joined #css
22:00:57 <Rossen> Rossen has joined #css
22:01:36 <astearns> topic: break
22:02:08 <fantasai> scribe+
22:02:44 <Rossen> github, take up > (note the leak already somewhat happens with polyfills of this feature)
22:02:53 <arronei> arronei has joined #css
22:02:54 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/12543
22:02:54 <github-bot> Topic: [css-color-5] Should origin colors serialize as their declared value?
22:02:54 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/12543
22:03:20 <emilio> ChrisL: someone has raised an issue that the spec and wpt disagree
22:03:46 <emilio> ... so the suggestion was to suggest to match wpt
22:03:55 <emilio> ... but that's not right because it's a recent change
22:04:01 <emilio> ... we should update wpt instead
22:04:16 <emilio> PROPOSED: Close no change, update tests to match the new spec text
22:04:34 <emilio> astearns: volunteers for changing it?
22:04:34 <Kurt> Kurt has joined #css
22:04:45 <emilio> ChrisL: weining proposed the change so will ask him otherwise I'll take it
22:04:49 <emilio> RESOLVED: Close no change, update tests to match the new spec text
22:05:21 <emilio> github-bot: take https://github.com/w3c/csswg-drafts/issues/13459
22:05:21 <github-bot> emilio, Sorry, I don't understand that command.  Try 'help'.
22:05:24 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13459
22:05:25 <github-bot> Topic: [css-color] Why not just alias deprecated system colors at parse time?
22:05:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13459
22:05:47 <emilio> ChrisL: oriol suggested that since deprecated system colors are supposed to be the same, why not aliasing them?
22:06:01 <emilio> ... there seemed to be general agreement
22:06:26 <lea> emilio: Impl-wise it's possible but I think the reason why they're not parsed aliases to begin with in Gecko is we need them to resolve to different values
22:06:46 <lea> ... not a big deal, we can parse-alias them when parsing web content stylesheets, that's just the historical reason
22:07:20 <lea> ... we want to make a title bar match the system color, there's a few colors to represent an active titlte bar, if we want to un-deprecate them that changes behavior
22:07:38 <alisonmaher> q+
22:07:42 <lea> ... that's the only thing that may make parsed aliases more annoying, you'd write div.style.color = "activeCaption", but then it would not roundtrip
22:07:58 <lea> ... if we want to bring some of these back, we have to change behavior again
22:07:59 <lea> q+
22:08:14 <lea> main q is are there some of these we may want to bring back
22:08:28 <lea> ... but no objections
22:08:44 <emilio> ChrisL: ntim also explained some of the WebKit behavior
22:08:55 <emilio> ... something about using them internally
22:09:28 <emilio> emilio: so same thing as gecko, using them internally?
22:09:38 <emilio> ntim: just existing apps using these
22:09:45 <Rossen> ack fantasai
22:10:09 <emilio> fantasai: support the logic emilio articulated, I'd support more explicit writing in the spec saying that they compute to the same, but specified value should remain as specified
22:10:22 <emilio> ChrisL: we're explicit about it
22:10:29 <emilio> fantasai: it says "same as", not "it computes as"
22:10:36 <emilio> ... we should also clarify color-scheme affects this
22:10:43 <emilio> ChrisL: but it does
22:10:49 <emilio> fantasai: yeah agreed, just not super clear in the spec
22:10:56 <emilio> ... doesn't mention the color-scheme property at all
22:11:09 <Rossen> ack alisonmaher
22:11:31 <emilio> alisonmaher: I think if we do believe we might end up with some changes emilio's point is fair
22:11:54 <emilio> ... re the titlebar the current thing is the accentcolor keyword, it doesn't match the inactive state tho
22:12:33 <ChrisL> q+
22:12:43 <emilio> ... not sure the plan is using the deprecated colors tho
22:12:58 <emilio> emilio: fwiw for native titlebar appearance you do need the (windows) active system color
22:13:03 <emilio> ... but not a big deal
22:13:27 <Rossen> ack lea
22:13:29 <emilio> lea: I don't think authors expect perfect roundtrip when setting specified values, lots of colors behave like that
22:13:29 <Rossen> ack ChrisL
22:14:10 <fantasai> PROPOSED: Clarify that they "compute" to the other value. (But specified value remains as specified.)
22:14:15 <emilio> ChrisL: I see some arguments both ways but parse aliasing might be a bit annoying
22:14:33 <florian> +1
22:14:43 <fantasai> RESOLVED: Clarify that they "compute" to the other value. (But specified value remains as specified.)
22:14:51 <fantasai> ACTION: Also clarify that they're affected by color-scheme.
22:15:19 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/10414
22:15:19 <github-bot> Topic: [css-color-5] Should intermediate out of range values be preserved in color-mix?
22:15:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10414
22:15:40 <emilio> ChrisL: proposal is "yes, we do that elsewhere"
22:15:53 <fantasai> emilio: what do browsers do?
22:16:16 <fantasai> ChrisL: Chrome/FF clamp
22:16:24 <fantasai> emilio: That testcase is weird, because same color
22:16:29 <fantasai> emilio: Also rgb [missed]
22:16:41 <fantasai> emilio: I think it would b emore interesting to test with color-mix() with color(srgb) etc.
22:16:46 <fantasai> emilio: So I think need a bit more data
22:16:54 <fantasai> ChrisL: Ok, let's investigate
22:17:20 <fantasai> SUMMARY: Get more precise compat data
22:17:26 <github-bot> Topic: [css-color-5] `color-mix()` serialization is outdated
22:17:40 <emilio> ChrisL: it is
22:17:47 <emilio> ... I had some problems with how to update it
22:18:05 <emilio> ... it used to be the case that you had two colors and if you don't specify them it's 50% and 50%
22:18:21 <emilio> ... so with more colors I'd expect 100% / N
22:18:46 <fantasai> emilio: Some implementation updates already, so can check what happens
22:19:10 <emilio> Rossen: is there any other sensible alternative?
22:19:15 <Rossen> ack fantasai
22:19:26 <emilio> fantasai: some questions about color-interpolation-method being optional
22:19:37 <emilio> ... we are probably happy to make that change?
22:20:06 <emilio> ChrisL: we already resolved on it, but yeah it should serialize to the shortest value (omit oklab if needed)
22:20:18 <emilio> PROPOSED: Allow to serialize without color space if it matches the default (oklab)
22:20:38 <emilio> s/Allow to serialize/Require serializing
22:21:44 <emilio> emilio: potential compat is `color-mix(in oklab,` now serializes without
22:21:48 <emilio> ... but probably fine
22:22:24 <emilio> fantasai: another one would be do we ever plan to change the default
22:23:11 <emilio> emilio: Even if we changed it we would potentially be breaking stuff so I'd rather do the simple thing and omit oklab
22:23:51 <emilio> PROPOSED: Require serializing without color space if it matches the default (oklab)
22:23:56 <emilio> RESOLVED: Require serializing without color space if it matches the default (oklab)
22:24:32 <emilio> ChrisL: other question is serializing with identical colors, like `color-mix(green, green, green, red)`, so you need to preserve them
22:24:45 <emilio> TabAtkins: you could do `green 75%, red 25%)`
22:24:50 <fantasai> PROPOSED: Multiple identical entries do not collapse.
22:25:01 <fantasai> RESOLVED: Multiple identical entries do not collapse.
22:25:03 <kbabbitt> +1
22:25:45 <emilio> RESOLVED: Colors are not collapsed
22:26:23 <emilio> fantasai: if you have both percentages 50% do you serialize them?
22:26:31 <emilio> ChrisL: the current algorithm omits the percentages
22:26:56 <fantasai> PROPOSED: If percentages for N arguments are 1/N (and are therefore all omittable), omit them.
22:28:15 <emilio> fantasai: if I write `red 50%, green 25%, blue 25%`, how do we serialize that out?
22:28:15 <fantasai> color-mix(red 50%, green 25%, blue 25%)
22:28:22 <Kurt> Kurt has joined #css
22:28:26 <fantasai> color-mix(red 50%, green, blue)
22:28:32 <fantasai> color-mix(red, green 25%, blue 25%)
22:28:49 <lea> q?
22:28:53 <lea> q+
22:29:02 <emilio> fantasai: we don't know what you meant, I suggest we drop the percents if all drop
22:29:22 <emilio> ChrisL: the current text says "if both are 50% you drop them, otherwise you don't"
22:29:39 <emilio> ... I'd like to preserve that, only drop if all are omittable
22:29:44 <Rossen> ack lea
22:29:46 <emilio> lea: we do have this rule
22:29:55 <emilio> ... about shortest serialization
22:30:00 <emilio> ... could be useful?
22:30:04 <emilio> emilio: within reason :)
22:30:14 <emilio> fantasai: if you have four colors there's no single answer
22:30:25 <ChrisL> as simple as possible. but no simpler
22:30:30 <lea> `red 30%, green 30%, yellow 20%, purple 20%`
22:30:53 <fantasai> PROPOSED: If percentages for N arguments are 1/N (and are therefore all omittable), omit them. Otherwise serialize the percentages (even if originally omitted).
22:31:05 <lea> +1
22:31:11 <emilio> RESOLVED: If percentages for N arguments are 1/N (and are therefore all omittable), omit them.
22:31:14 <fantasai> RESOLVED: If percentages for N arguments are 1/N (and are therefore all omittable), omit them. Otherwise serialize the percentages (even if originally omitted).
22:31:49 <fantasai> ACTION: update spec to handle hue-interpolation method
22:31:52 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13269
22:31:52 <github-bot> Topic: [css-color][css-animations] Is it specified anywhere that a color animation at time=0 exactly match the from color's computed value?
22:31:52 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13269
22:33:07 <fantasai> ChrisL: If you're not interpolating, then you don't do any color interpolation, so the color shouldn't change.
22:33:11 <emilio> ChrisL: I don't think it's explicit but I think it should, I think the birtles mentioned it falls out of the spec
22:33:28 <flackr> q+
22:33:29 <emilio> ChrisL: in the start and end you get the computed value
22:33:42 <emilio> ack flackr
22:33:43 <emilio> flackr: that's right
22:34:10 <emilio> ... there are cases where before / after the keyframe you have a different form because your interpolation dependends the other keyframe
22:34:31 <emilio> ... so before a keyframe could have a different shape than after
22:34:39 <emilio> ... so makes sense that at the keyframe you get the explicit keyframe behavior
22:34:44 <TabAtkins> A -> X and X -> B might interpret X differently in the two cases
22:35:05 <TabAtkins> so we should preserve the X value as specified so it can properly reinterpret
22:35:05 <emilio> astearns: so the test is correct and we just need to be explicit about why
22:36:15 <emilio> ChrisL: so we should add more tests
22:36:21 <emilio> astearns: maybe adding a color example?
22:36:28 <emilio> PROPOSED: Update the spec with an example
22:36:35 <emilio> PROPOSED: Update the animations spec with an example
22:36:44 <emilio> RESOLVED: Update the animations spec with an example
22:37:25 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13724
22:37:25 <github-bot> Topic: [css-color-5] Support `light-dark(<color>, <image>)` by producing a dimensionless image for `<color>`
22:37:25 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13724
22:37:53 <emilio> lea: recently we resolved on a `light-dark(<image>, <image>)`
22:37:53 <Kurt> Kurt has joined #css
22:38:11 <TabAtkins> q+
22:38:12 <emilio> ... if you specify colors you get a color, if images you get an image
22:38:29 <emilio> ... having a parse time color-or-image is not possible
22:38:45 <emilio> ... but why not encode the workaround of wrapping the thing on a linear-gradient
22:39:02 <emilio> ... making the type of an argument depending on another seems better?
22:39:10 <emilio> s/better/weird
22:39:26 <emilio> ... but it's a bit of a philosophical argument
22:39:51 <emilio> ... `image()` would be an option but doesn't exist now
22:39:52 <astearns> ack TabAtkins
22:40:13 <emilio> ... so I propose to do the auto wrapping to match author expectations
22:40:42 <emilio> ... I wonder if it'd be better to do `light-dark-image()` since then it'd be very clear
22:40:47 <emilio> q+
22:41:13 <emilio> TabAtkins: I wrote some objections in the issue, I'd rather not do colors-as-image in random spots
22:41:19 <emilio> ... because we can't do that arbitrarily
22:41:24 <emilio> ... I'd much rather implement `image()`
22:41:45 <emilio> ... when possible I'd prefer not having an argument influence the other
22:41:56 <emilio> ... doesn't feel great from a language design perspective
22:41:59 <emilio> ... prefer no change
22:42:12 <emilio> ... leaning on image() or linear-gradient() to get solid images
22:42:14 <emilio> +1
22:42:17 <astearns> ack fantasai
22:42:22 <emilio> fantasai: I'm with tab on this one
22:42:46 <emilio> ... if we want to just `image(<color>)` be L1 of that feature that seems fine as well
22:42:59 <emilio> emilio: I was going to make the same proposal
22:42:59 <lea> +1 to `image(<color>)` as the MVP of `image()` (I'm surprised that's not the case already)
22:43:04 <kizu> +1 to start from a simple `image(<color>)`
22:43:40 <astearns> ack emilio
22:43:42 <fantasai> emilio: Instead of linear-gradient() let's just simplify image() to <color>
22:43:45 <emilio> emilio: making `image(<color>)` the MVP and extending later seems fine if people find it weird
22:44:07 <ntim> ntim has joined #css
22:44:08 <lea> PROPOSED: No change, `image(<color>)` to be added to css-images-5 (?)
22:44:14 <fantasai> It's in L4 already
22:44:45 <ChrisL> https://drafts.csswg.org/css-images-4/#image-notation
22:45:05 <lea> PROPOSED: No change, `image()` to be moved to css-images-6,  `image()` in css-images-5 to be pared down to `image(<color>)`
22:45:31 <fantasai> PROPOSED: No change to spec. Add image(<color>) to the CSS Snapshot 2026
22:45:32 <lea> PROPOSED: No change, `image()` to be moved to css-images-5,  `image()` in css-images-4 to be pared down to `image(<color>)`
22:46:36 <fantasai> PROPOSED: No change to spec. Add image(<color>) to the CSS Snapshot 2026's "safe to release" exception list.
22:47:45 <fantasai> PROPOSED: No change to this spec. Move image() other than image(<color>) to next level of css-images. Add image(<color>) to CSS Snapshot 2026 "safe to release" list
22:48:04 <fantasai> RESOLVED: No change to this spec. Move image() other than image(<color>) to next level of css-images. Add image(<color>) to CSS Snapshot 2026 "safe to release" list
22:48:33 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13725
22:48:33 <github-bot> Topic: [css-color-5] Move `light-dark()`?
22:48:33 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13725
22:48:48 <emilio> lea: originally light-dark() lived in css-color-5 because it was a color fn
22:48:54 <emilio> ... now it's an image function too
22:49:01 <emilio> ... it's weird to point to it to css-images
22:49:08 <emilio> ... color-adjust might be a more fitting spec?
22:49:15 <emilio> ... that's where color-scheme is defined
22:49:18 <emilio> ... color-adjust is CR
22:49:40 <emilio> ... one option would be moving just the color version to color-adjust 1 or moving both with the image version at risk
22:49:45 <ChrisL> q+
22:49:46 <emilio> ... or starting a new level
22:49:54 <emilio> ... or we keep it in color-5 and point to it for images-5
22:50:00 <emilio> ... another option was css-values
22:50:04 <emilio> ... not a huge fan
22:50:09 <emilio> TabAtkins: nobody wants that
22:50:23 <emilio> fantasai: people that are looking for this are more likely to find it in color-adjust
22:50:30 <fantasai> or color
22:50:33 <emilio> ntim: other functions are there
22:50:46 <emilio> TabAtkins: mostly very wide functions like calc and such
22:50:50 <astearns> ack ChrisL
22:50:51 <emilio> ... color-mix and such are in color for example
22:51:01 <emilio> ChrisL: given I want to move color-5 to CR
22:51:18 <emilio> ... I plan to chop it to color only, move to CR, then move it to color-adjust
22:51:24 <emilio> TabAtkins: but we'd be adding the image version in CR
22:51:40 <emilio> ChrisL: no, just start color-adjust-2
22:52:13 <emilio> emilio: it's very easy to implement, I think it's fine
22:52:28 <emilio> astearns: so should we move it to color-adjust now with the image version?
22:52:29 <emilio> TabAtkins: yes
22:52:55 <emilio> ChrisL: you can put it in the CR draft, for the snapshot you need horizontal review
22:53:01 <emilio> lea: even if at risk?
22:53:21 <emilio> astearns: so given color-5 is going through horizontal review soon, leave it there for now then move?
22:53:46 <emilio> PROPOSED: Move to color-adjust (with the image version) once color 5 goes through wide review (with the image version)
22:54:40 <emilio> RESOLVED: Move to color-adjust (with the image version) once color 5 goes through wide review (with the image version)
22:55:06 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13377
22:55:06 <github-bot> Topic: [mediaqueries] Effect of <meta name=color-scheme> on img and video sources
22:55:06 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13377
22:55:56 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/31-css-minutes.html fantasai
22:56:04 <emilio> TabAtkins: if you set `<meta name=color-scheme>` it changes the used color-scheme, but media queries don't affect it
22:56:12 <emilio> ... the `<picture>` lets you switch between multiple different sources based on media query
22:56:55 <emilio> ... if you have `<picture>` but `<meta name="color-scheme" content="dark">`, but os in light mode, prefers-color-scheme doesn't match
22:57:17 <emilio> TabAtkins: we could special-case picture / video to make their media query resolve differently (not in love)
22:57:23 <emilio> ... make media queries look into the meta
22:57:43 <emilio> ... or make sure that there's a way to use the used color-scheme of the video / picture
22:57:44 <emilio> q+
22:58:03 <emilio> ... but would require more interaction with HTML and not fix any existing light / dark mode picture
22:58:10 <emilio> ... thoughts?
22:58:24 <emilio> ... my proposal would be to make the media query use the meta color scheme
22:58:30 <emilio> ... I think it's the cleanest way to solve several of these
22:58:35 <emilio> ... other solutions would be great
22:58:41 <emilio> ... the current state is quite bad
22:58:43 <astearns> ack fantasai
22:59:12 <emilio> fantasai: alternative proposal, new `color-scheme` media query that reflects the document, so `prefers-color-scheme` reflects the user preferred color scheme
22:59:27 <florian> I think I like fantasai's proposal
22:59:55 <emilio> fantasai: so you can do your queries for the `color-scheme` without interacting with the preferred value
23:00:26 <TabAtkins> emilio: I dont' like that proposal. `prefers-color-scheme` already takes into account the embedder page; if your outer page is in light mode, an iframe will match (prefers-color-scheme: light)
23:00:31 <astearns> ack emilio
23:00:38 <TabAtkins> emilio: I don't like any of them too much, but I think Tab's is the least destructive
23:01:03 <fantasai> emilio: why would you mismatch?
23:01:08 <fantasai> TabAtkins: You might have a switcher on the page.
23:01:18 <fantasai> TabAtkins: Do that by setting the meta
23:01:28 <fantasai> emilio: Didn't we have scripted control thing?
23:01:40 <fantasai> TabAtkins: yes, but also, one page might be forced dark mode while you're using generic assets that are styled for both
23:01:47 <fantasai> emilio: This would only affect things in the markup, right?
23:01:53 <fantasai> emilio: For other things you'd use light-dark function
23:02:14 <fantasai> emilio: Feels a bit annoying in that preloading for picture resources, now would need to account for that.
23:02:35 <fantasai> emilio: E.g. parsing HTML speculatively, you assume that the media is going to match and now you need to account for the meta tag changing, which is a bit wasteful
23:02:45 <fantasai> TabAtkins: while potentially wasteful, it is avoiding loading the wrong resource
23:02:59 <astearns> s/avoiding loading/avoiding displaying/
23:03:00 <fantasai> TabAtkins: That would only be an issue if you changed the meta well after preload
23:03:06 <fantasai> emilio: Your scanner would need to account for the meta
23:03:14 <fantasai> TabAtkins: how does it interact with viewport meta's today?
23:03:20 <fantasai> emilio: It doesn't :)
23:03:38 <fantasai> emilio: It's explicitly bad because [something]
23:03:54 <TabAtkins> s/something/without the viewport meta, the viewport size depends on the content in some ways/
23:03:56 <fantasai> emilio: Any other meta tag other than device-width is realistically not common enough to optimize
23:04:15 <fantasai> emilio: tldr, I think Tab's proposal is the least bad but still eh
23:04:24 <astearns> ack fantasai
23:05:14 <emilio> fantasai: tabs and my proposal is effectively the same other than with other name right?
23:05:23 <emilio> emilio: yeah but I still think changing prefers-color-scheme is fine
23:05:45 <emilio> fantasai: there were some concerns about that
23:06:15 <emilio> ... we wouldn't have done the embedder thing if we had this
23:06:23 <emilio> emilio: but then prefers-color-scheme is pretty useless
23:06:42 <emilio> fantasai: you'd use prefers-color-scheme to set the initial switcher state or so
23:07:16 <emilio> ... we have several meta tags that are going to affect media queries, the viewport meta tag, the color-scheme, the text-scale which will also affect media queries
23:07:31 <florian> q+
23:07:35 <fantasai> emilio: Not sure I buy need for distinguishing color-scheme and prefers-color-scheme
23:07:49 <fantasai> emilio: prefers-color-scheme already responds to the embedding page color scheme
23:08:38 <fantasai> emilio: We need a different concept for this, because the used color scheme for lacking a meta tag is light.
23:08:54 <fantasai> emilio: even if that's not the preferred color scheme
23:09:05 <fantasai> emilio: Given how it's already not quite the user's preferred color scheme
23:09:17 <fantasai> emilio: I find it a bit more acceptable to re-use it.
23:09:30 <fantasai> emilio: If it wasn't influenced by the embeder page, then I could see the distiction being meaningful
23:09:37 <fantasai> emilio: but right now it's pretty arbitrary
23:09:39 <astearns> q+
23:09:51 <astearns> ack florian
23:09:58 <emilio> florian: I think I'd have a strong preference if we were in a clean slate
23:10:22 <TabAtkins> Just as a reminder, the only argument we had for (prefers-color-scheme) remaining unchanged is so that certain data-collection schemes can still tell what the user preferred even on pages with a <meta color-scheme> manually set
23:10:43 <emilio> ... the fact we're not I think I still lean towards fantasai's approach but less strongly
23:10:50 <emilio> ... if a page has mixed color-schemes
23:11:13 <emilio> ... let's say you have a "spec browser" with its own picker which sets the meta
23:11:53 <emilio> ... within that, the color-scheme media would respond to the meta, which ??
23:12:00 <emilio> ... specs have light and dark mode
23:12:06 <emilio> ... you might have a preference for that
23:12:18 <Kurt> Kurt has joined #css
23:12:34 <emilio> ... instead of viewing them and it's not in an iframe
23:13:21 <emilio> ... so you have a picker in the gallery but having access to the OS level preference would allow you to render the iframe in the right color scheme
23:13:35 <emilio> emilio: ah so you have an iframe and you want the "system" color scheme on the iframe
23:13:44 <emilio> florian: how locked in are we on the iframe thing?
23:14:04 <emilio> ... if we had a color-scheme media query, we could use _that_ for the iframe
23:14:39 <TabAtkins> emilio: so my problem with (color-scheme) is that, it's the MQ you want for everything in practice. We have all this code and examples already using (prefers-color-scheme)...
23:14:53 <TabAtkins> emilio: so when would you want the actual (prefers-color-scheme)?
23:15:22 <TabAtkins> emilio: I agree in an ideal world we'd have done (color-scheme) originally, but...
23:15:53 <fantasai> TabAtkins: The original argument for keeping them distinct was collecting user data
23:16:04 <fantasai> emilio: For Firefox browser UI we need this distinction
23:16:18 <fantasai> emilio: We need to use the user's preference for the UI
23:16:35 <fantasai> emilio: I added a new MQ with a different name for the UI vs the web content
23:16:56 <fantasai> emilio: Given massive amount of code using 'prefers-color-scheme' that would need to change
23:17:08 <fantasai> emilio: can we instead add a new MQ for the "system preferred scheme"?
23:17:17 <fantasai> florian: I think we do want both. Though naming whatever.
23:17:28 <fantasai> emilio: Internally we have concept of "used" and "preferred" color schemes
23:17:45 <fantasai> emilio: I don't have a great name... it's not really the system color scheme
23:18:04 <fantasai> emilio: Potentially 3 color schemes involved
23:18:07 <fantasai> emilio: 1. One that the page sets.
23:18:12 <fantasai> emilio: 2. One that the embedder sets.
23:18:22 <fantasai> emilio: 3. The browser's color scheme.
23:18:27 <fantasai> emilio: 4. OS color scheme.
23:18:45 <fantasai> ....
23:18:56 <fantasai> emilio: There's the top-level value that the browser sets for the top-level page.
23:19:06 <fantasai> emilio: Then there's the one that your embedder sets, e.g. on an iframe.
23:19:18 <fantasai> emilio: Then there's the one set by the iframe document itself.
23:19:23 <fantasai> emilio: We only have name for one of these
23:19:44 <fantasai> emilio: Least disruptive approach is introducing a new name for the one you most likely don't want to use.
23:20:04 <fantasai> astearns: Emilio, you're worried about compat because we already have documentation and use of prefers-color-scheme
23:20:33 <fantasai> astearns: If we follow Elika's proposal to introduce a new MQ, then content would need to move over to the new feature.
23:20:48 <miriam> q+
23:20:52 <fantasai> astearns: But if we follow Tab's proposal to re-interpret prefers-color-scheme, then we break existing behavior / uses.
23:21:32 <fantasai> astearns: With both ideas, we'd be changing the prefers-color-scheme in some way...
23:21:38 <fantasai> astearns: Maybe we can shift to better names for things?
23:22:11 <fantasai> emilio: Not sensible. A lot of SVG icons using prefers-color-scheme right now. Changing that beahvior would break things.
23:22:13 <astearns> ack astearns
23:22:39 <fantasai> emilio: With Tab's proposal, if you only have one <meta> value then the behavior changes, but only if you have one of them.
23:22:45 <fantasai> astearns: Then we're locked into not quite ideal name.
23:22:47 <astearns> ack miriam
23:23:08 <fantasai> miriam: One other use case, there are variations. Lighter light modes, and darker dark modes, and darker light mods, and lighter dark modes.
23:23:30 <fantasai> miriam: So reasonable to say that you're in a dark mode with a light mode preference, and combine these two preference to choose.
23:23:42 <fantasai> emilio: Maybe use ua-prefers-color-scheme or something?
23:23:51 <fantasai> emilio: And that gets you the top-level preference.
23:24:20 <fantasai> emilio: If there wasn't tons of existing content, Elika's suggestion is strictly better.
23:25:00 <fantasai> TabAtkins: Proposal: Go ahead and change the prefers-color-scheme on the top-level page to follow color-scheme meta value.
23:25:20 <fantasai> TabAtkins: Also add a new media query that only responds to the user's preference, ignoring anything the content does.
23:26:02 <fantasai> fantasai: So like prefers-color-scheme reflects the color scheme resolved via <meta color-scheme>, and user-color-scheme reflects the user preference always.
23:26:23 <TabAtkins>  ua-prefers-color-scheme
23:26:30 <TabAtkins> (name technically TBD)
23:26:30 <fantasai> TabAtkins: And the JS API would not change the new one.
23:26:58 <florian> wfm
23:27:31 <fantasai> fantasai: Suggest we summarize the proposal into the issue, then resolve once we can cycle back to the people who had opinions.
23:28:34 <TabAtkins> PROPOSED: (prefers-color-scheme) reflects <meta name=color-scheme>. Add (bikeshed-color-scheme) to always reflect the preference coming from the browser.
23:28:36 <florian> +1
23:29:00 <TabAtkins> PROPOSED: (prefers-color-scheme) reflects <meta name=color-scheme>. Add (bikeshed-color-scheme) to always reflect the preference coming from the browser. (pending feedback from other commenters in the issue)
23:29:17 <TabAtkins> RESOLVED: (prefers-color-scheme) reflects <meta name=color-scheme>. Add (bikeshed-color-scheme) to always reflect the preference coming from the browser. (pending feedback from other commenters in the issue)
23:30:07 <iank_> are we doing any other issues today? or just republishing stuff?
23:30:19 <emilio> github-bot: take up https://github.com/w3c/csswg-drafts/issues/6900
23:30:19 <github-bot> Topic: Republishing Tasks Permathread
23:30:19 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/6900
23:30:34 <iank_> no just will walk my dog otherwise.
23:30:44 <TabAtkins> florian: I'd like to repub CSs UI 3
23:30:58 <TabAtkins> florian: currently a Rec, we've made normative changes. they're annotated as candidate corrections
23:31:05 <TabAtkins> florian: also editorial changes, they're not specially marked
23:31:22 <TabAtkins> florian: and on the basis of having repubbed we can gather review/experience, and then fold in the candidate corrections
23:31:37 <TabAtkins> astearns: you said they're candidate corrections; in the issue they're proposed
23:31:44 <TabAtkins> florian: Chris pushed back that they should be candidate
23:31:58 <TabAtkins> florian: there's an annoying difference
23:32:04 <TabAtkins> TabAtkins: I don't care about the diff while i'm minuting
23:32:19 <TabAtkins> florian: [explains anyway]
23:32:55 <TabAtkins> ChrisL: does Proposed trigger an exclusion opportunity?
23:33:14 <TabAtkins> florian: yes. Candidate doesn't. counts as a WD for the purposes of the patent policy
23:33:23 <TabAtkins> astearns: so you've done the work on the backport
23:33:26 <TabAtkins> florian: yes
23:33:56 <TabAtkins> florian: so propose to publish as Rec, having Candidate changes in there makes the update technically editorial
23:34:13 <TabAtkins> astearns: objections?
23:34:22 <TabAtkins> RESOLVED: Republish UI 3 as an updated Rec
23:34:48 <TabAtkins> florian: also, CSS Image Animation
23:35:01 <TabAtkins> florian: last time I published an ED, there were comments about things to flesh out for FPWD
23:35:11 <TabAtkins> florian: I think I've done everything, if anyone still has objection to FPWD let me know
23:35:23 <TabAtkins> astearns: I ahven't reviewed yet. I know there was back and forth over naming/etc
23:35:38 <TabAtkins> florian: Yeah, I think the problem space is now fully covered; solution isn't necessary done yet.
23:35:40 <TabAtkins> astearns: i'm good with it
23:35:43 <TabAtkins> ChrisL: i'm good
23:35:46 <TabAtkins> astearns: objections?
23:36:02 <TabAtkins> RESOLVED: Publish CSS Image Animations as FPWD
23:36:44 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13641
23:36:44 <github-bot> Topic: [css-image-animation] Applicability of image-animation to the poster image of video elements
23:36:44 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13641
23:36:58 <TabAtkins> florian: does image-animation apply to a video's poster image?
23:37:12 <TabAtkins> florian: seems the room's opinion was yes, it's an image
23:37:22 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/31-css-minutes.html fantasai
23:37:28 <TabAtkins> florian: counter-argument is it's not an image, it's a UI state
23:37:30 <TabAtkins> florian: we didn't quite resolve on it
23:37:41 <ChrisL> q+
23:37:43 <TabAtkins> florian: Do we want to resolve that it applies?
23:37:45 <TabAtkins> yes
23:37:50 <astearns> ack ChrisL
23:38:04 <TabAtkins> ChrisL: I think if we allow it to apply, users can choose whether they want it to apply or not
23:38:50 <ChrisL> s/apply or/animate or
23:38:55 <TabAtkins> RESOLVED: image-animation applies to <video> poster images
23:41:15 <TabAtkins> (florian, look at https://github.com/whatwg/html/issues/12318)
23:41:21 <TabAtkins> github-bot, take up https://github.com/whatwg/html/issues/13723
23:41:21 <github-bot> Topic: COULDN'T GET TITLE due to error HttpError { status: 404, headers: {"date": "Tue, 31 Mar 2026 23:41:21 GMT", "content-type": "application/json; charset=utf-8", "content-length": "116", "x-oauth-scopes": "public_repo", "x-accepted-oauth-scopes": "repo", "x-github-media-type": "github.v3; format=json", "x-github-api-version-selected": "2022-11-28", "access-control-expose-headers": "ETag, Link, Location, Retry-After, X-GitHub-OTP, X-Rat[CUT]
23:41:21 <github-bot> imit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset", "access-control-allow-origin": "*", "strict-transport-security": "max-age=31536000; includeSubdomains; preload", "x-frame-options": "deny", "x-content-type-options": "nosniff", "x-xss-protection": "0", "referrer-policy"[CUT]
23:41:21 <github-bot> n-when-cross-origin, strict-origin-when-cross-origin", "content-security-policy": "default-src 'none'", "vary": "Accept-Encoding, Accept, X-Requested-With", "x-github-request-id": "9C8C:2878AC:24EAB:99715:69CC5BA1", "server": "github.com", "x-ratelimit-limit": "5000", "x-ratelimit-remaining": "4995", "x-ratelimit-reset": "1775003804", "x-ratelimit-used": "5", "x-ratelimit-resource": "core"}, error: "{\"message\":\"Not Found\",\"documentati[CUT]
23:41:22 <github-bot> :\"https://docs.github.com/rest/issues/issues#get-an-issue\",\"status\":\"404\"}" }
23:41:22 <github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/13723
23:41:26 <TabAtkins> github-bot, take up https://github.com/whatwg/html/issues/13723
23:41:26 <github-bot> TabAtkins, ignoring request to take up https://github.com/whatwg/html/issues/13723 which is already the current github URL
23:41:33 <TabAtkins> github-bot, end topic
23:41:36 <TabAtkins> github-bot, take up https://github.com/whatwg/html/issues/13723
23:41:36 <github-bot> Topic: COULDN'T GET TITLE due to error HttpError { status: 404, headers: {"date": "Tue, 31 Mar 2026 23:41:36 GMT", "content-type": "application/json; charset=utf-8", "content-length": "116", "x-oauth-scopes": "public_repo", "x-accepted-oauth-scopes": "repo", "x-github-media-type": "github.v3; format=json", "x-github-api-version-selected": "2022-11-28", "access-control-expose-headers": "ETag, Link, Location, Retry-After, X-GitHub-OTP, X-Rat[CUT]
23:41:36 <github-bot> imit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset", "access-control-allow-origin": "*", "strict-transport-security": "max-age=31536000; includeSubdomains; preload", "x-frame-options": "deny", "x-content-type-options": "nosniff", "x-xss-protection": "0", "referrer-policy"[CUT]
23:41:36 <github-bot> n-when-cross-origin, strict-origin-when-cross-origin", "content-security-policy": "default-src 'none'", "vary": "Accept-Encoding, Accept, X-Requested-With", "x-github-request-id": "8F50:1CC51C:388EE:E8360:69CC5BB0", "server": "github.com", "x-ratelimit-limit": "5000", "x-ratelimit-remaining": "4990", "x-ratelimit-reset": "1775003804", "x-ratelimit-used": "10", "x-ratelimit-resource": "core"}, error: "{\"message\":\"Not Found\",\"documentat[CUT]
23:41:37 <github-bot> ":\"https://docs.github.com/rest/issues/issues#get-an-issue\",\"status\":\"404\"}" }
23:41:37 <github-bot> OK, I'll post this discussion to https://github.com/whatwg/html/issues/13723
23:41:47 <TabAtkins> github-bot, end topic
23:41:57 <TabAtkins> github-bot, take up https://github.com/w3c/csswg-drafts/issues/13723
23:41:57 <github-bot> Topic: Allow developers to set the text color under the caret when caret-shape is block
23:41:57 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13723
23:42:19 <TabAtkins> florian: if you set caret-shape to block, and don't set color, we have spec text saying UA should choose a color that maintains contrast
23:42:34 <TabAtkins> florian: we didn't handle opposite situation, a block caret and user sets the color, and now the text fails to contrast
23:42:48 <TabAtkins> florian: deliberately chose a caret that matches the text
23:43:04 <TabAtkins> florian: user might expect the *text* to then contrast the caret
23:43:22 <TabAtkins> florian: I propose we extend caret-color to have an optional second argument, giving the color of the text when it's overlapping the caret
23:43:25 <ChrisL> q+
23:43:35 <TabAtkins> florian: if we don't have compat, make the default be "browser can flip color if needed".
23:43:50 <astearns> ack ChrisL
23:43:52 <TabAtkins> florian: otherwise default is currentcolor
23:43:57 <TabAtkins> ChrisL: what are caret-shape options?
23:44:02 <TabAtkins> florian: bar, underscore, block
23:44:20 <TabAtkins> ChrisL: what happens with descenders/etc outside the caret?
23:44:31 <TabAtkins> florian: stepping back, the block caret is already somewhat sensitive to text around.
23:44:40 <TabAtkins> florian: it checks the next character so it can be the right width
23:44:59 <TabAtkins> florian: i'm suggesting that, with the same definition, can look at text color, and is allowed to be smart about swashes poking out
23:45:32 <TabAtkins> florian: at least apply the color to the active character. if you're extra smart, maybe do visual intersection
23:46:32 <TabAtkins> ChrisL: my concern is a character changing color due to caret but its acute accent is a different color
23:46:39 <dshin-moz> dshin-moz has joined #css
23:46:43 <TabAtkins> florian: my default proposed behavior is that the ehwole next character changes color
23:46:57 <TabAtkins> florian: so two qs. first, do we want this second parameter at all?
23:47:19 <TabAtkins> florian: if yes, is the default `currentcolor` (as it currently effectively is) or is it `auto` that preserves contrast?
23:47:32 <TabAtkins> florian: I suspect the most compatible behavior is to allow currentcolor+auto and default to currentcolor
23:47:36 <TabAtkins> florian: but maybe not ideal
23:48:11 <TabAtkins> ChrisL: or add a new property, caret-color-text
23:48:15 <TabAtkins> florian: yeah, that's another approach
23:48:29 <TabAtkins> astearns: q of add a value or a separate property hinges on whether you need these to cascade seperately
23:48:33 <emilio> scrollbar-color is a similar precedent
23:48:34 <TabAtkins> florian: I think you want them together
23:49:16 <ntim> q+
23:49:17 <TabAtkins> kbabbitt: I was thinking about a use-case where I have a paragraph of text that's mostly one color except a span, I might want the caret to follow the underlying text... maybe that means it should be two properties
23:49:27 <TabAtkins> ChrisL: you could also do a  relative color using currentcolor
23:49:49 <TabAtkins> florian: I think because it'sa bout contrast you want to set them together
23:50:02 <astearns> ack ntim
23:50:07 <TabAtkins> ntim: where does that second color show up?
23:50:19 <astearns> q+
23:50:27 <TabAtkins> florian: in bar or underscore it doesn't matter, but if you have a block caret it overlaps the next character
23:51:04 <TabAtkins> ntim: so you'd have the original text...
23:51:16 <TabAtkins> TabAtkins: The following character is rendered in this new color
23:51:28 <TabAtkins> ntim: oh I thought the caret covered the text
23:51:39 <TabAtkins> florian: No, it displays the text still
23:51:46 <astearns> q-
23:51:49 <TabAtkins> emilio: for anything other than block, you just draw it on top
23:51:58 <TabAtkins> florian: but for block you do render behind/around
23:52:19 <TabAtkins> florian: this property *would* allow you to make the text invisible with the caret if you want
23:52:52 <TabAtkins> TabAtkins: I think I've seen console environments with either behavior
23:53:09 <TabAtkins> astearns: if this second color was specified with underline or bar, it just wouldn't have an effect?
23:53:11 <TabAtkins> florian: yes
23:53:50 <TabAtkins> astearns: so are we arriving at a proposed resolution?
23:53:59 <TabAtkins> astearns: objections?
23:54:10 <TabAtkins> arronei: do we want to clarify we don't want a property?
23:54:20 <TabAtkins> astearns: it's in the discussion and the resolution will be for the second value, specifically
23:54:40 <TabAtkins> RESOLVED: Add a second color to caret-color which sets the font color of the following char when caret-shape is block
23:54:50 <TabAtkins> florian: now second question: is the initial value current-color, or auto?
23:55:07 <TabAtkins> florian: current Chrome behavior is effectively currentcolor
23:55:39 <TabAtkins> florian: downside is authors *might* have their own idea of what's ok, and already be happy with their text+caret colors
23:56:45 <TabAtkins> TabAtkins: I suspect, since the major use-case of block caret is console emulation, and consoles (at least, mine) do the inversion, we should default to "auto"
23:56:50 <TabAtkins> florian: happy to spec it that way
23:57:12 <TabAtkins> PROPOSED: Default value for this new second color is "auto", letting the UA decide on the contrasting color
23:57:17 <TabAtkins> astearns: objections?
23:57:24 <TabAtkins> RESOLVED: Default value for this new second color is "auto", letting the UA decide on the contrasting color
23:57:49 <TabAtkins> florian: if the author actually wants the color to be the same as the rest of the text, do we expect them to type currentcolor? or give them "normal"?
23:57:53 <TabAtkins> fantasai: currentcolor seems fine
23:58:11 <TabAtkins> florian: k
23:58:35 <TabAtkins> github-bot, end topic
23:59:10 <TabAtkins> <br dur=16h>