So, What Is The Difference Between em and rem anyway

For the longest time px was the way one specified the size of fonts, and pretty much anything else, when developing websites. If you are a responsible web developer, which we all should be, you would be concerned though that font sizes defined using pixels are absolute and does not change when a user wants to enlarge it using the tools the browser provides. This is especially true for Internet Explorer 6 – 8.

With that in mind, you might have started using em as your unit of choice when specifying font sizes. Not only will font sizes specified using em enlarge using the tools that the browser provides but, text will also resize relatively to it’s containing parent. And in that lies the difference.

While the size of 1em is determined by it’s parent in the DOM, the size of 1rem is determined by the root element, the html tag in this case. Let’s look at what this means. Let’s take the following simple HTML:

At this point, both h1 tags are of the same size. Setting the size of the h1 tags to 1em at this stage will make no difference as it inherits (cascades down) from it’s parent which is, at this stage, still the html tag. Now, let us tweak the HTML a little and add one more CSS rule:

Aha, now we can see the real difference. Whilst the h1 tag outside the wrapper retains it’s size based on the root html rule, the h1 inside the wrapper div, has now increased in size as this is it’s new parent. So, to sum it up once more, em resizes based on the size of it’s parent whereas rem resizes based on the root element.

For more reading please see Chris Coyier’s article on switching to EM and Jonathan Snook’s article on REM.

Switching to django-compressor in Playdoh

Around six months ago the Mozilla Playdoh project, a web application template based on Django, switched from using jingo-minify to using django-compressor for all things ‘combinable’ and ‘minifiyable’. Along with this we started using the staticfiles app i.e. django.contrib.staticfiles.

Both of these have been positive moves and while funfactory does most of the heavy lifting to upgrade your project successfully, or setting it up if it’s a recent clone, to use the above, there are still some changes you need to be aware of and make manually. These are the items I will then cover in this post.

NOTE: I here assume that you have already created and setup a basic Playdoh project using the Playdoh documentation here.

Referencing Static Files

The first thing we need to look at is how static files are references when using the new libraries. If you have been using jingo-minify you will be used to creating bundles in settings/base.py and then referencing those bundles in your template, for example:

Now with django-compressor there is nothing to do in your settings and you would include your assets as follows:

Now in late January of this year (2012) the project layout of Playdoh projects also changed in the sense that is no more apps nor media directory and instead, there is a ‘projectname’ folder. The great thing about this combined with the above two is that it is now possible to keep the assets needed for your app right there with your templates, views etc.

So, what does a typical project layout look like?

Well after funfactory has created your app you will have a structure as follows (looking only at the folder related to you project):

projectname
-- base
---- templates
------ .gitignore
------ 404.html
------ 500.html
------ example_base.html
---- __init__.py
---- models.py
-- examples
---- static
------ examples
-------- css
-------- js
---- templates
------ examples
-------- mobile
---------- ...
-------- bleach.html
-------- home.html
---- __init__.py
---- models.py
---- urls.py
---- views.py
-- locale
---- ...
-- settings
---- ...
__init__.py
urls.py

Whoah, that is a lot but, for the purpose of this post we are only interested in the base and examples folder. Going from the top, go ahead and create a folder called static inside the base folder and in this folder you can then store all of your core static assets such as your images, CSS/LESS and JS etc.

Next you can either create a new folder at the root of your project folder that matches your  projectname and remove the examples folder or, rename the examples folder to match your project’s name (this is what is assumed here, so most things will already be there but follow along) and remove anything you will not need. Inside this folder move into the static folder and again rename examples to your project’s name and do the same inside the templates folder. You should end up with something like:

-- base
---- static
------ css
------ img
------ js
---- templates
------ .gitignore
------ 404.html
------ 500.html
------ base.html
---- __init__.py
---- models.py
-- projectname
---- static
------ projectname
-------- css
-------- js
---- templates
------ projectname
-------- home.html
---- __init__.py
---- models.py
---- urls.py
---- views.py

Before we can start coding, we need to add something to our urls file to make development smoother i.e. you do not need to run the collectstatic command every time you add something new or make a change to an existing file. Inside the root folder of your project open the urls.py folder and add the following (This might already be present so double check before adding):

Now we are ready to code our project and use our static assets. Inside your base folder open up the base.html (if it is still called example_base.html, rename it) folder. Inside the head section of you page add the following to link your main CSS:

As you can see here we are using the static function inside the href of the link tag to point to the file we want to include, we also wrap this up in a site_css block, that will come in handy in a minute, as well as using compress css. The site_css block gives us a hook that we can later use to override what is in base or, add something additional. The compress css will ensure that what is inside it will be minified and potentially preprocessed if you use, for example LESS (as is the case in these examples).

NOTE: If you are using LESS you need to ensure that you have Node.js and the lessc preprocessor installed and that it is in your PATH. For more on this see the LESS website’s server side section. Also, django-compressor has built in support for LESS by default and will as such recognize the use of text/less as the value for the type attribute on the link tag.

Next, move into your projectname/templates/projectname folder and open up index.html

