Here are some thoughts I had after reading through the slides and gist:
- I don't think I'd often use
*prop
. I don't keep track of which properties/values need vendor prefixes (or nonstandard code) to work with the browsers I'm targeting. I use Autoprefixer, which uses data from the Can I Use? database. - A command that generates JSON with keys representing the variable names used in a .gcss file would be handy.
- I feel like I missed the point of storing style variables in JSON. One benefit is "different site themes"--but most of my projects include a "_variables.scss" file that could be swapped out--oh, but that would require recompiling scss. I see. I think I get it now. Never mind!
If you're only ever going to do server-rendering (like in build process), then storing them in a JSON still makes sense for the avoidance of re-compilation (as you recognized).
But externalizing data is more important than that. It's also:
Separation of concerns: keeping data separate from "presentation" is an established best practice, I'm just extending that principle to the values of CSS variables (as presentational data). So keeping it in a separate file is important (which is one reason people make separate .sass/.scss files).
Externalized data lets you do complicated calculations where those operations OUGHT to be: in your presentation controller, not inside of the CSS file. Doing complicated math operations, lightening the tone of color values, etc.. I think all that is "programming" and "presentation logic" and that belongs NOT in your template, but in your presentation controller.
The only logic that I think belongs in any template (HTML or CSS) is "structural logic", things like variables, nesting, mixins, prefixes, etc in CSS templates.
Keeping data separate enables dynamic on-the-fly re-rendering of CSS (either the whole stylesheet or just parts of it) in the browser possible, whereas it's not possible with pre-processors only.