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