13:00:41 RRSAgent has joined #components 13:00:41 logging to https://www.w3.org/2019/04/26-components-irc 13:01:19 Zakim has joined #components 13:01:49 pmdartus has joined #components 13:02:41 DanClark has joined #components 13:02:56 margaree has joined #components 13:04:26 JanMiksovsky has joined #components 13:04:56 Ruphin has joined #components 13:05:17 rrsagent, set logs world-visible 13:05:34 brandon has joined #components 13:05:34 Meeting: Web Components 13:05:40 Chair: annevk 13:05:50 Agenda: https://github.com/w3c/webcomponents/issues/802 13:06:46 Stacey has joined #components 13:12:05 bkardell_ has joined #components 13:13:23 sfdc_iurie has joined #components 13:15:01 slightlyoff_ has joined #components 13:18:26 caridy has joined #components 13:20:49 who is speaking now? 13:21:09 justin has joined #components 13:21:32 vmpstr has joined #components 13:21:42 q? 13:21:44 diervo has joined #components 13:22:30 scribe: Ruphin 13:23:03 Moving to ::theme topic 13:24:05 tomalec has joined #components 13:24:12 Justin: There current state is that ::part has some current agreement 13:24:29 Justin: The current implementation seems useful, it reduces the need for custom css variables 13:24:47 Justin: The problem is mostly with deeply nested items and styling subtrees 13:25:20 Justin: The question is if parts should be exposed higher up the tree implicitly 13:26:39 Justin: The problem with that is name collision, if you use theme or part on a node there is no way to differentiate between children 13:26:53 Anne: It looks like we don't have a concrete proposal and we're just in a brainstorming stage 13:27:39 Anne: It seems like we have a namespacing problem, similar to what we tackled with custom registries 13:28:29 Justin: There is a spectrum of use cases. One extreme is a world where everything in an app is constructed by the same vendor and they have full control so they just want access 13:28:37 q? 13:29:07 Justin: The other end is an application that uses many external components and there needs to be some form of communication/coordination 13:29:08 pmdartus has joined #components 13:30:16 Brendan: Salesforce certainly needs some form of namespacing to prevent things from external parties leaking through the application 13:30:44 rniwa_ has joined #components 13:31:43 Rniwa: It seems like we have two usecases: One where you want to globally style an entire app, like giving the whole app a 'dark' theme. The other usecase is styling all instances of a certain element, like making all the buttons blue 13:32:05 Rniwa: It looks like we need some form of namespacing 13:32:23 Justin: We have the same problem with custom variables, and the way people solve that is with custom prefixes 13:33:28 Alex: It's worth highlighting that element authors explicitly choose to expose things with part and theme, so unlike /deep/ it's less vulnerable 13:34:09 Anne: Parts automatically inheriting up will make it more like /deep/ where things all start leaking globally 13:35:44 q+ 13:35:45 Diego: Expanding on what Alex mentioned, it's important for authors to communicate what parts/themes they expose 13:35:54 q? 13:36:13 Diego: But it's easier to explain what themes are available, and harder to document all the parts that are deeply available 13:36:21 ack justin 13:36:41 Justin: I suspect that most companies will use Theme over Part, because the part fowarding is cumbersome 13:37:22 Justin: We have a situation where people ask for things, but maybe that's because people are used to being able to do a certain thing 13:37:50 Justin: Perhaps it's just because they are not thinking in a model of encapsulation 13:39:32 Rniwa: One thing with themes is that it's hard to make things global, because for some elements it may make sense to theme for example the background, and for others it does not 13:40:20 Rniwa: There is a question about how specificity works with theme and inherited styles 13:41:04 one challenge with you specifying everything that you need fixed and letting other things through is that as new properties are added you wouldn't have set them - could that create issues? 13:41:05 Anne: It's hard to design a system around ::part that allows authors to do what they want, because you may expose too many things you don't want 13:41:25 Anne: You would need some kind of blacklist to block styling certain properties 13:41:55 Rniwa: We're already in a situation where some elements are styled through ::theme and others with CSS variables 13:42:13 Anne: We don't yet have experience with what developers will do with ::part 13:43:29 caridy has joined #components 13:43:40 Justin: @apply had some mechanism to keep some properties internally defined by authors 13:44:36 Brandon: We have parts that can absolutely not be overridden, like things related to layout 13:44:38 rniwa: having to use completely different mechanisms as soon as you wanted to restrict the list of properties to apply doesn't strike me as a good design 13:45:14 Brandon: We prefer to keep things conservative in what we allow others to style 13:45:39 Justin: It seems like we're having the same kind of topic around part and theme, with whitelisting and blacklisting what can and cannot be styles 13:46:08 Rniwa: We need more concrete usecases so we can use those to shape the API 13:46:19 Justin: We have those from @apply usage 13:47:08 Justin: @apply gave people to apply a style to a bunch of parts, and people used it to style a bunch of elements like applying a certain theme to all paper elements 13:47:38 Anne: It looks like Rniwa is referring more to an abstract list of things that developers would like to do 13:48:20 Rniwa: We need this list from developers, and then we can create an API and determine if our proposal covers all the requirements in the list 13:50:06 Diego: There are many different levels of what kind of exposure we need, down from allowing applying a single style to one deeply nested elements, up to being able to style everything everywhere 13:50:40 We could try to commit ourselves to finding out at what level our users need to have this exposure 13:50:56 Diego: We could try to commit ourselves to finding out at what level our users need to have this exposure 13:51:20 Anne: It would be great to have that information well before TPAC so we can discuss 13:51:39 Rniwa: It looks like the Polymer team also should have information on what customers use with @apply 13:52:00 Rniwa: It would be nice if there was some overview on the different uses from those users 13:52:05 muan has joined #components 13:52:28 Justin: The usage for @apply was mostly closely mappable to ::the,e 13:52:30 Justin: The usage for @apply was mostly closely mappable to ::theme 13:53:19 Rniwa: @apply is more powerful than ::theme because you can choose to apply different things 13:53:21 @apply wasn't perfect though -- you needed to expose different @apply entrypoints for :hover, :focus, :disabled, etc. 13:53:49 @anne: We don't know all the requirements, so maybe we should move on to the next topic> 13:54:41 Alex: What other evidence do we need? We have a lot of information from @apply in what users are doing. Is the information from Salesforce going to be critical for the decision making process? How much additional data do we need 13:54:50 tomalec_ has joined #components 13:55:10 Justin: It would be really nice to have tabatkins here, because he is involved with this spec 13:55:24 is tab able to join remotely 13:55:42 Anne: We are just missing a concrete enough proposal to get to any kind of concensus here 13:56:07 Justin: We did have a concrete proposal 13:56:27 Anne: That proposal had some issues where ::theme and ::part had some overlap, and there is no new concrete proposal that deals with those issues 13:57:01 Justin: But the original requirements from CSS shadow parts are unchanged, so we should have a list of requirements at least 13:57:22 Anne: But as long as we don't have a concrete proposal it's hard to really commit to anything right now 13:57:28 q+ 13:57:44 Anne: The main problem was sharing namespace with ::part 13:58:20 Justin: Maybe we can get a conclusion that the namespacing problem applies to both theme and part and we can discuss what we want to do that now? 13:58:48 Justin: I can commit to getting a concrete proposal here 13:59:01 Desire2Learn is in a different spot than Salesforce - we have full control over the all components and currently prefix all components and css variables with "d2l-" 13:59:09 pmdartus has joined #components 13:59:30 Justin: From our customers we know that the major blockers to using shadowDOM are theming and SSR, so it would be nice to have progress on these topics today 13:59:47 Rniwa: Everything is too abstract, so it's hard to judge what exactly we are talking about 13:59:58 q? 14:00:40 Tess: My recollection of the relevant CSS meeting was that there was consensus on the feature, and the usecases brought up at the time seemed to be addressed by css variables 14:01:29 Ruphin: it looks like we're having an issue here with ::theme; it'd make sense to decide on a desired outcome for this discussion, what's the goal? Do we need more use cases, is that the blocker? Is the blocker the lack of concrete proposal? 14:01:32 rniwa_ has joined #components 14:01:55 Rniwa: The point of this meeting is to be determine what we need to move on 14:02:16 Rniwa: It looks like there is more feature need over CSS variables from the user presentations 14:02:56 Rniwa: So it looks like we need a clear documentation on what the requirements are that we do not currently address, and _then_ we can shape a new proposal that addresses these requirements and get concensus on that 14:03:24 Rniwa: We need documentation on exactly what the current gap is that is still missing in styling capabilities 14:04:11 Rniwa: For any feature we suggest now it's hard to say if it's necessary. Perhaps the namespacing problem can just be solved with prefixes for example 14:04:25 Rniwa: More clarity on the requirements would help us determine this 14:05:17 Diego: Just to be sure, we can commit on testing certain proposals, but it would be nice to have some kind of proposal that we can test on our users 14:05:27 * there's nothing to change except insofar as make something exist to evaluate :) 14:05:44 Justin: The problem with that is there is no current ::theme to test against, because theme is currently not in any spec 14:06:54 Anne: Ideally we get a list of concrete usecases/requirements from Salesforce, and not necessarily a test-implementation 14:07:41 Justin: It's somewhat difficult for framework vendors, because we currently offer some capabilities for users, but it's hard to hunt down how our users are using those features currently, but it's something we can work on 14:07:58 Anne: Looks like we can move to the next topic 14:08:26 scribe: Travis 14:08:57 Topic: Asynchronous UI updates / DOM update batching 14:09:16 https://github.com/WICG/display-locking 14:09:28 vmpstr: Will be talking about display locking to give rendering control of rendering engine 14:09:50 .. developers sometimes have very little control over rendering 14:10:05 .. New prop on HTML Element. "displayLock" with 3 functions. 14:10:43 .. "acquire" puts an element in locked state. Clears it's painted output. Doesn't process any updates to its subtree. Takes optional size as fallback. 14:11:02 .. Then its' OK to modify the subtree and no style/layout updates. 14:11:17 .. "update" browser processes the lifecycle phases in "cooperative manner" 14:11:31 .. so it can take multiple frames to complete. Browser should yield if possible. 14:11:49 .. when update is done, script may read layout properties and the operations should be cheap. 14:12:02 "commit" - unlocks the element. 14:12:15 .. anything left is synchronously processed. 14:12:23 .. back to "acquire" 14:12:40 .. takes params: size [width, height] 14:12:59 .. 'auto' layout once, then lock. (value of size) 14:13:30 .. 'timeout': mili. Enables auto-unlock, cause devs can mess this up. 14:13:39 .. can take value of Infinity.. :-) 14:13:54 .. 'activatable' enables find-on-page, etc. 14:14:01 .. The implementation details. 14:14:12 .. uses 'contain: size" like layout. 14:14:50 .. can skip subtree style/layout. skips paint/raster. ignores hit testing. 14:15:19 .. 'activatable: true' adds Find-on-page, anchor links, scrollIntoView 14:15:36 .. "update" call is allowed to take multiple frames. I think this was said before. 14:15:55 .. To avoid "leaks" the element must have containment to avoid side-effects. 14:15:58 .. That's it for me! 14:16:02 q+ 14:16:09 q- 14:16:11 .. Looking for feedback on devs and implelmenters. 14:16:22 q+ 14:16:43 justin: Suprrised by pixel clearing. This seems to eliminate primary use case! 14:16:50 .. Like react's update mechanism. 14:17:13 vmpstr: We found there was lots of problems with 'stayed' pixels, than it solved. 14:17:28 q+ 14:17:34 .. selection frozen. visual didn't match DOM. animated GIF, blinking cursors, etc. 14:17:48 .. hit testing as well. Hard to not to react to that... 14:18:04 justin: Main case is to enable large update to DOM, but spread out async... 14:18:20 vmpstr: Use case we are considering is pre-rendering. Slide can be prepared in advance. 14:18:38 .. tab UI. Virtual scrollers. More items added to the DOM and have them be searchable. 14:18:52 justin: Hmm. So no longer intended to address concurrent react case? 14:19:07 q+ to ask how it enables more elements in the node tree 14:19:20 vmpstr: For React case, we're still thinking it should be possible to create simbling node with zero size, then remove existing sibling and show the other (element swap). 14:19:30 .. yes, it does eliminate the clean layout. Work has to be done again. 14:19:44 q+ to are al the scenarios now based on locking a subtree that is not yet connected? 14:19:47 justin: Any chance of locking pixels that doesn't have pixels. Ex: could blur... 14:19:57 ack justin 14:20:16 vmpstr: That's the question, can we do it without copying the DOM. One way to preserve old pixels is to keep a copy of the DOM and use that to preserve painted output. 14:20:25 .. we think that's too expensive. 14:20:33 ack Ruphin 14:20:50 Ruphin: Another problem. When you copy the DOM, you lose your selection state, etc. Has same issues. 14:20:59 vmpstr: That's what the proposal is as it stands. 14:21:00 ack rniwa_ 14:21:04 rniwa_: Stepping back. 14:21:08 .. what's it trying to solve? 14:21:15 q+ 14:21:41 vmpstr: Trying to give the rendering control to the DEv. Case of text editor, can prevent offscreen content from being style/layied out, but searchable. 14:21:54 rniwa_: display none? 14:22:00 q+ 14:22:03 vmpstr: That's not serachable with Find-on-page. 14:22:24 .. (explanation...?) 14:22:43 rniwa_: visibility: collapse? 14:22:52 .. that has entire style info, and is jsut as fast? 14:23:01 vmpstr: Not sure what that is (visibiliity: collapse) 14:23:15 BoCupp: I think collapse is not enqueued by rendering engine? 14:23:24 .. to layout/paint. 14:23:48 .. Use cases are for subtrees that are yet to be connected. So you can do some work and have the tree "blink into existance". 14:24:08 vmpstr: Want to lock something connected to tree and have it not do layout. 14:24:10 caridy has joined #components 14:24:21 .. should be quick because style/layout will be computed. 14:24:52 BoCupp: If you ahve display none, then switch to display block... the work to do this might take a lot of time. For a complex subtree can you prepare it in advance. 14:25:07 vmpstr: Collapsed thread in an email. If you expand it, this could cause jank. 14:25:18 annevk: Wouldn't it potentially require shifting other content around? 14:25:26 BoCupp: That's why contains is a requirement. 14:26:02 .. Also, size attribute. Point is to prepare content and put it into the expected size. 14:26:34 .. It's not depending on layout, you know it in advance. You already have an area reserved. 14:26:54 vmpstr: The way the update works... 14:27:25 .. It goes into subtree of locked element, during layout the info available to subtree is as correct as we can make it (respecting styleing info of element)... 14:27:42 .. if width is there, height is dependent... store the locked state after update is processed. 14:27:48 .. possibility that more layout will be needed. 14:28:01 annevk: Still don't get the expand an email case. 14:28:11 .. you need to replace part of the view that is to be replaced. 14:28:23 vmpstr: Idea: you'd insert the element (locked). 14:28:39 .. you pass in the space you think it will take. 14:28:44 hey all, flackr is on the queue? 14:28:52 annevk: When you commit, there's reflow for ht element around it. 14:29:00 vmpstr: Subtree will be as clean as it could be... 14:29:07 annevk: It still might be expensive. 14:29:20 pmdartus has joined #components 14:29:20 vmpstr: Alternative display none, then flip 14:29:24 q? 14:29:33 ack annevk 14:29:33 annevk, you wanted to ask how it enables more elements in the node tree 14:29:42 flackr: I think you can get some of this with vis: hidden and contain: size. 14:29:51 rniwa has joined #components 14:29:54 q? 14:30:01 .. should allow lazy layout. Only think you don't get is "when the element is done laying out". 14:30:08 .. but I think it gives all the other benefits. 14:30:16 vmpstr: Doesn't give cooperative layout. 14:30:28 flackr: Shoudl be able to lazily cooperatively layout. 14:30:36 vmpstr: REquires size to be specified? 14:30:45 q+ 14:30:46 flackr: Yes, and you do that until the layout is done. 14:31:12 BoCupp: Do you have scenarios for when the author needs specific control for when the subtree should... 14:31:15 q? 14:31:22 ack BoCupp 14:31:22 BoCupp, you wanted to are al the scenarios now based on locking a subtree that is not yet connected? 14:31:23 flackr: Problem is when you flip, browser blocks on when layout is complete. 14:31:33 ack flackr 14:31:37 .. Idea is that dev gets a signal when the flip is about to happen... 14:31:40 q+ 14:31:44 ack Ruphin 14:31:56 Ruphin: Now, if you acquire, you paint white pixels? 14:32:00 vmpstr: It's transparent 14:32:14 ack rniwa 14:32:15 Ruphin: It paints transparent.. you see what's behind it? 14:32:31 rniwa: Seems it assumes a lot of how browser works. 14:32:41 .. cooperative layout is not a think in Webkit. 14:32:53 vmpstr: Yes, this is the spec for that. 14:33:05 rniwa: Seems really immense. 14:33:19 slightlyoff: You pay nothing for not doing this... 14:33:35 .. you're not forced to do the cooopeartive layout. You loose nothing. 14:33:46 rniwa: If you don't do it, then what's the point? 14:33:58 slightlyoff: Your implementation is just slower. 14:34:13 rniwa: Don't see the need for this feature? 14:34:22 slightlyoff: Familiar with React suspense work? 14:34:30 rniwa: Yes, but not convinced... 14:34:56 rniwa: They may be working around things, but not with good reason. 14:35:10 .. if this was an issue in our browser, we would fix it by speeding up layout. 14:35:21 .. doesn't strike me as an API we want to support. 14:35:54 Ruphin: This API allows DEvs to signal to browser where to optimize. If browsers want to make things faster, they can use this to improve perf. 14:36:10 annevk: No, it comes with requirements... certain aspects are expected to be fast. 14:36:35 Ruphin: There's no requirement (guarantee). App could be running on generally slow hardware. 14:36:47 .. You can never get a guarantee 14:37:04 slightlyoff: Devs have no way to know today that the layout is clean, and wont' be invalidated by the next line. 14:37:13 .. we don't have a locked time to know when readback is safe. 14:37:28 rniwa: I think CSS containment is working, then style calc can be fast... 14:37:52 .. reason it's so expensive... without containment, there's inter-connectedness that makes perf slow. 14:38:00 .. still don't see why we want to do this. 14:38:02 q? 14:38:21 annevk: Point of order--transition to other proposals? 14:38:35 q- 14:39:13 <_caridy> _caridy has joined #components 14:39:54 justin: We're doing async rendering in our library. 14:40:08 .. we want to respond to property/attribute changes to cause a layout/render. 14:40:20 .. the algorithm we use does a syncrouns render. 14:40:32 .. so everything we do enqueues a microtask to do the render. 14:40:46 .. so now we hang a promise off to let it know when rendering is complete. 14:41:05 .. From multiple levels, each one puts in its microtask... 14:41:18 .. Children get enqueued one after another... 14:41:30 .. we don't have a single at the top of the tree (to know when everything's done). 14:41:38 .. API is nice--gives us batching. 14:41:51 .. haven't seen too many issues where devs needed to block layout. 14:42:03 .. seems like this + React's concurrent mode, are doing this. 14:42:25 .. Browser doesn't ahve an affordance for what pending layout work is needing to be done. 14:42:57 .. Discuss: should the DOM have affordances for subtree layout. Events? Promises? Coordination in some other way? 14:43:00 q? 14:43:07 annevk: I'm confused often becaseu the DOM doesn't do layout. 14:43:12 .. rendering happens elsewhere. 14:43:25 .. certain getter/methods force layout to happen. 14:43:33 .. getComputedStyle/offsetWidth... 14:43:41 .. but not if you mutate the tree for a bit. 14:43:56 .. the costly operation happens later. And only if there is interleaving. 14:44:07 q+ to can you clarify what parts of lit element are async behind those promises? 14:44:30 .. proposal for DOMChangeList... idea is to batch up tree mutations so that they can't be interleaved with operations that would force layout. 14:44:52 .. problem with domchangelist is custom-elements. If you insert 100 CE, then that gets costly. 14:45:21 .. Sometimes the way we talk about it, it doesn't match how the browser works... 14:45:33 q+ 14:45:47 BoCupp: to Justin, in LitElement, what part is being made async? 14:45:57 justin: Element author writes a render methods. like in React. 14:46:08 .. it executes some logic... 14:46:29 .. for perf and mental model for the dev, we want devs to think of the state of the lemeent as having settled. 14:46:43 .. when render methods is called, an entire batch of changes has been applied. 14:46:52 BoCupp: Is that happening when the subtree is disconnected? 14:47:10 justin: If you set a property on the element, it enqueues and update. 14:47:17 BoCupp: So the user sees intermediate steps? 14:47:28 justin: No. 14:47:38 BoCupp: Trying to understand what the async step is... 14:47:45 .. is it just to keep the stack shallow? 14:47:57 justin: No, it's to batch. Just one render after you've set them all. 14:48:06 BoCupp: It's just to organize the order of operations in JS. 14:48:29 justin: One problem you see with big trees, with network effects between then... when you have a sync effect, it must travel all the way down the tree. 14:48:37 .. One property set flushes all the way down the tree. 14:48:46 .. Then you do it again, and it flushes down the tree again. 14:49:01 .. So, to avoid we batch, then you only get one pass down the tree. 14:49:14 BoCupp: So you fight the cost of DOM manipulation... 14:49:22 justin: Not just DOM, but the cost of the render method itself... 14:49:26 q+ 14:49:45 ack BoCupp 14:49:45 BoCupp, you wanted to can you clarify what parts of lit element are async behind those promises? 14:49:59 BoCupp: You have an efficient method to do that. Once you do the manipulation, you commit yourself for an uninterruptable layout process. 14:50:09 .. Could have complex layouts, nested grids... 14:50:30 .. Some of these other proposals enable the browser to stretch this time... 14:50:35 justin: different proposal. 14:50:56 .. we're reordering, putting in microtask queue, avoiding interleaving. 14:51:18 .. comes down to nested operations, brought on by custome elements and shadow dom. 14:51:54 .. C-E with property change notifications, can really explode the number of operations. 14:52:11 .. this has worked out well for us, with the exception of not having a standardized way of coordinating work. 14:52:16 ack rniwa 14:52:16 rniwa: Stepping back... 14:52:27 .. n^2 layout issue from DOM manip... 14:52:30 .. is a normal problem. 14:52:33 q+ 14:52:48 .. biggest mistake DOM api made from web devs perspective. They don't know what is cheap/expensive. 14:52:57 .. modern batching dom libraires solve this. 14:53:15 .. since your batching and finally do the work, it's relatively cheap. (virtual dom) 14:53:19 .. two general approaches. 14:53:37 .. 1) batched mutations. Make a list of changes, but make promises to make the changes, then commmit at once. 14:53:48 .. drawback: when you query, you're getting old state. 14:54:04 .. DOM is not live, can't get current state easily. 14:54:12 .. cumbersome model to work with dom changes you haven't made. 14:54:40 .. 2) Make global transaction model. Entire document stops update layout/style. 14:54:47 .. browser uses values from previous layout. 14:54:58 .. drawback: browser has to cache old values. 14:55:18 .. browser is forced to update layout at the beginning of the transaction start. 14:55:30 .. otherwise the browser won't know what values to provide during that frame. 14:55:45 .. for interop, needs to have a consistent approach, and I think it's up front. 14:56:01 .. we've talked internally. Conclusion, both models are bad. We just need to make layout faster. 14:56:17 .. style containment is not necessarily required. Browser could automatically do it. 14:56:23 .. Browser can invest more time optimizing. 14:56:28 ack smaug 14:56:57 smaug: Why do you use microtask? Will get tons of microtask checkpoints! 14:57:03 caridy has joined #components 14:57:07 .. Lots of promise chain callbacks. 14:57:22 justin: animation frames... 14:57:34 smaug: Today, you run tons of these callbacks... 14:57:43 justin: Any work you do might enqueue other animation frames. 14:57:53 annevk: Use animation frame as bootstrap.. 14:58:02 q- 14:58:07 rniwa: Have a library that does this--use rAF to track jobs. 14:58:15 justin: We don't have global coordination. 14:58:26 .. no queue specifically for a base class to do its work. 14:58:36 .. Microtask queue is one we can use. 14:58:55 annevk: You sort of want event-based animation frame, to allow multiple handlers. 14:58:56 +q 14:59:14 justin: If we did this on animation frame, it would trigger other animation frames... 14:59:26 smaug: Maintain a separate queue to process in the rAF. 14:59:29 pmdartus has joined #components 14:59:41 justin: You might not have all participatings in all the elments using that queue... 14:59:51 smaug: But they all use Microtasks... 15:00:02 justin: OK, you could do that if all C-E agreed. 15:00:26 .. how else do you coordinate among the different disparate CE? 15:00:50 annevk: 15:00:57 rniwa_ has joined #components 15:01:00 Ruphin: I think we've diverged from the original issue. 15:01:11 .. What's the evidance that Microtasks are a bad idea. 15:01:28 .. Rendering system is really efficient. Don't see the evidence for slow down 15:01:46 .. when we use queueing system, it's imposisble to tell when an element's rendering cascade is finished. 15:02:06 .. (other Microtasks will have happened, and I don't know the extent of when that will be done). 15:02:17 annevk: animation frame callback is before animation frame happens... 15:02:29 .. there is a proposal to tell after the animation frame is done. 15:02:33 rniwa: Use case? 15:02:51 Ruphin: Framework has a callback like 'updatecomplete' is called whenever its own rendering function is done. 15:03:06 .. when rendering is done, promise resolves, you know then that rendering is done. 15:03:21 .. you can't proceed with more style read, because you don't know if any children have pending tasks 15:03:38 .. React solves this because they globally control this. 15:03:44 rniwa: Understand. 15:03:45 q? 15:03:51 ack Ruphin 15:04:10 rniwa: How are component going to use that to do stuff? After knowing that all children are done with layout? 15:04:25 justin: virtual scroller. Add rows, measure layout, then add more rows. 15:04:28 q? 15:04:43 ack diervo 15:04:49 diervo: Clarifications.. we use the same thing, everyone has to implement batching, and the queue. 15:04:57 .. we had to add a callback re-render callback. 15:05:06 .. they need to know when they are done and in the DOM. 15:05:16 .. they need that single for devs to know when the work is done. 15:05:31 .. rAF doesn't work because of timing delay... 15:05:38 .. so we use Microtasks. 15:06:00 .. would be great to have a native primitive to know when a thing is inserted and ready. 15:06:10 .. probably not a panacea to make this cheap. 15:06:24 .. you have to be very precise and prescriptive to get coordination. 15:06:41 .. having a callback in the spec would allow frameworks to reconcile they're behavior. 15:06:51 .. would love to see a proposal in a web copmonents spec. 15:06:59 .. we do have the same layout thrashing problem. 15:07:08 rniwa_: When to render, or when rendering is done? 15:07:15 diervo: When it's finished. 15:07:38 justin: Confusion of terms. Not when the browser has finsihed rendering, but.. 15:07:45 q? 15:07:50 .. element has state change and needs to make state changes. 15:08:25 .. whatever the custom element logic is used to update it's shadow dom. 15:08:39 BoCupp: Moved from proposals... 15:09:07 .. whatever's at the end of the pipeline, there's browser work to do. Does anyone have a problem with this perf problem. 15:09:34 .. use case for after DOM update that rendering is taking too long? 15:10:01 .. Saw DOMChangeList, DisplayLocking to enable DOM mutation to be batched up, and interleaved enabling DOM control. 15:10:24 .. Use case: I have nodes that aren't critical for the next frame, but want them rendering. 15:10:39