ThemeRoller: Generate file containing variables for use in SASS/LESS

[scottgonzalez]

I think a YAML file of all the variables set in a Themeroller CSS file would be enough. we can build a compass plugin that takes a YAML file and convert it into constants that SASS can use. I think this is probably the same with LESS too.

Themeroller is too awesome to not have its variables made usable in other parts of a site's design! Keep up the good work folks!

http://bugs.jqueryui.com/ticket/5902

[jhilden]

I might be interested in working on this. It would be great to able to directly serve .sass (or .scss) assets from the jquery-ui-rails gem.

However, while I'm quite familiar with Sass, Compass, Ruby, etc., I'm not so familiar with the whole jquery-ui eco system, grunt, and so on. Maybe you could quickly outline what kind of solution you would envision/accept for jquery-ui and what parts I would need to look at.

I would envision all the default stylesheets being converted to Sass using default variables for colors, dimensions, images, etc., so they can be overwritten by official themes or custom tweaks by users.

The users would have the choice whether to work directly with the .sass files or to stick to compiled .css.

What do you think?

[scottgonzalez]

I don't want to convert our stylesheets. What I want is a polyfill for CSS Variables. I think the only reasonable output today would be a .json file of the parameters used to build the theme.

[jhilden]

I don't want to convert our stylesheets.

Do you expect any major downsides? You already have a build process in place and nothing would change for regular users of the compiled CSS. It makes the stylesheets a lot more DRY, easier to understand and provides awesome new possibilities for Sass users.

What I want is a polyfill for CSS Variables.

Couldn't Sass be considered to be "sort of" a polyfill for CSS variables? I think this will be the direction it's going in.

My major motivation behind this would be to have an easy, flexible and update-save way of customizing the jquery-ui styles. For example being able to do something like setting $border-radius: 0px, which would be honored by the jquery-ui sass stylesheets.

If that's something that you are not interested in at all, that's fine. That's why I'm asking here before building something.

[scottgonzalez]

Do you expect any major downsides?

I consider the act of choosing a format (Sass vs. LESS vs. Stylus) to be a downside.

You already have a build process in place and nothing would change for regular users of the compiled CSS.

But it would change for any developer who modifies CSS. Running a build never needs to happen during development right now. I'm ok with this process change though.

It makes the stylesheets a lot more DRY, easier to understand and provides awesome new possibilities for Sass users.

I don't think we'd become a lot more DRY, we don't have that much CSS to begin with. Unless you're talking about user CSS being DRYer because it can use the variables. For the same reason, I don't think it's going to make it much easier to understand. In fact, I don't think it will be easier to understand at all. It provides awesome new possiblies for Sass users and likely annoys all other CSS-preprocessor users.

Couldn't Sass be considered to be "sort of" a polyfill for CSS variables?

No. Either it conforms to the spec or it doesn't.

My major motivation behind this would be to have an easy, flexible and update-save way of customizing the jquery-ui styles.

Does this mean you don't even want to use ThemeRoller because you'll be setting variables on your own? If so, why not just write a simple script that converts our tokens to Sass variables? Should be super easy.

If that's something that you are not interested in at all, that's fine. That's why I'm asking here before building something.

I'd prefer if there were a way to build Sass/LESS/Stylus/whatever rules. But I don't want to maintain that in jQuery UI. It seems to me like it shouldn't be too hard to write a script that takes the base theme with the tokens, a JSON file with the values and generates the appropriate output.

---

It's worth pointing out that I don't want Sass for the same reason that I don't want AMD. It's not a standard, there are plenty of alternatives, we work in the lingua franca of the Web, and the appropriate standards bodies will eventually solve these problems.

[jhilden]

I do understand the issue about not wanting to endorse one particular preprocessor language over the other. However, so far we are only talking about using variables and that's pretty standard across the board. It should be easy enough to convert from one language to the other. I as a Sass user wouldn't be annoyed at all, if you would be using LESS, so I could base my work off of that.

