If you followed the steps in the last post on setting up your development environment to leverage SASS, you should be all set to start rocking some seriously awesome custom themes for your Sencha Touch app. But before you dive in, you might take a few moments to take a deep breath and survey all that’s going on to build out the default Sencha Touch theme.

It’s not that you couldn’t immediately jump in and produce something awesome–you definitely could, and it would be pretty simple. I suggest browsing the default theme, however, because despite how easy it is to being customizing your own .scss file with new colors, icon masks, and whatever else strikes your fancy, actually understanding (if even in a very preliminary sort of way) what’s going on will help prevent future frustrations that may dampen your sudden excitement to start theming.

With that thought in mind, let’s take a few moments to peek around the default theme to see how the magic happens.


In your Sencha Touch installation, browse to /resources/sass/. In this folder, you’ll see a file named config.rb. This file, written in Ruby, is one of those “setup it up and leave it alone” kind of files. In a nutshell, this file brings all of theme together, letting the compiler know where particular assets are located, how it should output the content, etc. If you follow the lead of Sencha Touch’s default theme, this is a file you can leave alone…or copy and modify according to how you set things up.

One of the more important things to note about this file is the “load” directive. This tells the compiler where to find the core assets (.scss files) that contain the code which will generate the ultimate .css files. In the default config.rb file, this loads .scss files located in the /resources/themes/ folder. We’ll take a look at that in a second, but for now, just remember that the config.rb file absolutely needs to point to the right location, or else the compilation won’t work right. So if it’s working…leave the file alone!

The last thing to point out is the css_path configuration. This is important, because it specifies where the compiled .css file will be saved (in this case /resources/css/). And the way that Compass works, there will be a one-to-one correlation between the .scss files that are a part of the compilation and the .css files that are produced. So, if we were to run the compilation in the /resources/sass/ folder, we would find a .css file in the /resources/css/ folder for each .scss that was compiled: in other words, /resources/sass/sencha-touch.scss = /resources/css/sencha-touch.css.


I hope that last point was clear. If it wasn’t, I’ll reiterate it this way: You know the sencha-touch.css file that you are probably loading based on your following of the “Getting Started” example? All of the style rules in this .css file are the direct result of a compilation of the resources/sass/sencha-touch.scss file. While you probably thought the .css file was the result of some poor slob painstakingly putting together all that complexity, the actual production of the .css file comes as a result of sencha-touch.scss getting compiled, and SASS working its magic.

If you open up sencha-touch.scss, you’ll probably be pretty underwhelmed. It’s a very small file, but deceptively so. In reality, it is a gateway to initializing the entire beauty of SASS, a process that will eventually involve dozens of other .scss files.

So the very first line you come across is a variable: $base-color: #7A1E08.  This one line will control the overall color scheme for the Sencha Touch application. If you were to modify this to, say, some green color, recompiled, and then refreshed your application, you’d notice that the entire aesthetic of your app would change; that one simple line would have deep impacts in the theme of your application.

That’s pretty cool in itself, but let’s keep moving…A few lines more, we come across the following:

@import ‘sencha-touch/default/all’;

In SASS, you can import other .scss files. So in this example, the sencha-touch.scss file includes another called ‘all.scss’. But where is this file? Well, if you look in /resources/themes/stylesheets/sencha-touch/default/, you’ll find a file named _all.scss; despite initial appearances, this is the one that’s included on sencha-touch.scss.


Yes, at first it’s a little confusing. Let’s break it down, and hopefully it will make more sense.

First off, how does Compass know to look there to find that file?

If you remember the config.rb file we looked at earlier, look at the “load” directive. This tells Compass where the theme is located (e.g., the “themes” folder).

Okay, but how about the “stylesheets” folder? I don’t remember that being configured anywhere!

True, we didn’t specify that in config.rb, nor anywhere else. The answer is that this is “default” configuration of Compass. There is a configuration variable called “css_dir” in Compass…unless you override, it defaults to “stylesheets.” If that’s something that might drive you crazy, feel free to add css_dir = “stylesheets” to your config.rb file; it won’t change anything, but may make getting your head around it a bit easier 🙂

Fine, that makes sense. But how about that “_all.scss” file? The import directive didn’t have an underscore?!?

This is another Compass-thingy. By default, Compass will compile ALL .scss files to .css files. However, you can create what is called a “partial“–this is just a normal .scss file with an underscore at the beginning of the file name. This tells Compass not to compile, but it’s still able to find the file and use it.

Moving On

Hopefully it’s now what this simple import statement is doing. The remainder of the sencha-touch.scss file that we’ve been looking at is the inclusion of the default set of Sencha Touch style collections. While we won’t get into these right now, you might make note that these can be commented out in order to save precious bytes on the total size of the compiled .css. In other words, if you’re not going to use something (like Carousel), don’t include it! The loading speed of your app will thank you.


For the last discussion of this exploration, go ahead and find that elusive _all.scss file and open it up. You’ll notice that it’s yet another gateway file, merely importing more .scss files. As you have time, follow the path of imports, making note of how the files are inherited and what each file does. As you browse these files, you’ll eventually get to terminal pages that actually have quasi-CSS-looking code. This is where the magic of SASS happens. Using a conglomeration of SASS variables, mixins, and super-sweet rule nesting, the final complexity that is the sencha-touch.css is built, bit by bit. Then all of it is wrapped up, compiled, and spit out as our awesome .css file.

Wrapping Up

Yes, I know: we didn’t actually get to any custom theme building. However, I think the walk through is important, if for nothing else than to provide some exposure to how the many .scss files that make up the final sencha-touch.css file work together. Plus, if you’ve taken the time to actually understand how all the bits fit together, you’ll find that setting up your own custom .scss file (or even an entirely custom theme) is a lot less painful and frustrating. After all, creating custom design should be fun and inspiring–you shouldn’t have to fight with environmental unknowns when trying to achieve your goals. So even though this little detour has not produced any custom styling, we’re now in a much better place to start tackling a customization…and that’s what we’ll dive into in the next post.