- From: Matthew Dean via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Dec 2018 19:15:21 +0000
- To: public-css-archive@w3.org
> I wonder to what extent you can make use of CSS variables to simulate this sort of functionality in the meantime. You can do pretty much whatever you want with CSS variables, but because CSSOM is still in draft, any changes you make in actual output usually involves an entire replacement of a stylesheet's innerHTML, which will invalidate the style tree and can cause a document style recalculation / reflow. 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. The browser can immediately begin calculating a style tree very early in building the document. JavaScript-based solutions have to wait, look for styles, parse, calculate changes, and push updates, with more expensive side-effects. I know you've done a lot of impressive demos of what can be done with CSS variables, but it can never beat a native feature, especially because simulating "cascade effects" through JavaScript is trivial. It's why I would advocate for this even though it's in Less, because live variable bindings / cascade make it a more powerful possibility than a pre-processor (or JS live processor) can provide. > Isn't this why CSS variables exist? 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). -- GitHub Notification of comment by matthew-dean Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3455#issuecomment-448711705 using your GitHub account
Received on Wednesday, 19 December 2018 19:15:22 UTC