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!
On the server, I don't have a specific plan for configuration of such details. I don't think it would be impossible to consider a command-line flag for it at some point. But it's not on my radar at the moment.
When rendering in the browser, it is my hope that CSS templates could be more environmentally-aware, through a variety of ways, including the dev using feature-detects to know which browser, then that info informing how and what CSS is rendered.
For example, on the server, the default list of vendor prefixes will be
[ "-webkit-", "-moz-", "-ms-", "-o-", "" ]
(and you can of course change that default list if you never care about "-o-" or whatever). But when the rendering is running in the browser, it could/should detect IE for instance and then us[ "-ms-", "" ]
as the default list.In any case, my suggestion to handle your use-case would be to render the full CSS (sans IE6 stuff) on the server, then in the browser, detect if you're in IE6, and then render only the IE6.css template and inject it.