I'm 100% convinced that all preprocessors will eventually support the spec concerning variables (they would be stupid if they didn't), so in my opinion it doesn't really matter which one you choose.

I think we completely agree on the end goal, but I personally would prefer a more iterative approach first using the existing tools at hand instead of custom building something new right away.

If so, why not just write a simple script that converts our tokens to Sass variables? Should be super easy.

As I said, I'm not so familiar with the jquery-ui/themeroller eco system, so could you elaborate what you mean by "tokens" here? Is that something existing right now?

[scottgonzalez]

As I said, I'm not so familiar with the jquery-ui/themeroller eco system, so could you elaborate what you mean by "tokens" here?

Sure. Several years ago, we built our own processor in PHP for the download builder (this has since been ported to node.js). We designed it such that the source is valid CSS and uses default values when unprocessed. This is still what we use today and is maintained in the jquery-ui repo (check out jquery.ui.theme.css for the file with the tokens). The syntax is pretty simple:

property: value/*{variable-name}*/;

This allows us to use real values but easily swap out values based on the variable name. Because this system is only meant to support our code base, the functionality is extremely limited and values must not contain spaces.

Here's a snippet from our current base theme:

.ui-widget {
    font-family: Verdana,Arial,sans-serif/*{ffDefault}*/;
    font-size: 1.1em/*{fsDefault}*/;
}

You can see that font-family uses Verdana,Arial,sans-serif when unprocessed and is treated as the ffDefault (font-family default state) variable when processed by ThemeRoller. This syntax is why we don't require a build process during development (though adding the requirement of a build process when working with CSS is not a concern for me).

So my thought for now is that we can just produce a JSON file with the variables. This is similar to the original request which is a YAML file (again, we work in the lingua franca of the web).

[jhilden]

Aaah. Thanks a lot for explaining. Now everything makes a lot more sense to me. I guess I will just try to work with that for the needs of jquery-ui-rails for now and see how far it takes me. After I have gained some experiences maybe we can talk more. Again, thanks a lot!

[rxaviers]

This is where DownloadBuilder places the default variables https://github.com/jquery/download.jqueryui.com/blob/master/lib/themeroller.defaults.js .

@scottgonzalez the above is basically the JSON we're talking about in this issue. Shall I convert/rename it to a JSON (and of course do the few necessary changes) and close this bug?

[rxaviers]

Ah! Note some variables are deduced/produced in https://github.com/jquery/download.jqueryui.com/blob/master/lib/themeroller.js based on the variables of that file.

[scottgonzalez]

@rxaviers Well, the JSON would need to contain the user-selected values, not the defaults (and then be included in the zip).

[rxaviers]

Ah! Never mind. Right.

This seems very simple to be implemented anyway. Wanna wait until a next release to define and include that file, or shall we go ahead and do it?

Chosen theme JSON variables:

css/<themeFolder>/variables.json
development-bundle/themes/<themeFolder>/variables.json
development-bundle/themes/<themeFolder>/minified/variables.json

Base theme JSON variables:

development-bundle/themes/base/variables.json
development-bundle/themes/base/minified/variables.json

Does this sound good?

[scottgonzalez]

Yeah, let's wait on this. @jhilden has already moved forward with an external implementation anyway.

[joliss]

... Running a build never needs to happen during development right now. ...

Speaking of all of this, I'm currently writing a client-side package-manager/asset-pipeline/build tool; it'll likely be npm based. (I'm maintaining the jquery-ui-rails gem, and I think these "-rails"-kind of asset gems really need to die, in favor of a backend-agnostic system. These asset gems have nothing to do with Rails except for the fact that they use Sprockets.)

You jQuery UI folks, with your build process and the theme roller, seem to have one of the more demanding use cases out there. I'd love to link up some time to understand what kinds if problems you are facing. Will any of you be at either CSSConf, JSConf, or NodeConf? (I'll be attending all three.)

[Thomas131]

I would also like a LESS-Support.

Thomas131