5 ms·
CSS variables land in WebKit (again)
- jacobr 14y agoThe previous implementation, with this syntax: @variables { foreground: green; } body { background: var(foreground); } was discontinued in 2008 [1] and we now have a new spec [2] var-foreground: green; body { background: var(foreground); } 1: http://lists.w3.org/Archives/Public/www-style/2008Sep/0194.html http://lists.w3.org/Archives/Public/www-style/2008Sep/0194.h... 2: http://dev.w3.org/csswg/css-variables/ http://dev.w3.org/csswg/css-variables/
- bsimpson 14y agoAlthough it's nice that they're being thoughtful about maintainability, it's a bit frustrating that they solved this issue four years ago, but shelved it. What's wrong with having a variable declaration block? There's a lot of CSS that's been written in the last four years that would have been much easier to read/maintain with proper variable support.
- BerislavLopac 14y agoI really don't understand why it's that difficult to incorporate something like SCSS, or a portion of it (e.g. no mixins) directly to browsers?
- cleverjake 14y agoMy understanding from reading about this on the CSS working group boards is as follow - the biggest issue is users assume CSS is instantaneous. If you ever see an interaction (other than animations), or a flash of unstyled content, it looks like a broken website. That means the W3C want to ensure any candidate they are using can be calculated on poor performance machines in a matter of a couple milliseconds. For one off variables this is not hard at all, but the the cascading effect of css means that a lot more calculations have to be made