The idea behind Grips is that HTML templating and CSS preprocessing can be pretty much the same. Very neat.

grips.md

Here are some thoughts I had after reading through the slides and gist:

1. 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.
2. A command that generates JSON with keys representing the variable names used in a .gcss file would be handy.
3. 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!

A command that generates JSON with keys representing the variable names used in a .gcss file would be handy.

That's a great idea. Can you file that as a bug on the grips repo? http://github.com/getify/grips

I already have the plan to build tools which will import your sass/scss/compass/less stylesheets and convert them to grips syntax. This tool would sit nicely alongside them. :)

I feel like I missed the point of storing style variables in JSON

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:

1. 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).

2. 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.

3. 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.

Cool, thanks for the reply--very informative! I'll file a bug for the utility.

A couple more questions about *prop: (I don't mean to obsess about *prop--I'm sorry if this comes across that way. I know your project/idea is bigger than a single implementation detail.)

---

One of the things I like about Autoprefixer is that it affects more than vendor prefixes, e.g. property names and values:

justify-content: space-between;

becomes

-webkit-box-pack: justify;
-webkit-justify-content: space-between;
-ms-flex-pack: justify;
justify-content: space-between;

Would *justify-content: space-between; do the same in Grips?

---

Autoprefixer can target specific browser versions (so that generated CSS is not bloated with IE6 styles if those are unnecessary). Will Grips itself have a configuration file (maybe JSON) where browser support (or other variables) could be defined?

Would *justify-content: space-between; do the same in Grips?

First off, that divergence between browser syntax is unacceptably insane. They're the one making our lives harder. Shakes head.

But moreover, that kind of complexity is way beyond *, so if you need that, use autoprefixer. But keep in mind how big and complex that tool is, and how much weight that adds if you want to do that sort of thing in the browser. Your other option is to manually specify those things and avoid the big library, especially since those cases are (hopefully) pretty limited. :)

However, * used in the value portion is a placeholder for the prefix expanded in the property portion, so if you do:

*transition: *transform;

You get:

-webkit-transition: -webkit-transform;
-moz-transition: -moz-transform;
...

I do have a plan to eventually special-case some simple examples of this cross-browser divergence insanity, like (notice the "full-screen" vs "fullscreen"):

:-webkit-full-screen
:-moz-full-screen
:fullscreen

Autoprefixer can target specific browser versions (so that generated CSS is not bloated with IE6 styles if those are unnecessary). Will Grips itself have a configuration file (maybe JSON) where browser support (or other variables) could be defined?

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.

that divergence between browser syntax is unacceptably insane

It doesn't make web development any easier. :) I'm happy to see a trend away from vendor prefixes and towards runtime flags for experimental CSS/JS features in Firefox and Chrome.

However, * used in the value portion is a placeholder for the prefix expanded in the property portion

Didn't realize this before. Very useful!

it is my hope that CSS templates could be more environmentally-aware, through a variety of ways, including the dev using feature-detects

Yes. Agree with this. I usually use customized Modernizr scripts for this.