I'm pretty sure this is impossible, but I thought I'd ask just in case there's some crazy hack or something.

I keep my media query "breakpoint" values in Less variables — and I generate them with some complicated math based on OTHER Less variables. Naturally, it would be nice to get my media query values into JavaScript, so I can do matchMedia() stuff as necessary.

The least-bad idea I've had so far is to loop over every rule of every stylesheet, pick out the CSSMediaRules, parse them for max- and min-width directives, assemble all those values into a descending list, and infer where the breakpoints are from the list.

Needless to say, I'd rather not write that code if there's a better way. Any ideas?

Comments

75th Trombone created an issue. See original summary.

corey.aufang’s picture

If possible, you could do the math in PHP land and then pass them into Less with hook_less_variables() and into JS using drupal_add_js($vars, array('type' => 'setting')).

Getting stuff out of compiled Less files and into JS, there is no clean/easy way. You would pretty much have to parse the output css file yourself to retrieve the information.

Lanny Heidbreder’s picture

Okay, so I sat down to move the logic into PHP, but now I have an architectural question.

These breakpoint variables, naturally, go with my theme. So I would like them to be added to Less in my theme, not in a module. hook_less_variables() only works in modules, so I'd have to use hook_less_variables_alter() to keep it in my theme. But hook_less_variables_alter() says it can generate different values for every page, and that sends up all sorts of red flags to me about performance and caching and who knows what else.

The options of splitting the code between theme and module OR just moving everything to a module feel flatly incorrect, since it's my front-end theme that this stuff has to do with, not the admin theme or whatever, and I really want it all in the same place, not split up.

I don't know. Any advice? Should I not be as afraid of hook_less_variables_alter() as I am? Or should I just bite the bullet and send some of my theme code far away from home to module land?

Lanny Heidbreder’s picture

Upon further messing with this, I realized that the module confines injected Less variables to the module/theme doing the injecting. Which is of course an excellent and sensible feature.

So the only part of my question remaining is, should I feel the least bit squicky about using hook_less_variables_alter() in my theme's template.php, for any reason?

corey.aufang’s picture

It depends.

If you are getting mostly anonymous traffic and using page caching, then you shouldn't worry too much about it as most users are going to get a statically cached version.

Otherwise, as long as you don't have many things that change in your variables, then you shouldn't worry. Doing the math in PHP is going to be a very minor overhead compared to compiling the Less to CSS.

All variables that are passed into Less for processing are first hashed to create the output file name. If a file already exists with a matching hash, then it's assumed that there were no changes to the variables that were passed in and the existing processed file is served rather than re-compiling.

Also, if you're doing a bunch of math crunching that does add a page by page overhead, you could cache the results manually using Drupal caching methods: https://www.drupal.org/node/145279

Lanny Heidbreder’s picture

Status: Active » Fixed

Your next-to-last paragraph alleviates all of my concerns, and that's really, really smart. No further objections, and thanks for your help!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.