As you can see from the above we here use the site_css tag from before and then call super() which will ensure the file(s) defined in the template we are extending is included as well as the new file(s) we are adding for this specific template. The one difference you will notice is that inside the index.html file, instead of using css/ourfile.less, we are prefixing it with projectname/css/ourfile.less, this is to inform Playdoh that you want to load the file from the static folder of your projectname folder and not base.

The same then also goes for including images as well as JavaScript but, with JavaScript there is a slight difference:

The main difference being creating a block called site_js and then calling compress js inside your block. Inside your template extending base, the usage is then the same as before with this one change.

This should then get you up and running quickly and easily using django-compressor, the staticfiles app and the new project layout of Playdoh. If there is something I missed or you have any additional comments or questions, please feel free to add them in the comments.

Debugging B2G-Desktop Blank Screen On Launch – Gaia

When launching a B2G-Desktop build, has your testing been brought to a grinding halt due to the blank screen of death?

I was the victim of exactly the above scenario during the course of the last week as my focus shifted almost exclusively to working on Gaia, the UI layer of FirefoxOS. As with most new projects one get’s involved with, one of the first steps is getting a working development environment set-up. With Gaia there are basically three options, and the one you choose, depends on either your stage of development or, the module you are currently working on. I am not going to go into to much detail here about your options, but suffice it to say, at some stage you will touch all three.

Now, as mentioned before, my problems started when I loaded up a B2G-Desktop build using my own working profile of Gaia. After installing the dependencies, I ran the following command:

/Applications/B2G.app/Contents/MacOS/b2g-bin -profile 
/Users/sneethling/mozilla/projects/gaia/profile

I was greeted not with the home screen but instead, with a pure white, blank screen and absolutely nothing being written to stdout to give me a hint as to why this is happening. I headed over to the Hacking Gaia page on the Mozilla Wiki to see if there was anything related to this problem, and indeed there seemed to be. When reading more of the details though, I realized this was not exactly what I was running into however, the second possible problem seemed plausible.

From here on then you can follow along to determine whether this is what is causing your desktop build to break as well. Head over to $GAIA_HOME/profile/extensions/httpd/content/ and open up the httpd.js file and find the following line:

/** True if debugging output is enabled, false otherwise. */
var DEBUG = false; // non-const *only* so tweakable in server tests

This is then the variable we want to set to true to enable logging of the process. After doing this start up the desktop build again. NOTE: Be careful not to rebuild you Gaia profile at this time as it will overwrite your change from above.

When the build starts up now, you will see some logging output being written to stdout. Your mileage might vary but, in my case I saw output similar to the following: “port 8080 x number of pending connections…”. That definitely sounds like there might be another process bound to 8080 so, the next step is to find that process.

Before looking at how we can find the offending process I want to take a short detour that will surely save time for some of you. If you are running CrashPlan, chances are 99% that this is the offending process but, as it also turns out, it is not port 8080 that is the trouble maker but instead port 4242 to which B2G opens socket, that is the real issue here. Nevertheless, below we will fix both possible problems.

if CrashPlan

Open up the CrashPlan UI and click on Settings and then under the General tab, click on the Configure button next to ‘Inbound backup from…….’ and change the listen port from it’s default of 4242 to something like 4142 and click Ok.

Screen Shot of CrashPlan inbound backup settings

Now, load up b2g-bin again and everything should be as expected.

if !CrashPlan

If you are not running CrashPlan, then we have to dig a little deeper to find the problem. In the terminal execute the following:

sudo lsof | grep -i 'listen'

The command might take a little while to complete depending on the number of process running at the moment. Once it returns, you will see output similar to the following:

Screen Shot lsof output

On the far right of the above is where we want to look for a process that is listing on either port 8080, 4242 (if you look at the output when starting b2g you will see a socket as opened on this port) or even 2424 as all of these are known to cause conflicts. Once you have a found the process, and identified the application, you can kill the process by taking it’s id, in the second column from the left, and running kill -9 ‘id’ from the terminal. Once the process is terminated, go ahead and load up b2g-bin again. This time, as with the CrashPlan fix, everything should work as expected.

Thing is though, it is not always desirable to simply kill a process running on port 8080 and you might wonder, why can I not just change the port for Gaia? Well, you can. To do this, build your profile as follows:

GAIA_PORT=9090 DEBUG=1 make

With the above Gaia will now bind to port 9090 and no longer 8080. If you make the above change, remember to update your hosts file so it also maps to the same port. For the socket port of 4242 however, you will have to follow the steps above.

I closing then. Now that everything works you may find that, dependent on how many times you went through the trail and error process, once the desktop build does start up, you are welcomed with a screen similar to the one below:

Screen Shot mutiple homescreens

In more cases then not, the last one would be the one you want. Having said that, to select a homescreen every time  before you can interact with the lock screen can get annoying so, if you want to get back to only one clean profile, you should run:

rm -Rf profile/
DEBUG=1 make

I hope this helps you to get up and running quickly and contributing to Gaia and FirefoxOS. On a final note, I wish to call out and thank James Lal (lightsofapollo) for all his assistance during my debugging experience.