Skip to content

Instantly share code, notes, and snippets.

@smockle
Last active August 29, 2015 14:01
Show Gist options
  • Save smockle/8a06bb6f566c809c6aeb to your computer and use it in GitHub Desktop.
Save smockle/8a06bb6f566c809c6aeb to your computer and use it in GitHub Desktop.
The idea behind Grips is that HTML templating and CSS preprocessing can be pretty much the same. Very neat.

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!
@getify
Copy link

getify commented May 12, 2014

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.

@smockle
Copy link
Author

smockle commented May 12, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment