- From: Tommy Hodgins via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Dec 2018 20:19:54 +0000
- To: public-css-archive@w3.org
> You can do it on a limited scale, but a JavaScript synchronous read / update process can never be as fast or as performant as a solution in CSS … it can never beat a native feature Definitely agreed, but short of actually implementing this in a browser how do can this sort of functionality be prototyped and explored? Building a demo to try it out using technology we already have seems like a good starting point. I'm not trying to say this shouldn't be a feature, the opposite. I'm trying to explore the idea and establish: - the feature could be useful - if existing solutions to it (like what I've built) aren't adequate That's why I'm so confused by your reaction to this. I would have thought somebody wanting this feature like this would be excited about a demo, even if it's rough, because it proves _something_ about the idea. If you think the idea is useful and that my demo isn't good enough to use in production, that's something _good_ we have proven about it, and anybody can run the demo to see why it's not good enough for themselves and understand. Having the demo helps make the case for the feature. And having _more_ demos should help make the case for it even better. > If you mean to be hook points for JavaScript polyfills, no. That is not their primary design purpose. That's mainly the goal of worklets and the CSS Paint API (Houdini). JavaScript being able to interact with CSS variables so easily seems like it was intentionally designed and supported even if it isn't their _primary_ design purpose for existing. Right now CSS variables have a lot more browser support than the Paint API, so they seemed like a natural building block to begin exploring the concept and fleshing it out. If you wanted to experiment with totally custom syntax, CSS variables would still be a way you could include your custom syntax inside CSS in a valid way and handle parsing and processing of it outside of CSS while a feature like this was being worked on to help you avoid having to write invalid CSS. Even after a feature like this is added to CSS and begins to have browser support, at the time you want to start using it you'll probably need a frontend polyfill to support this feature in browsers that can't parse it, so the polyfill you would write in the future to support the feature in older browsers might not look so different than what a speculative prototype you build for this feature might look like today. I think it's worth thinking about. How would you prototype functionality like this to build a demo of it instead? I'd love to see a prototype of this idea working if you can implement it in a different way to test it out! -- GitHub Notification of comment by tomhodgins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3455#issuecomment-448730735 using your GitHub account
Received on Wednesday, 19 December 2018 20:19:55 UTC