- From: Rick Byers via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Dec 2023 15:38:38 +0000
- To: public-houdini-archive@w3.org
Thanks for reaching out Andy! From Chrome team's perspective I think we largely decided that this was just incredibly difficult to do, even for us, AND unlikely to get support across engines. Lately we've been focusing instead on higher-level APIs like [scroll animations](https://drafts.csswg.org/scroll-animations-1/). I still agree with what I said about higher-level APIs being fundamentally limited and low-level primitives being more powerful. But I also now think it was a grave error for me to argue against prioritizing such APIs [like snap points](https://lists.w3.org/Archives/Public/www-style/2014Feb/0769.html) in favour of getting scroll customization primitives (I just underestimated the challenge by at least an order of magnitude). While I still agree with much of the philosophy of the [extensible web manifesto](https://extensiblewebmanifesto.org/), I think we got the priority wrong then. IMHO in a world of quite limited resources for browser engine investment (especially considering across WebKit/Gecko/Chromium) the first priority should be to ensure the 95% use cases can be done easily and (crucially) in a highly-performant way with declarative APIs. Making the remaining 5% possible in some way is also important probably less so. Do you know to what extent the things you've been looking at could work on top of declarative APIs like scroll animations? Perhaps some are possible with relatively minor addition to those designs? Transforms based on scroll positions, synchronized scrolling and scroll speed "warping" all sound to me like things that should either be possible to do already or that require only minor additions. I don't see any path in the next few years by which the Chrome team will be able to invest seriously in the low-level scroll customization primitives I proposed here. At the same time, if someone else was willing to make the (IMHO massive) investment in Chromium to do so in a sustainable and quality way, I don't think we'd necessarily be opposed to it. Just given the limited (I know, hard to believe) resources we have to invest in this space, I think we can get more value for web developers via the higher-level approaches. WDYT? -- GitHub Notification of comment by RByers Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/1118#issuecomment-1854163406 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 December 2023 15:38:47 UTC