Info

This is where frequently asked questions will be answered. The list will be updated need be and added to when a question is asked frequently. If you have a question that is not answered here I recommend you ask your question on the ctr forum board, Reddit subreddit, Gitter Chat, or Stack Overflow.

Performance & Size?

First off, to make sure we are on the same page, the goal of ctr is to create CSS faster and manage CSS complexity better. The raw performance and size of CSS will never be a primary goal of ctr, however, in future releases, I plan on adding some features to help reduce the raw CSS output size.

Performance

Once upon a time, there was cause to avoid deeply nested CSS child selectors due to performance concerns. Along the following lines:

.peopleOn > .theInternet > .willTell > .youTo > .neverMake > .aSelectorLikeThis

Well, I have good news it’s no longer 2008, and this argument is no longer relevant like <blink> — shoots fired. Want proof, check out the tests below.

However, as you’ll notice the more targets, the greater the performance difference between the two selectors. Rule of thumb is if you’re creating a boat load of elements (+10,000) always use a single selector. In the same breath, deeply nested CSS child selectors do create other side-effects. Chiefly, it increases the brittleness of the relationship between CSS and HTML. That is if you change your HTML you will have to change your ctr styles, but due to the Object tree data structure of ctr, it makes these changes trivial. In my opinion, child selectors are the most underrated feature in CSS hands down.

Size

There’s no way around it, ctr will increase the size of your CSS if you use ctr how it’s intented to be use — to created CSS faster. This is due to CSS duplication. That’s not to say you can’t use ctr in a manner that won’t increase the size of your CSS, but it somewhat defeats the purpose. Personally, I used to be the “type” that did everything I could to save 25KB, that is until I realized the fruitlessness of the endeavor in my context. Keyword — context. If I were working on an Amazon-like-traffic website and had optimized everything else, CND’s, HTTP/2, GZip, etc., then saving 25KB in CSS would be on my list of optimizations, given it makes $ sense.

So the question becomes, do you value your time more than a few KB? If yes, then ctr is your answer. If no, let me remind you that you can’t buy more time and we are all running out of the stuff. ☹

Sass Support

I have bad news for the majority, there’s no Sass support as of right now. I thought about it, and it’s possible, but there’s little direction as to how to integrate custom plugins not written in Sass. Plus I have a distaste for Sass due to the syntax — I’m a Stylus fanboy. In the future, there’s a good chance there will be an official Sass ctr plugin. However, I’m open to helping anyone that would like to take up the endeavor. “Technically” you should be able to drop in the same ctr implementation that I created for Less more or less. You can view the Less implementation here.