Meeting minutes
Shared Element Transitions
github: https://
JakeA: [slides]
JakeA: I'm helping out with this Shared Element Transitions work, along with Jeremy and Khushal
JakeA: Current state: when you navigate on the web, the page just changes
JakeA: but on apps, especially in mobile, you get these lovely transitions betweens tates
<fantasai> [slide shows various transitions, like sliding in a sidebar, swiping across panels, etc]
JakeA: they look nice in person, and can even be directly useful, to help communicate transitions between states so there's less context loss
JakeA: I asked people on twitter about this, especially if they'd like it in a SPA or MPA (multi-page app)
JakeA: most people were interested in it for a multi-page app!
<fantasai> [slide shows Twitter survey of SPA vs MPA, 31% to 52.9%]
JakeA: I see why - you can already kinda do it in a SPA, but it's impossible in an MPA
JakeA: Strong feeling that many sites *become* SPAs just to get these transitions; not sure, but it feels like it.
JakeA: And that's a problem, SPAs have a lot of issues, and they're often done badly.
JakeA: But even when done by experts, you lose things like HTTP streaming, gain a big JS bundle, etc.
JakeA: So thinking about this space
<fantasai> [slide shows timeline]
<fantasai> [2015: Chrome proposal and experiment]
JakeA: 2015 was an early chrome proposal, didn't go very far, and the people left for other projects
<fantasai> [2015: Chris Lord (Mozilla)'s sketch]
<fantasai> [2017: Jake's sketch]
<fantasai> [2018: Tab's sketch]
JakeA: 2017, I sketched an API. Each time we learned more things that might work.
<fantasai> [2021: This round!]
JakeA: 2018, Tab had his own proposal
JakeA: And now we're here today
JakeA: Not the first people to even try this out, back in '97 IE had something.
<fantasai> [1997: IE4 with navigation transitions via meta http-equiv="page-enter"]
JakeA: 24 years ago, you could use <meta> to do page transitions
JakeA: there were 22 transitions to choose from; several dupes from different directions, like "wipe left" and "wipe up"
<fantasai> [ <meta http-equiv=page-enter content="RevealTrans(Duration=0.600, Transition=6)]"> ]
JakeA: also a special 23rd transition that made a random choice
JakeA: slightly kidding, but I think a predefined set of transitions can get us pretty far
JakeA: But not all the way, I got feedback from people asking for custom control
JakeA: If we look at some of the nicest transitions in the android docs
JakeA: It's animating between states in multiple ways; some things are shared between the states
<fantasai> [shows Android Contacts list, clicking on name of person shifts the name up and colors/layout changes to show a profile]
JakeA: This person's name in the address list moves to be the header for their profile
<fantasai> [Jake's homepage with 2-line title vs 3-line title]
JakeA: on my blog, when you're on the index page and click thru to an individual post, the headers are basically the same. why coudln't that transition?
JakeA: Every element on the two pages are different, even different tag names.
JakeA: Some elements change content, some elements (dates) don't change content but do change position.
JakeA: Header changes layout, it does a fade to the new larger text
JakeA: and header container scales its height
JakeA: then the rest of the page just fades content
JakeA: There was a bunch of moving parts here, but overall, it was simple because it was done with just textures, no live layout between the two
JakeA: So didn't need to keep the old page alive
JakeA: there are some concepts we keep coming back to
<astearns> https://
<fantasai> [slide: Change]
JakeA: First, there's a change
JakeA: Before that, we need a prepare step
<fantasai> [slide: Prepare, Change]
JakeA: where the outgoing page offers up parts of itself to be involved in the transition
JakeA: Like my blog example, offering the header, the date, the sidebar
<fantasai> [slide: Prepare, Change, Transition]
JakeA: Then the change happens, letting the outgoing page be cleared from memory except for the textures it's offering up
JakeA: Then the Transition happens, where the new page animates in
JakeA: LIke, if you have a series of chat messages, the old page might have three messages, the new has four; the three can just fade in, but the fourth has to do something special; this is where that can happen
JakeA: Like I said, these are textures; we don't want to do layout on the old page
JakeA: But we also don't want the new page to get pixel readback from the old textures
JakeA: New page is trusting waht the old page gave it - it says "this is a heading!" and the new page trusts that it's a heading
JakeA: for cross-origin transitions that's a potential concern
<fantasai> [slide: cross-origin transitions]
JakeA: The old page could offer up bad stuff
JakeA: A bad page could transition into a news page, offering up its "header" and boom, it's the q-anon logo
JakeA: So cross-origin transitions either need to be heavily restricted
JakeA: Or need a two-way handshake to agree on which textures to share
<fantasai> [slide: single-page app transitions]
JakeA: There's also single-page app transitions
JakeA: Not as many authors are interested
JakeA: because they're actually quite hard to do today
JakeA: You need DOM for both states at once, which means you need to protect the old stuff from being interacted with, or being seen by a11y tools
JakeA: Need to control for scroll position, how it can mess up CSS mid-transition, etc.
JakeA: Twitter says they don't do transitions precisely for these reasons
JakeA: So we were thinking about this and realized this should work on the page transitions model just as well
<fantasai> [slide: prepare, change, transition]
JakeA: You're still doing a prepare phase to record bits of the old state, then you transition into the new state
JakeA: We already ahve a sketch of the SPA model behind a flag in Canary
JakeA: Here's an example of the Preact website
<fantasai> [slide: preact website SPA]
JakeA: Author of the site says it's "a mess", but it has a router for the overall site transition as many SPAs do
JakeA: But even tho I didn't understand much, I could easily poke in and add the transitions API, and it all just works
JakeA: BAck button reverses transitions, it's all just very little code
<fantasai> [slide: preact website with subsections fading in and out in the content panel]
JakeA: In spirit, our current design is very similar to the old IE version, with a list of predefined transitions
JakeA: New bit is this "shared elements" notion, like the heading and sidebar in the guide.
JakeA: In this example I'm using this to keep them in position and only change the content by sliding it in
<fantasai> [slide: Interesting Problems]
JakeA: While we need the bare-bones for EWM reasons, I think there's definitely a high-level version that solves 80% of cases
JakeA: Some problems.
<fantasai> [slide: cross-fading]
JakeA: First is cross-fading. Transitions have a lot.
JakeA: Hard to do in CSS rightnow
JakeA: Especially between elements with transparency.
JakeA: Can use explicit opacity on the two states
<fantasai> [slide with .thing1 { opacity: 1 } .thing2 { opacity: 0; } ]
JakeA: here's a slide where the two are identical save for a few extra words on the second
<fantasai> [slide: cross-fade shows image, which doesn't change, fades to 50% hafway in the transition]
JakeA: Midway thru the transition the shared pixels fade a bit, ideally we could fix this
JakeA: CSS has a cross-fade(), which does the right thing
<chris> This is because the cross-fade needs to be done in linear-light
(That's not the only reason)
<chris> so that 0.5 + 0.5 = 1.0 :)
cross-fade() also blends sizes tho
JakeA: Which isn't always what we want
<fantasai> [slide: background-image: cross-fade(...); ]
<fantasai> [slide: Not quite elements, not quite images]
JakeA: We're not dealing with elements *as such*; images might be okay since we've just got textures left over
<chris> (interested to know the other reasons)
JakeA: but not all an image - Some information like transforms we might want to carry over so it can animate properly
<fantasai> [slide: timings and deadlines]
JakeA: Another thing to think about is timings and deadlines
JakeA: Right now when you click to a new page, the browser shows the new page when it wants, when the data comes in
<fantasai> [slide: iWouldLIkeToDoAPageTransition(); ]
JakeA: But if the incoming page wants to control the transition, it should be able to signal for it
JakeA: But how long can we wait?
<fantasai> [slide: iWouldLikeToDoAPageTransition(); await massiveImageLoad; nowDoTHePageTransition(); ]
JakeA: How long do we wait for the "i want to handle this" signal, and how long do we wait for it to actually do the transition after it signals?
JakeA: We like progressive rendering
JakeA: Do we want to allow pages to delay until a 5MB image loads?
JakeA: They can do it today, kinda
<fantasai> [slide: Thoughts? Questions?]
JakeA: But maybe if they, say, don't do it in 5s we just do a page swap
JakeA: So, questions?
<chris> Jake Archibald 17:28 https://
<JakeA> https://
<JakeA> https://
<JakeA> https://
florian: Intriguing! Overall makes sense at a high level.
florian: Curious how much ends up being declarative vs JS, how they intertwine, I'm sure y'all are thinking of this
florian: There was also something between IE4 and modern stuff. I believe Opera experiemented around 2010
florian: They were a little like the declarative transitions, but also a concept of arranging things in space, so you could say "this page is left of that one" and it would automatically swipe over to it
florian: tied into gestures as well
florian: Wondering if there has been any thought on these lines, including tied in with the "shared elements" part
florian: This notion of arranging bits of space, I thought it was interesting
florian: Doesn't seem obvious that it doesn't fit
JakeA: Hard to talk about binary declarative vs imperative
JakeA: For some peopel it just means "JS" vs "CSS", but Web Anim - which is it?
JakeA: We almost certainly will end up with something declarative to some extent
JakeA: Lot of desire to do this animation out of the control of either page; the pages just dictate how they want it to go, but it's actually handled outside
JakeA: I did put a sketch together purely in CSS, and I think I got to 15+ properties and hadn't thought about the destination url negotiating yet...
JakeA: I anticipate the destination being done in JS at least
JakeA: And maybe there's a smaller subset that can be done in pure CSS with simple behaviors
JakeA: Before I had the ability to associate elements with some ID, and if the destination page uses the same ID they're autoamtically tied together
JakeA: In the JS API I presume it'll be similar.
JakeA: There needs to be a way to give more information - like, by default it maybe just translates, cross-fades, and scales
JakeA: But scaling isn't always what you want, as I showed in some examples
chris: if you've got two things transitioning opacity...
chris: You need something where .5 + .5 = 1. That needs linear light; images aren't linear painted, which is why there's lightening.
TabAtkins: linear-light was one problem
<chris> agreed
TabAtkins: Other problem is that halfway through, two 50% things laid on top of each other means together they are only 75% opaque
flackr: Gaming has opacity saturation buffers to solve this
khushal: Yeah we foudn that, there's a blend mode that can do that
khushal: I found a webkit bug asking to expose this to mix-blend-mode
emilio: so the idea is that the destination page can observe stuff about the transition, like position of old elements
<khushal> https://
emilio: That seems like in conflict with the UA being able to control the transition
JakeA: we hope within the API to catch spots where, like, if an error is thrown it doesn't deadlock the transition
JakeA: With this model you can definitely delay the intro of your own page. Having the incoming page control it means you're only harming your own perf
JakeA: Question of how much we want to prevent people - they can already delay their own page arbitrarily.
JakeA: Worry about damaging legit use-cases to guard against some peopel getting it wrong
emilio: Main thing I'm concerned about is an animation working on a good computer, but breaking on a crappy phone
JakeA: Right, so think if the transition isn't ready within 3s we just bail, or something like that
JakeA: Like doing font-rendering intervention
emilio: I took a look at the API, which is promise based; if you bail on the transition it rejects the promise, right? If the promise rejects unexpectedly the page might still break.
emilio: This would be much simpler if the UA could decide what to render without the destination page being involved, but I understand it breaks some of the fanciness.
JakeA: I see you're looking at the GH page for the API; that's still in flux
JakeA: We're def looking at ways to mitigate these problems
JakeA: Issue on GH right now looking at moving to a JS API similar to WebLocks
JakeA: In that you provide a callback to run later that returns a promise. Errors become rejected promises instead of breaking script, so you somewhat avoid deadlock.
khushal: design thing i'm thinking about, which page controls the transition. reasons for that to be diff between same-origin vs cross-origin
khushal: Incoming page controlling the transition is good bc it has info from both sides, and can make better decisions
khushal: But for cross-origin cases, we can't let the incoming page know about the outgoing page, so the outgoing page has to control the transition completely
khushal: This requires different API shapes, and it's causing some API divergence
JakeA: This is something I ran into for the CSS-only version
JakeA: If you've got a shared item in the outgoing page which doesn't have an incoming equivalent, or vice versa, it becomes hard to deal with
JakeA: It's hard in CSS to talk about an element that isn't there
JakeA: Whereas in a JS callback you can get handed five elements, and four match int he new page, and you can figure out what to do with the leftover
astearns: You mentioned pixel access - I assume incoming page has no pixel access at all
JakeA: correct
JakeA: Probably model will be outgoing picks up an element for sharing, and a StructuredClonable of info about it, like "I'm a heading" or whatever
JakeA: But no pixel access
JakeA: Hope we can one day get to a state where we can read the pixels on a page
JakeA: We have origin isolation right now, maybe some even stricter version could some day allow this
astearns: And with outgoing pages opting into data sending, for cross-origin the incoming page might need to be restricted from knowing which of its transitions actually matched. No info about which headings matched, etc, just always run them
JakeA: two angles there - don't want Page A to find info about Page B they didn't want to share
JakeA: In some cases the number of chat messages can leak that
JakeA: But there's also Page A and B *wanting* to share info, but for privacy we don't want to allow them
JakeA: Not sure where the line is right now
JakeA: Might be that cross-origin is just the IE model - a list and the whole view moves
astearns: you talked about having a high-level declarative variant with less features
astearns: I hope if we get there, the high-level thing can be hooked by the low-level, so you can intervene when necessary
+1
JakeA: Yeah, I think CSS shorthands model is something like what we want to go for
JakeA: Can set up a "sliding" animation, and it can specify a WebAnim-like set of keyframes
JakeA: And maybe we just wrap that up in "slide-left" keyword, but with full control to do your own
<Zakim> fantasai, you wanted to mention incremental rendering
fantasai: One, incremental rendering, if you're on a slow connection you want the partial page to show up early
fantasai: dunno how that's considered right now, just want to make sure it's not forgotten
<astearns> prefers-reduced-motion would turn all of this off, presumably
fantasai: There was also a discussion about shared element transitions in Burlingame, I think, not sure if there are notes or if it was informal; think Ojan was involved
fantasai: Big point I remember there was that cross-origin ones shoudln't leak info
fantasai: Another idea was sharing a timer between the two, so outgoing and incoming pages could put things on the same timeline
fantasai: Coudln't necessarily coordinate between elements, but could at least ensure timing matched up
JakeA: For incremental loading, def one of the fundamentals I want to keep.
JakeA: Def a tension between that and page transitions
JakeA: Would be nice to have a way to say "don't transition until X element is around"
JakeA: Very hard to do right now, tricky with a Mutation Observer
JakeA: Might be a waitForElement() API to let you delay as little as possible
JakeA: In the blog example I want *some* of the content to be there, but don't need the whole page necessarily. Probably want a way to say I just need the top of the page, not the stuff a MB away
JakeA: Nothing concrete there yet, but it's on our minds
JakeA: I didn't know about the transitions discussion
JakeA: I'll try to find notes
JakeA: In chat Alan asked about prefers-reduced-motion
JakeA: Yeah we'd just ignore the transition in that case
JakeA: Re: leaking cross-origin, absolutely a concern, need to lock down properly
JakeA: re: timeline sharing, that's similar to my previous 2017 idea
JakeA: That version required both pages to be alive at the same time
JakeA: which is an issue for low-memory devices
JakeA: Thought right now is one side controls the transition; the other side just offers things to be transitioned
khushal: interesting to think about whether incoming page *has* contextual info to control the transition or not
khushal: if you're on a news aggregator, and it wants to have a transition to links, ok. but if the user enters in the omnibox, maybe the incoming page gets control over that instead. or maybe browser-initiated just doesn't get transitions.
khushal: Also, re: same vs cross-origin
khushal: In same-origin when incoming can control, we also let it control when the transition states
khushal: and it gets all the info about the outgoing page, so it can do smart things
khushal: but in cross-origin, when the incoming page doesn't have any info but might still have useful timing info, that's a difficult question
eugene: Riffing on khushal's comments, if you have cross-fade capabilities, the omnibox can do its own thing controlled by the UA
eugene: we've also got scroll-to-text capability now
eugene: and ideally when you're referring to a shared element, hopefully we have a consistent way to refer to those elements
eugene: another comment, declarative vs imperative. declarative is basically marking up a single transition, I think it falls down when you want multiple things simultaneously
eugene: So it's important to ahve the models build on each other
eugene: Big call for extensibility, building more on top of this
eugene: Think the right model is to build on the animations ecosystem, so all the existing animations work, and users get new abilities as animations get better
JakeA: re: scroll to text, I think you can use a css selector to id the element
JakeA: that works okay for sscroll-to-text because the lifetime is relatively short
JakeA: And if the highlighting doesn't work, it's not a huge loss
JakeA: Coudl be worse on transitions
JakeA: concern I have is you're navigating around a site, and mid-article the site redeploys and the class names have changed
JakeA: So model we're using right now isn't tags or selectors, it's literally just a bunch of named element references
JakeA: {"heading": someDOMEl}
<jbroman> I think scroll-to-text uses a snippets of text rather than CSS class names to avoid this
JakeA: Might need a way to bail on transitions so if two versions of a site are totally incompatible they cna figure it out
eugene: I think if it's a problem for page transitions, it'll be more of a problem for people who save links from their search bar; "scroll to image" is just as bad
It does, yes.
flackr: I assume that BF nav, we want to use the transition that you saw when you came in
flackr: Not sure how it would work with the current API
flackr: But should be some way of memorizing the transition so we can reverse it if we go back
flackr: Is that something we can do?
JakeA: Yes, and the more autoamtic we can do the better; people don't often test that
JakeA: Maybe we only do it if the page is in BFCache
JakeA: gets more complicated if you're reloading the old page as well
JeremyRoman: This is a very big rathole, but interesting
JakeA: I think limiting it to BFCache and only +1/-1 transitions is a good start
astearns: Assuming you'd like more feedback in the WICG repo?
JakeA: Yes, that's the right place for it
astearns: And we can do CSS issues when you come up with a declarative CSS version of this
JakeA: Absolutely. Thanks!
<jbroman> +1; thanks CSSWG for your time
<vollick> thanks, all!
astearns: I think it'll be great to bring the web platform back up to IE4 standards.
<br dur=10min>
<JakeA> https://
<JakeA> For the minutes: https://
Pause media playback in iframes hidden by content-visibility:hidden
<astearns> github: https://
<JakeA> Thanks again for inviting me!
chrishtr: Web developer raised use case of wanting to automatically pause videos, media
chrishtr: in situation where media happens to be in iframe, page can't really access it, because usually cross-origin
chrishtr: atm can only do that by coordinating with each provider of video
chrishtr: Perhaps platform can make that possible
chrishtr: Suggestion was content-visibility to control that
chrishtr: content-visibility is meant as a perf tool, and this is about reducing unnecessary use of CPU
chrishtr: so ...
chrishtr: so seems that media under content-visibility be automatically paused
chrishtr: final point is, as I understand, for web-compat a lot of sites expect video, esp with audio, when not visibible for other reasons
chrishtr: e.g. off screen or detached from the DOM
chrishtr: But since content-visibility is new, probably not compat worry
TabAtkins: I'm surprised at how many things still allow video to play
TabAtkins: This seems like a good idea
astearns: I'm not sure I'd look for content-visibility as a way to make cross-origin video stop playing
florian: In that direction not obvious
florian: but in other direction, would you expect a video with content-visibility to play?
flackr: display:none might have similar effect
flackr: might also unload frame...
Rossen_: Display:none is a big hammer
<TabAtkins> It does unload the frame
emilio: Idea is to also do this for same-origin stuff?
emilio: ...
emilio: Is there a ? on if you remove element from the DOM, then it doesn't stop playing, then you add content-visibility and then remove from DOM it's paused, that's weird
emilio: Doesn't pausing media change styles?
emilio: causes :pause to apply ...
emilio: maybe not a huge deal if under subtree, but also weird
emilio: overall, I think removing video from DOM should pause
emilio: seems weird that content-visibility is the only thing that does this
chrishtr: Yes, it would be all media
chrishtr: issue says iframes, but would also apply to same-origin video within the document
chrishtr: wrt relative timing, seems similar to detaching video after user presses pause button
chrishtr: same thing, rendered as visibible under content-visibility
chrishtr: thrid point was about how styling changes when it's paused
chrishtr: I think yes, those styles would conceptually apply, just like all boxes within content-visibility subtree
chrishtr: but UA is allowed to not render within that, for perf reasons
emilio: Does content-visibility currently change styles under its sub-tree?
emilio: I guess it pauses animations, which is something
flackr: It pauses animations in a way that is not very developer-visibible
flackr: the timer keeps going
flackr: For this video, could maybe not change state to pause, but would not continue playing
Rossen_: Is that how we have it specced?
Rossen_: content-visibility is currently defined as behaving like 'display: none' on contents
Rossen_: [quotes spec]
Rossen_: display:none does not exhibit the behavior you just described for animations
flackr: That's a misleading statement, interaction should not continue ..
astearns: That note is about accessibility, but it's not clear what that note is hooked to
<Rossen_> https://
<dholbert> https://
emilio: But this isn't what the OP filed the issue about
Rossen_: you get to some part of the video, or would you start from the beginning?
astearns: The idea is it will pause, and then resume after visible
astearns: detaching would restart the video which is not good
chrishtr: Pausing video seems simpler to implement
<flackr> content-visibility animation pausing was spec'd by https://
chrishtr: already way to pause videos in UAs
chrishtr: Wrt styles, can leave styles uncomputed
emilio: Why not for animations?
Rossen_: display:none will stop animations entirely
Rossen_: but wrt animations, it's different than what I'm hearing about video that's described by ??
Rossen_: in case of animations, supposed to pretend they're running, but not actually run and use up CPU
Rossen_: when you return, get to more advanced stage
Rossen_: video ...
Rossen_: saying 2 are the same is not right
Rossen_: If we want this behavior for video or media
Rossen_: differentiate clearly so people would know what to expect
chrishtr: Leaving video playing but not using CPU to do texture stuff is problem, because still have audio
chrishtr: otherwise UA would have to keep audio stream running, but not the video stream
Rossen_: you can pause, and then take them forward, by the delta
Rossen_: as if the video was playing
<TabAtkins> fantasai: What Rossen said - if you wanted animations and videos to be consistent, you'd need to advacne the timer on it even when it's not playing
<TabAtkins> fantasai: I think it would be good to treat them the same
astearns: and if you did that, then you would not set the pause style on the video
<TabAtkins> astearns: And if you did that, you would *not* set pause on the video
fantasai: right
flackr: because content-visibility:auto hides things as scrolled out of view
flackr: ...
flackr: this is why we had this behavior for animations
emilio: pausing a video not only changes styles, but also triggers JS events
emilio: really a problem when style change triggers a bunch of JS handlers
emilio: ...
chrishtr: for animations, we did decide that although video is conceptually advancing in time, it doesn't fire events
chrishtr: since that goes against perf goals
chrishtr: could potentially just not fire the events
flackr: concern was audio, could also conceptually mute the audio
astearns: that would meet the perf goal, but I wonder
astearns: I get annoyed when I scroll Twitter just slightly enough, but want to keep hearing it
TabAtkins: I have exactly opposite problem with Youtube videos when I scroll away
chrishtr: Could conceptually allow the video to continue, but mute it, and get all the perf advantages
chrishtr: solve use case of pausing the videos some other way
<TabAtkins> s/Youtube videos open in a tweet where they *don't* stop playing/
florian: conceptually playing doesn't mean actually playing, can just move the timer and not do work
florian: but for use cases where authors do want to pause
florian: could send an event
florian: and then video can react to that state
florian: same thing could apply to animations, things applying to canvas, etc.
florian: all things trying to be on the same timer
chrishtr: I think you're referring to an event where you can identify when you are skipped?
chrishtr: Discussed on and off. There are use cases for it, like avoiding work in scripts
chrishtr: A video, for example, inside cross-origin iframe could pause when skipped
chrishtr: Similar use case from gmail, cross-origin iframes, would like to be able to stop themselves when they are noticed they are skipped
chrishtr: don't want to poll server to ask for more when not visible
Rossen_: appears we're drifting off the main task of pausing the video
Rossen_: rather than aligning behavior with scrolling and animations
Rossen_: user request we have as well, people want to pause video when scrolling away
Rossen_: At least the current described behavior for content-visibility:hidden doesn't quite align with that
Rossen_: so behavior that advances animations and advances stuff, are we talking about a different behavior here
Rossen_: a pause-media? could be helpful
Rossen_: allows two behaviors co-exist
Rossen_: or have users control one or the other
Rossen_: also what is the event model going to look like?
Rossen_: are you going to get all the events on the DOM side
Rossen_: if trying to synchronize animations with your video
Rossen_: one moved ahead and other paused, etc.
Rossen_: 2 different behaviors, let's discuss them separately
Rossen_: define what pausing looks like and then figure out how they can co-existy
chrishtr: I think 2 options are pause the video, or conceptually continue video but muted
<florian> ?
Rossen_: They weren't asking for that
chrishtr: that's what person was asking for, however ...
astearns: Fits more with existing behavior of content-visibility, to conceptually run it
astearns: So should do that
astearns: and then discuss use case of pausing
chrishtr: Talked to developer
chrishtr: didn't want to keep playing video, audio is annoying
chrishtr: and also didn't want to take up bandwidth
chrishtr: easiest way was to kill it off
chrishtr: I do think that perf and muting things won't solve everything but will help
emilio: Other question is pausing, does it fire events, does it not fire events
emilio: Media has a bunch of crazy things going on
fantasai: Should we resolve on the timer continuing while it's actually paused?
astearns: Proposed to treat video similar to animations in content-visibility, is conceptually muted, will return with intervening time skipped
astearns: any objections?
flackr: don't object, but that's not identical to animations
flackr: not ticking animations is what user would have seen if animation continued to tick
flackr: but muting audio is a bit different from ...
flackr: but given that content-visibility is a perf optimization I"m not objecting
Rossen_: with this behavior, are there any events?
chrishtr: no events will fire, it's not observable
chrishtr: querying the element might trigger events or something, kinda like animations
Rossen_: So observability will be aligned with that of CSS animations as well
chrishtr: yes
<dholbert> my question (in case my audio won't work) is: does this mean Twitter couldn't use content-visibility & also match Alan's expectations of letting videos continuing to play even when they're scrolled offscreen?
chrishtr: observability to script same, observability to user a bit different because muted
astearns: note Twitter right now stops the video when scrolling out of view
dholbert: Twitter version that matched Alan's expectation mean can't use content-visibility?
dholbert: if want to still have audio play while off-screen
astearns: You just don't use content-visibility in that case
dholbert: yes, but Twitter might want to use content-visibility ...
TabAtkins: the benefits of c-v are precisely that the browser can stop committing resources to things, rather than keeping videos around multiple times
<Rossen_> conten-visibility: hidden pause;
dholbert: I feel like I"ve heard from our media team that we already stop streaming video in background tabs, there's optimizations that can be made there
dholbert: maybe can do that here too
smfr: websites like youtube and ??
smfr: manipulating through script
smfr: if no notification to video that it's being paused, will still run all that stuff
smfr: which is a waste
smfr: are we resolving for skipped content (also affects content-visibility:auto) or only content-visibility:hidden
chrishtr: proposal is to apply to all skipped content
smfr: are we trying to avoid detectability of when content becomes skipped or unskipped?
chrishtr: the events that determine whether skipped, can also consider
chrishtr: raised issue of ? video
chrishtr: or youtube video automatically pause themselves when they notice that they are skipped
chrishtr: in order to raise the other use case in the discussion
<Zakim> fantasai, you wanted to respond to flackr
<TabAtkins> fantasai: wrt the idea that muting the audio isn't entirely consistent
<TabAtkins> fantasai: it kinda is if the audio is part of the visibility of the element
<TabAtkins> fantasai: which is true in an audio enviro
<TabAtkins> fantasai: so don't think it's entirely inconsistent
<TabAtkins> fantasai: not sure if this is the mechanism we want to use to allow videos to be paused
<TabAtkins> fantasai: might want to do it more explicitly, rather than building it into this
<smfr> +1 for more explicit control. you don’t want Command-F to start videos making noise
<TabAtkins> fantasai: bc depending on the use-case you might want it to still play
florian: idea reasonable, especially with event that allows you to customize behavior
florian: maybe can then combine with API to pause an entire subtree
florian: but comment from smfr got me wondering, if you just think about things being skipped or not being off-screen, whole thing we discussed is reasonable
florian: but if things are unskipped
florian: suppose you search for word 'play', then they all start playing with video
florian: not a great user experience
florian: can no longer be skipped due to things other than being off-screen, maybe isn't great
flackr: if you scrolled something into view, would start playing
flackr: but because most search results off-screen
flackr: we'd resolve their style to figure out whether they match the search, but they're still off-screen and will continue to be skipped
chrishtr: would be able to see the track time, but not playing
smfr: what if UA makes all content unskipped when finding in content-visibility:auto
chrishtr: spec says that [...]
chrishtr: it will only become unskipped when scrolled into view
smfr: per-element granularity?
chrishtr: every element that becomes unskipped
smfr: confused about the granularity of skipping
smfr: suppose container with auto
smfr: inside it each element becomes skipped or not individually?
chrishtr: granularity is content-visibility:auto element
astearns: This seems to be more generally, could you read through spec and open an issue if it's a problem?
smfr: ok
astearns: back to media playback, any other comments before we try for a resolution?
[silence]
<TabAtkins> (There's text in <https://
Resolution: conceptually play (invisibly and muted) any media playback for things that are skipped due to content-visibility, skipping any events unless queried (as for animations)
<br duration=10m>
break
Should transform affect scroll-direction of touchpads?
github: https://
fantasai: the question is what happens to various ways of scrolling when you have a transform
… on firefox the wheel follows logical directions
… while touchpad uses physical directions
… other UAs do different stuff
… this is not defined, do we want to specify this?
TabAtkins: Given the complexity of what transforms can do to an element I doubt that we can provide strict rules
… but guidance sounds good
<fantasai> +1
TabAtkins: flipping an element and scrolling with the trackpad should probably scroll visually
smfr: I'd prefer not defining this strictly, we rely on UIKit and doing something different is probably very hard
florian: If you manipulate a touchscreen there's a clear expectation, but mousewheel is different. Should guidance for direct manipulation sounds worth it but trackpads are harder
<chris> yeah users have two, conflicting, ways that touchpads and mice should work and each user hates one of them
Rossen_: seems there's agreement to add guidance, would this go to overflow?
florian: yeah, we talking about a note?
Rossen_: yeah
florian: fine by me
Resolution: Adding a note describing the behavior to the css-overflow spec
scroll-index
github: https://
florian: not my issue but I wanted to give it some attention
… The use case is something we see on lots of websites, with a top banner that disappears but reappears if you scroll up again
… This author is thinking of this in terms of nested scrollers
… where your top banner is in a scroller outside the inner one
… we always prioritize the inner scroller
… but the author was proposing to prioritize the outer scroller, and only when that is exhausted scroll the inner one
… no strong opinion, there could be some parallels with overscroll-behavior
… just wanted to bring some attention to the issue
TabAtkins: I find the use case good to address because lots of sites do this badly
… but I think this approach is not the way to go
… first this doesn't do what lots of sites do which is having a minified banner
… second, it seems very easy to screw up a page if you only test on desktop
… the current behavior is safer for that
… So I think the problem is good, the solution is bad
… we probably want another way to do this
flackr: I was going to point pretty much the same
… you only want to do this scroll priority inversion for the topmost scroller
… if you have nested ones then scrolling the header is probably not what the user intended
… so it seems a bit of a problematic solution
Rossen_: sounds like the use case is well recognized, but the proposed solution is not
<argyle> agree with robert and tab
Rossen_: I suggest to go back to the issue to discuss the solution
florian: so the issue was proposing the solution, you're proposing to repurpose it right?
Rossen_: sure
florian: sounds good
Rossen_: yeah, it seems like we should explore a good solution for this problem
republish fonts 4/5
github: https://
chris: we discussed this already and have a resolution so I'm puzzled
<fantasai> github: none
astearns: it seems the tag didn't get taken off
Replaced elements canvas, img, etc should behave as expected when styled with relative sizes in grid, transferred size should not affect them unless specifically asked to
github: https://
TabAtkins: iank_ asked us not to resolve on this, but we can probably discuss
<chris> seems to capture not only an issue but also a proposed resolution
Rossen_: should we move on to other issues?
TabAtkins: let's move on
<fantasai> github: none
Any needs to avoid other layers overriding name-defining @-rules?
github: https://
miriam: so it's possible to give importance to e.g. using an animation (like using !important on animation-name)
… but there's no way to do the same for the animation definition itself
… we discussed how name-defining constructs should behave for layers, but there's no way to make them difficult to override
… that seems fine to me but OP wondered about whether there's a use case for it
TabAtkins: without a strong use case I'd rather avoid adding another level of layering given they interact with tree scopes already
miriam: agreed
fantasai: how many of these things we have? We haven't needed one so far
fantasai: layers end up reordering these name-defining constructs, and the question is whether it's needed to make them important
… important is really about needing something to be overridden
<TabAtkins> The fact that nobody's request the ability to put !important on these constructs so far (which is today's poor-man versino of layers) suggests it's not needed
fantasai: I don't think we need to add an importance mechanism to these name-defining constructs
<fantasai> [emilio agrees with TabAtkins]
Rossen_: seems like we should move on until there's a stronger use case
Resolution: Close no change, we should get a stronger use case
Allow authors to explicitly place unlayered styles in the cascade layer order
github: https://
miriam: this one is another coming from an earlier resolution
… we resolved that unlayered styles are lower pri
… jen asked about whether it'd be useful to tweak the unlayered styles priority
… there's some syntax proposals in the issue
… and I'd expect it to work at each level of layering
… are we happy with an empty layer rule syntax? Does this become too complex?
florian: I could see use cases for top/bottom, has any non-theoretical use case come up for in the middle?
miriam: yeah, you want components at the top and resets on the bottom, so you might want most of your styles between them
TabAtkins: Like florian I see the use case but I'm not sure we need to solve it right now
… we could reserve the CSS wide keywords as layer names in case we want to solve them
miriam: does that become a problem if additional wide-keywords are added?
TabAtkins: theoretically? But we haven't added many over the years
fantasai: we could also do something that isn't a keyword
… I don't have strong opinion on having to solve this now, and I'd be ok reserving the wide-keyword, like an asterisks
florian: maybe I need to re-read the minutes for when we decided to switch top/bottom, I wasn't there and it seems !important could take care of jumping to the top
miriam: main reason for that was that putting them at the bottom allows progressive enhancement
… sort of like when not all browsers had media queries you'd write the specific styles in there
… but lots of people think of layers as a way to hide their resets
florian: I guess I see it more like the later but that also doesn't give me a strong use case for having unlayered styles in the middle
… I'd be fine reserving the wide keywords though
fantasai: so there's the question of whether we add it now, if we don't we might want to just reserve the keywords
miriam: if we're not sure if it's needed I'd be ok with reserving the keywords and delaying
… since it adds a fair amount of complexity
florian: what do we need by reserving the keyword? Just making them syntactically invalid?
fantasai: yeah, if you define @layer with that keyword the whole block is in invalid
florian: is that progressively-enhanceable? If you add a layer that doesn't work and then it starts working...
fantasai: why would you type it in if it doesn't work?
florian: would it be wholly invalid or just ignored?
TabAtkins: could we bring that detail back to the thread?
Emilio: fwiw it seems simpler to make the whole block invalid at parse time
Resolution: Reserve the CSS wide-keywords (making the whole layer block invalid at parse time) for now and details TBD when we have better use cases
Need method to interpolate variable font settings
github: https://
<astearns> https://
astearns: This was raised by scott a while back along with other issues
… he works on typetura which does a lot of fancy things with responsive typography
… and he'd like to do fancier things and helpfully filed a bunch of issues
… but they didn't get a lot of attention
… so I raised them to get some attention from the group
… he wants to interpolate variable font settings that are numbers with e.g. viewport lengths
… can't use calc() because incompatible units
TabAtkins: it's perfectly fine to use calc(), you just need to divide the unit away
… unless there's something more subtle going on we should be fine on this issue
<chris> I was going to say the sam as tab
astearns: there are some other subtleties, calc() might be limiting, but let's do this on the next issue
<chris> calc(19px/1px)
<fantasai> chris, wouldn't you just write 19 at that point?
emilio: Tracking multiple units doesn't work, but dividing the same units and getting an integer possibly works already?
<chris> if you have some length and it happens to have px, you can convert it to number by dividing out the unit
Resolution: No change, should work with already-in-the-spec calc() improvements
<chris> but what I put was a handy test
Higher level CSS interpolation module
github: https://
astearns: this also might be covered in-spec but not impls
… in addition to using calc() across various types, they want to use easing functions for ~all properties
… haven't looked at it in a while, but perhaps we can use easing functions in all properties or is it more limited than that?
chris: when we added animations and before with SMIL we got some feedback from animators saying that it only worked on two values
… so this is a thing we want any time we transition, animate or interpolate
<chris> yes, done
astearns: and I don't think we have any of the easing editors on the call
… it seems they are meant to be used anywhere where a value could be set
fantasai: wdym with that?
<fantasai> https://
fantasai: they are meant to be used where an easing function is asked for
… it's a function, not a value
astearns: I believe scott's ask is for things like optical sizing to be able to use easing functions as values
<chris> seems like a reasonable ask
astearns: to be able to have more subtle transition across values
fantasai: you need a range of values for that as well
lea: if I'm reading this correctly, easing functions is just a minor piece of that issue
… there are other important issues like mixing relative units
… you need to do spacing manually in keyframes
… I didn't open this issue and scott isn't here, but I think the idea is to unify all these interpolation mechanisms
… so that the same features are available everywhere
miriam: when interpolating between breakpoints wrt media/container queries, part of the complexity is that you have to set those breakpoints and then somehow attach an animation to those breakpoints
… I've thought a bit to scrolling animations and animation timelines linked to container / media queries
… not sure if something like that would help
<argyle> https://
argyle: I use a lot of online tools that would generate things for me like shadows (^)
… what I'd like to do instead of something like this is letting CSS do this with a clamp-like function
… so that I can get an easing shadow with a natural curve
… it'd be really cool to pass curves to shadows / gradients / etc rather than a bunch of percentages
… almost anywhere where we accept multiple values we could shorten the entire stack into one or two by specifying the range and a curve
… if you're looking for use cases for stuff like this I can help
astearns: I think this is very relevant, there are lots of use cases to express stuff in terms of curves of values. not quite sure where to start though
Rossen_: where do we go from here? Is this the most appropriate issue to capture this?
astearns: birtles suggests this as an expansion to web-animations-2
<fantasai> emilio: Use cases adam mentions aren't particularly animation-like
Rossen_: shouldn't but it's where most that stuff is defined
Rossen_: sounds like enough motivation was heard. There are some overlapping efforts in the interpolation space with animations-2, and if that's not enough we need to figure out what else is needed
… is there anything else we can do with this issue?
<lea> +1 to work on it
Resolution: This is something we want to work on, exact details TBD
other pubs?
<lea> s/you need to do ?? manually in keyframes/gradient stops can automatically be evenly spaced, whereas it needs to be done manually in keyframes/
FPWD for nesting
<TabAtkins> https://
TabAtkins: We've discussed nesting a bunch of time, has matured a lot. There's the OM bits, etc. Gotta do some work on syntax
<chris> +1 to FPWD, LGTM
<lea> +1 to FPWD
TabAtkins: we have agreement that this is a good idea, I'd like to request FPWD
<astearns> +1 to FPWD
<miriam> +1
<rachelandrew> +1
Resolution: publish FPWD of nesting
<lea> This is possibly the main reason authors still use preprocessors, if I could +100 I would
<TabAtkins> Agreed, lea
Rossen_: what's the status of logical? we have min-block-size defined but not on TR
… not published since 2018
<fantasai> https://
Rossen_: it's the only thing implemented everywhere but not on a WD
fantasai: it is on TR (^)
… we should update it, there's lots of specs we should update
Rossen_: there's stuff in the ED which is not in a public WD
… we should revisit this
Rossen_: that's everything for today, let's end here
end
<fantasai> https://