14:02:19 RRSAgent has joined #css 14:02:19 logging to https://www.w3.org/2021/07/27-css-irc 14:02:21 RRSAgent, make logs Public 14:02:22 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 14:02:41 present+ 14:02:46 alisonmaher has joined #css 14:03:02 present+ 14:03:03 present+ 14:03:23 lea has joined #css 14:04:19 ScribeNick: TabAtkins 14:04:32 oriol has joined #css 14:04:41 present+ 14:04:41 present+ 14:04:46 present+ 14:05:01 present+ 14:05:09 present+ 14:05:16 present+ 14:05:18 dholbert has joined #css 14:05:20 present+ 14:05:22 present+ 14:05:24 Topic: Shared Element Transitions 14:05:26 present+ 14:05:27 present+ 14:05:43 github: https://github.com/w3c/csswg-drafts/issues/6464 14:07:03 jbroman has joined #css 14:07:54 present+ 14:07:59 una has joined #css 14:07:59 jensimmons has joined #css 14:08:09 JakeA has joined #css 14:08:10 present+ 14:08:17 present+ 14:08:26 present+ 14:08:46 JakeA: [slides] 14:08:57 JakeA: I'm helping out with this Shared Element Transitions work, along with Jeremy and Khushal 14:09:08 JakeA: Current state: when you navigate on the web, the page just changes 14:09:22 JakeA: but on apps, especially in mobile, you get these lovely transitions betweens tates 14:09:31 [slide shows various transitions, like sliding in a sidebar, swiping across panels, etc] 14:09:47 JakeA: they look nice in person, and can even be directly useful, to help communicate transitions between states so there's less context loss 14:10:04 JakeA: I asked people on twitter about this, especially if they'd like it in a SPA or MPA (multi-page app) 14:10:12 JakeA: most people were interested in it for a multi-page app! 14:10:23 [slide shows Twitter survey of SPA vs MPA, 31% to 52.9%] 14:10:25 JakeA: I see why - you can already kinda do it in a SPA, but it's impossible in an MPA 14:10:41 JakeA: Strong feeling that manys ites *become* SPAs just to get these transitions; not sure, but it feels like it. 14:10:53 s/manys ites/many sites/ 14:10:53 JakeA: And that's a problem, SPAs have a lot of issues, and they're often done badly. 14:11:08 JakeA: But even when done by experts, you lose things like HTTP streaming, gain a big JS bundle, etc. 14:11:20 JakeA: So thinking about this space 14:11:21 [slide shows timeline] 14:11:27 [2015: Chrome proposal and experiment] 14:11:35 JakeA: 2015 was an early chrome proposal, didn't go very far, and the people left for other projects 14:11:36 [2015: Chris Lord (Mozilla)'s sketch] 14:11:41 [2017: Jake's sketch] 14:11:53 [2018: Tab's sketch] 14:11:58 JakeA: 2017, I sketched an API. Each time we learned more things that might work. 14:12:00 flackr has joined #css 14:12:01 [2021: This round!] 14:12:06 eugene has joined #css 14:12:07 JakeA: 2018, Tab had his own proposal 14:12:15 JakeA: And now we're here today 14:12:27 JakeA: Not the first people to even try this out, back in '97 IE had something. 14:12:35 [1997: IE4 with navigation transitions via meta http-equiv="page-enter"] 14:12:42 JakeA: 24 years ago, you could use to do page transitions 14:13:10 JakeA: there were 22 transitions to choose from; several dupes from different directions, like "wipe left" and "wipe up" 14:13:20 [ ] 14:13:21 JakeA: also a special 23rd transition that made a random choice 14:13:37 JakeA: slightly kidding, but I think a predefined set of transitions can get us pretty far 14:13:49 JakeA: But not all the way, I got feedback from people asking for custom control 14:13:57 JakeA: If we look at some of the nicest transitions in the android docs 14:14:11 JakeA: It's animating between states in multiple ways; some things are shared between the states 14:14:18 [shows Android Contacts list, clicking on name of person shifts the name up and colors/layout changes to show a profile] 14:14:20 JakeA: This person's name in the address list moves to be the header for their profile 14:14:40 vollick has joined #css 14:14:41 [Jake's homepage with 2-line title vs 3-line title] 14:14:55 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? 14:15:11 JakeA: Every element on the two pages are different, even different tag names. 14:15:14 chris has joined #css 14:15:30 JakeA: Some elements change content, some elements (dates) don't change content but do change position. 14:15:46 JakeA: Header changes layout, it does a fade to the new larger text 14:15:54 JakeA: and header container scales its height 14:16:09 JakeA: then the rest of the page just fades content 14:16:28 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 14:16:32 present+ 14:16:36 JakeA: So didn't need to keep the old page alive 14:16:48 present+ 14:16:50 JakeA: there are some concepts we keep coming back to 14:16:52 https://github.com/WICG/shared-element-transitions 14:16:57 [slide: Change] 14:16:57 JakeA: First, there's a change 14:17:05 JakeA: Before that, we need a prepare step 14:17:08 [slide: Prepare, Change] 14:17:15 JakeA: where the outgoing page offers up parts of itself to be involved in the transition 14:17:26 JakeA: Like my blog example, offering the header, the date, the sidebar 14:17:44 [slide: Prepare, Change, Transition] 14:17:44 JakeA: Then the change happens, letting the outgoing page be cleared from memory except for the textures it's offering up 14:17:55 JakeA: Then the Transition happens, where the new page animates in 14:18:20 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 14:18:29 JakeA: Like I said, these are textures; we don't want to do layout on the old page 14:18:39 JakeA: But we also don't want the new page to get pixel readback from the old textures 14:18:55 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 14:19:06 JakeA: for cross-origin transitions that's a potential concern 14:19:10 [slide: cross-origin transitions] 14:19:22 JakeA: The old page could offer up bad stuff 14:19:42 JakeA: A bad page could transition into a news page, offering up its "header" and boom, it's the q-anon logo 14:19:57 JakeA: So cross-origin transitions either need to be heavily restricted 14:20:06 JakeA: Or need a two-way handshake to agree on which textures to share 14:20:11 [slide: single-page app transitions] 14:20:17 JakeA: There's also single-page app transitions 14:20:24 JakeA: Not as manya uthors are interested 14:20:29 khushal has joined #css 14:20:30 JakeA: because they're actually quite hard to do today 14:20:37 s/manya uthors/many authors/ 14:20:52 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 14:21:03 present+ 14:21:07 JakeA: Need to control for scroll position, how it can mess up CSS mid-transition, etc. 14:21:16 JakeA: Twitter says they don't do transitions precisely for these reasons 14:21:33 JakeA: So we were thinking about this and realized this should work on the page transitions model just as well 14:21:46 [slide: prepare, change, transition] 14:21:51 JakeA: You're still doing a prepare phase to record bits of the old state, then you transition into the new state 14:22:00 JakeA: We already ahve a sketch of the SPA model behind a flag in Canary 14:22:07 JakeA: Here's an example of the Preact website 14:22:08 [slide: preact website SPA] 14:22:29 JakeA: Author of the site says it's "a mess", but it has a router for the overall site transition as many SPAs do 14:22:47 JakeA: But even tho I didn't understand much, I could easily poke in and add the transitions API, and it all just works 14:22:57 JakeA: BAck button reverses transitions, it's all just very little code 14:22:59 [slide: preact website with subsections fading in and out in the content panel] 14:23:14 JakeA: In spirit, our current design is very similar to the old IE version, with a list of predefined transitions 14:23:27 JakeA: New bit is this "shared elements" notion, like the heading and sidebar in the guide. 14:23:41 JakeA: In this example I'm using this to keep them in position and only change the content by sliding it in 14:23:56 q? 14:23:59 q+ 14:24:04 [slide: Interesting Problems] 14:24:10 JakeA: While we need the bare-bones for EWM reasons, I think there's definitely a high-level version that solves 80% of cases 14:24:13 JakeA: Some problems. 14:24:17 [slide: cross-fading] 14:24:21 JakeA: First is cross-fading. Transitions have a lot. 14:24:25 JakeA: Hard to do in CSS rightnow 14:24:35 JakeA: Especially between elements with transparency. 14:24:47 JakeA: Can use explicit opacity on the two states 14:24:47 [slide with .thing1 { opacity: 1 } .thing2 { opacity: 0; } ] 14:25:02 JakeA: here's a slide where the two are identical save for a few extra words on the second 14:25:18 [slide: cross-fade shows image, which doesn't change, fades to 50% hafway in the transition] 14:25:19 JakeA: Midway thru the transition the shared pixels fade a bit, ideally we could fix this 14:25:27 JakeA: CSS has a cross-fade(), which does the right thing 14:25:28 This is because the cross-fade eeds to be done in linear-light 14:25:39 (That's not the only reason) 14:25:41 s/eeds/needs/ 14:25:42 so that -0.5 + 0.5 = 1.0 :) 14:25:51 cross-fade() also blends sizes tho 14:25:52 s/-0.5/0.5 14:26:00 JakeA: Which isn't always what we want 14:26:02 [slide: background-image: cross-fade(...); ] 14:26:20 [slide: Not quite elements, not quite images] 14:26:27 JakeA: We're not dealing with elements *as such*; images might b eokay since we've just got textures left over 14:26:27 (interested to know the other reasons) 14:26:42 s/b eokay/be okay/ 14:27:08 JakeA: but not all an image - Some information like transforms we might want to carry over so it can animate properly 14:27:09 [slide: timings and deadlines] 14:27:16 JakeA: Another thing to think about is timings and deadlines 14:27:32 JakeA: Right now when you click to a new page, the browser shows the new page when it wants, when the data comes in 14:27:39 [slide: iWouldLIkeToDoAPageTransition(); ] 14:27:47 JakeA: But if the incoming page wants to control the transition, it should be able to signal for it 14:27:51 JakeA: But how long can we wait? 14:28:08 [slide: iWouldLikeToDoAPageTransition(); await massiveImageLoad; nowDoTHePageTransition(); ] 14:28:11 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? 14:28:17 JakeA: We like progressive rendering 14:28:29 JakeA: Do we want to allow pages to delay until a 5MB image loads? 14:28:39 JakeA: They can do it today, kinda 14:28:47 [slide: Thoughts? Questions?] 14:28:51 JakeA: But maybe if they, say, don't do it in 5s we just do a page swap 14:28:58 JakeA: So, questions? 14:29:17 Jake Archibald 17:28 https://github.com/WICG/shared-element-transitions - repo (API design in flux) https://preact-with-nav-transitions.netlify.app/ - preact site demo 14:29:38 https://www.irccloud.com/pastebin/at0XnzDj/ 14:29:45 present+ 14:29:50 https://github.com/WICG/shared-element-transitions - repo (API design in flux) 14:29:50 https://preact-with-nav-transitions.netlify.app/ - preact site demo 14:29:57 ack florian 14:30:09 florian: Intriguing! Overall makes sense at a high level. 14:30:28 florian: Curious how much ends up being declarative vs JS, how they intertwine, I'm sure y'all are thinking of this 14:30:45 florian: There was also something between IE4 and modern stuff. I believe Opera experiemented around 2010 14:31:13 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 14:31:20 florian: tied into gestures as well 14:31:39 florian: Wondering if there has been any thought on these lines, including tied in with the "shared elements" part 14:31:55 q? 14:31:59 q+ 14:32:08 florian: This notion of arranging bits of space, I thought it was interesting 14:32:14 florian: Doesn't seem obvious that it doesn't fit 14:32:24 JakeA: Hard to talk about binary declarative vs imperative 14:32:37 JakeA: For some peopel it just means "JS" vs "CSS", but Web Anim - which is it? 14:32:55 JakeA: We almost certainly will end up with something declarative to some extent 14:33:03 GameMaker has joined #css 14:33:08 present+ 14:33:16 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 14:33:40 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... 14:33:53 JakeA: I anticipate the destination being done in JS at least 14:34:04 JakeA: And maybe there's a smaller subset that can be done in pure CSS with simple behaviors 14:34:29 present+ 14:34:36 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 14:34:44 JakeA: In the JS API I presume it'll be similar. 14:35:01 JakeA: There needs to be a way to give more information - like, by default it maybe just translates, cross-fades, and scales 14:35:12 JakeA: But scaling isn't always what you want, as I showed in some examples 14:35:57 chris: if you've got two things transitioning opacity... 14:36:17 chris: You need something where .5 + .5 = 1. That needs linear light; images aren't linear painted, which is why there's lightening. 14:36:26 scribe+ 14:36:30 TabAtkins: linear-light was one problem 14:36:50 agreed 14:36:53 TabAtkins: Other problem is that halfway through, two 50% things laid on top of each other means together they are only 75% opaque 14:37:04 flackr: Gaming has opacity saturation buffers to solve this 14:37:13 khushal: Yeah we foudn that, there's a blend mode that can do that 14:37:26 khushal: I found a webkit bug asking to expose this to mix-blend-mode 14:37:31 ack emilio 14:37:47 emilio: so the idea is that the destination page can observe stuff about the transition, like position of old elements 14:37:50 https://bugs.webkit.org/show_bug.cgi?id=142416 is a bug which talked about the blend mode that would work for this. 14:38:05 emilio: That seems like in conflict with the UA being able to control the transition 14:38:09 q+ 14:38:16 q+ 14:38:21 JakeA: we hope within the API to catch spots where, like, if an error is thrown it doesn't deadlock the transition 14:38:42 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 14:38:58 JakeA: Question of how much we want to prevent people - they can already delay their own page arbitrarily. 14:39:13 JakeA: Worry about damaging legit use-cases to guard against some peopel getting it wrong 14:39:14 q+ later 14:39:18 q- 14:39:26 emilio: Main thing I'm concerned about is an animation working on a good computer, but breaking on a crappy phone 14:39:44 JakeA: Right, so think if the transition isn't ready within 3s we just bail, or something like that 14:39:56 JakeA: Like doing font-rendering intervention 14:40:26 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. 14:40:50 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. 14:41:03 JakeA: I see you're looking at the GH page for the API; that's still in flux 14:41:13 JakeA: We're def looking at ways to mitigate these problems 14:41:29 JakeA: Issue on GH right now looking at moving to a JS API similar to WebLocks 14:42:08 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. 14:42:14 ack khushal 14:42:38 khushal: design thing i'm thinking about, which page controls the transition. reasons for that to be diff between same-origin vs cross-origin 14:42:53 khushal: Incoming page controlling the transition is good bc it has info from both sides, and can make better decisions 14:43:18 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 14:43:28 khushal: This requires different API shapes, and it's causing some API divergence 14:43:40 JakeA: This is something I ran into for the CSS-only version 14:44:00 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 14:44:08 JakeA: It's hard in CSS to talk about an element that isn't there 14:44:30 q+ 14:44:38 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 14:44:47 q+ 14:44:53 astearns: You mentioned pixel access - I assume incoming page has no pixel access at all 14:44:55 JakeA: correct 14:44:58 q+ 14:45:10 q? 14:45:18 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 14:45:29 JakeA: But no pixel access 14:45:40 JakeA: Hope we can one day get to a state where we can read the pixels on a page 14:45:49 q+ 14:45:57 JakeA: We have origin isolation right now, maybe some even stricter version could some day allow this 14:46:53 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 14:47:06 JakeA: two angles there - don't want Page A to find info about Page B they didn't want to share 14:47:12 ack astearns 14:47:16 JakeA: In some cases the number of chat messages can leak that 14:47:28 JakeA: But there's also Page A and B *wanting* to share info, but for privacy we don't want to allow them 14:47:33 JakeA: Not sure where the line is right now 14:47:44 zakim, close queue 14:47:44 ok, astearns, the speaker queue is closed 14:47:45 JakeA: Might be that cross-origin is just the IE model - a list and the whole view moves 14:47:48 smfr has joined #css 14:47:53 q- 14:48:04 astearns: you talked about having a high-level declarative variant with less features 14:48:25 astearns: I hope if we get there, the high-level thing can be hooked by the low-level, so you can intervene when necessary 14:48:27 +1 14:48:51 JakeA: Yeah, I think CSS shorthands model is something like what we want to go for 14:49:07 JakeA: Can set up a "sliding" animation, and it can specify a WebAnim-like set of keyframes 14:49:08 present+ 14:49:27 JakeA: And maybe we just wrap that up in "slide-left" keyword, but with full control to do your own 14:49:35 ack fantasai 14:49:35 fantasai, you wanted to mention incremental rendering 14:49:48 fantasai: One, incremental rendering, if you're on a slow connection you want the partial page to show up early 14:50:00 fantasai: dunno how that's considered right now, just want to make sure it's not forgotten 14:50:19 prefers-reduced-motion would turn all of this off, presumably 14:50:29 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 14:50:41 fantasai: Big point I remember there was that cross-origin ones shoudln't leak info 14:51:00 fantasai: Another idea was sharing a timer between the two, so outgoing and incoming pages could put things on the same timeline 14:51:13 fantasai: Coudln't necessarily coordinate between elements, but could at least ensure timing matched up 14:51:28 JakeA: For incremental loading, def one of the fundamentals I want to keep. 14:51:35 JakeA: Def a tension between that and page transitions 14:51:44 q- 14:51:47 JakeA: Would be nice to have a way to say "don't transition until X element is around" 14:51:57 JakeA: Very hard to do right now, tricky with a Mutation Observer 14:52:11 JakeA: Might be a waitForElement() API to let you delay as little as possible 14:52:38 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 14:52:50 JakeA: Nothing concrete there yet, but it's on our minds 14:52:58 JakeA: I didn't know about the transitions discussion 14:53:01 JakeA: I'll try to find notes 14:53:16 JakeA: In chat Alan asked about prefers-reduced-motion 14:53:22 JakeA: Yeah we'd just ignore the transition in that case 14:53:30 q+ 14:53:42 JakeA: Re: leaking cross-origin, absolutely a concern, need to lock down properly 14:53:55 JakeA: re: timeline sharing, that's similar to my previous 2017 idea 14:54:04 JakeA: That version required both pages to be alive at the same time 14:54:11 JakeA: which is an issue for low-memory devices 14:54:25 JakeA: Thought right now is one side controls the transition; the other side just offers things to be transitioned 14:54:43 khushal: interesting to think about whether incoming page *has* contextual info to control the transition or not 14:55:23 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. 14:55:31 khushal: Also, re: same vs cross-origin 14:55:45 khushal: In same-origin when incoming can control, we also let it control when the transition states 14:55:58 khushal: and it gets all the info about the outgoing page, so it can do smart things 14:56:14 present+ 14:56:19 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 14:56:28 ack eugene 14:56:44 eugene: Reffing on khushal's comments, if you have cross-fade capabilities, the omnibox can do its own thing controlled by the UA 14:57:01 eugene: we've also got scroll-to-text capability now 14:57:20 eugene: and ideally whe nyou're referring to a shared element, hopefully we have a consistent way to refer to those elements 14:57:37 s/Reffing/Riffing/ 14:57:43 s/whe nyou/when you/ 14:57:49 eugene: another comment, declarative vs imperative. imperative is basically marking up a single transition, I think it falls down when you want multiple things simultaneously 14:58:00 s/imperative is/declarative is/ 14:58:08 eugene: So it's important to ahve the models build on each other 14:58:16 eugene: Big call for extensibility, building more on top of this 14:58:42 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 14:59:00 JakeA: re: scroll to text, I think you can use a css selector to id the element 14:59:12 JakeA: that works okay for sscroll-to-text because the lifetime is relatively short 14:59:22 JakeA: And if the highlighting doesn't work, it's not a huge loss 14:59:29 JakeA: Coudl be worse on transitions 14:59:55 JakeA: concern I have is you're navigating around a site, and mid-article the site redeploys and the class names have changed 15:00:10 JakeA: So model we're using right now isn't tags or selectors, it's literally just a bunch of named element references 15:00:16 Francis_Storr has joined #css 15:00:27 JakeA: {"heading": someDOMEl} 15:00:33 I think scroll-to-text uses a snippets of text rather than CSS class names to avoid this 15:00:46 JakeA: Might need a way to bail on transitions so if two versions of a site are totally incompatible they cna figure it out 15:01:20 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 15:01:31 It does, yes. 15:01:42 ack flackr 15:01:49 flackr: I assume that BF nav, we want to use the transition that you saw when you came in 15:01:57 flackr: Not sure how it would work with the current API 15:02:14 flackr: But should be some way of memorizing the transition so we can reverse it if we go back 15:02:20 flackr: Is that something we can do? 15:02:30 JakeA: Yes, and the more autoamtic we can do the better; people don't often test that 15:02:39 JakeA: Maybe we only do it if the page is in BFCache 15:02:53 JakeA: gets more complicated if you're reloading the old page as well 15:03:12 JeremyRoman: This is a very big rathole, but interesting 15:03:27 JakeA: I think limiting it to BFCache and only +1/-1 transitions is a good start 15:03:49 astearns: Assuming you'd like more feedback in the WICG repo? 15:03:56 JakeA: Yes, that's the right place for it 15:04:11 astearns: And we can do CSS issues when you come up with a declarative CSS version of this 15:04:17 JakeA: Absolutely. Thanks! 15:04:23 +1; thanks CSSWG for your time 15:04:37 thanks, all! 15:04:38 astearns: I think it'll be great to bring the web platform back up to IE4 standards. 15:04:46
15:08:48 https://github.com/WICG/app-history/ 15:14:05 For the minutes: https://github.com/WICG/app-history/ provides a "navigate" event which provides a central place to hear about navigations, kinda like I was able to use on the preact site (due to its router). This means if you want to hear about navigations, you don't need to listen for all link clicks, all form submissions etc etc 15:14:11 dholbert has joined #css 15:17:26 topic: Pause media playback in iframes hidden by content-visibility:hidden 15:17:33 github: https://github.com/w3c/csswg-drafts/issues/6468 15:17:36 scribenick: fantasai 15:17:51 Thanks again for inviting me! 15:17:55 chrishtr: Web developer raised use case of wanting to automatically pause videos, media 15:18:12 chrishtr: in situation where media happens to be in iframe, page can't really access it, because usually cross-origin 15:18:20 chrishtr: atm can only do that by coordinating with each provider of video 15:18:29 chrishtr: Perhaps platform can make that possible 15:18:35 chrishtr: Suggestion was content-visibility to control that 15:18:50 chrishtr: content-visibility is meant as a perf tool, and this is about reducing unnecessary use of CPU 15:18:56 chrishtr: so ... 15:19:10 chrishtr: so seems that media under content-visibility be automatically paused 15:19:31 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 15:19:41 chrishtr: e.g. off screen or detached from the DOM 15:19:51 chrishtr: But since content-visibility is new, probably not compat worry 15:20:03 TabAtkins: I'm surprised at how many things still allow video to play 15:20:09 TabAtkins: This seems like a good idea 15:20:09 q+ 15:20:10 enick_101 has joined #css 15:20:22 q+ 15:20:30 astearns: I'm not sure I'd look for content-visibility as a way to make cross-origin video stop playing 15:20:37 florian: In that direction not obvious 15:20:48 florian: but in other direction, would you expect a video with content-visibility to play? 15:21:00 flackr: display:none might have similar effect 15:21:03 flackr: might also unload frame... 15:21:10 ack emilio 15:21:11 Rossen_: Display:none is a big hammer 15:21:13 It does unload the frame 15:21:18 emilio: Idea is to also do this for ?? stuff? 15:21:24 emilio: ... 15:21:32 s/??/same-origin/ 15:21:49 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 15:21:54 emilio: Doesn't pausing media change styles? 15:21:59 emilio: causes :pause to apply ... 15:22:06 emilio: maybe not a huge deal if under subtree, but also weird 15:22:18 emilio: overall, I think removing video from DOM should pause 15:22:26 emilio: seems weird that content-visibility is the only thing that does this 15:22:31 chrishtr: Yes, it would be all media 15:22:43 chrishtr: issue says iframes, but would also apply to same-origin video within the document 15:22:56 chrishtr: wrt relative timing, seems similar to detaching video after user presses pause button 15:22:58 q+ 15:23:05 q 15:23:05 chrishtr: same thing, rendered as visibible under content-visibility 15:23:11 chrishtr: thrid point was about how styling changes when it's paused 15:23:32 chrishtr: I think yes, those styles would conceptually apply, just like all boxes within content-visibility subtree 15:23:44 chrishtr: but UA is allowed to not render within that, for perf reasons 15:23:53 emilio: Does content-visibility currently change styles under its sub-tree? 15:24:00 emilio: I guess it pauses animations, which is something 15:24:11 flackr: It pauses animations in a way that is not very developer-visibible 15:24:17 flackr: the timer keeps going 15:24:30 flackr: For this video, could maybe not change state to pause, but would not continue playing 15:24:39 Rossen_: Is that how we have it specced? 15:24:52 Rossen_: content-visibility is currently defined as behaving like 'display: none' on contents 15:25:02 Rossen_: [quotes spec] 15:25:14