- From: Greg Whitworth via GitHub <sysbot+gh@w3.org>
- Date: Mon, 20 May 2019 14:25:42 +0000
- To: public-css-archive@w3.org
> It is not because it was synchronous that it was causing issues, it is because the only way to use this was to trash layout, and you need to trash layout O(n^2) Yes, I know that, but the synchronous version made this a terrible end user experience, thus compounding the issue of doing layout numerous times. > Using the same pipeline as RO to achieve the desired results will not solve any of the problems people are facing with RO today and which make them say this isn't the solution they want (while still admitting it is the solution they need, because there isn't any better yet). Again, I am not opposed with a longer term solution that is both synchronous and avoids the layout thrashing. Assuming that can be done and I also stated that I was for having an `async` & synchronous version so we won't need to worry about webcompat for the synchronous version. That said, the ways in which people have proposed to solve this issue, in the past, makes it so the use cases that web developers need, not work which defeats the purpose entirely. Seeing as how we haven't come up with a solution that both solves the pain points of web developers (bringing CQ to CSS, rather than in JS alone), and end-users, by keeping the main thread from being blocked; I think bringing RO into CSS is a step in that direction. At the very least it's gotten us talking about it further 😉 Finally, as denoted above - and I just want to repeat for emphasis, if you (or anyone) have any suggestions on how we can both solve web developer's use cases while also avoiding layout thrashing and thus allowing it to be synchronous; I happily welcome them. -- GitHub Notification of comment by gregwhitworth Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3852#issuecomment-494010079 using your GitHub account
Received on Monday, 20 May 2019 14:25:43 UTC