Specificity wars

light sabers

When you look through the element styles of your browser web developer tools, you can see how CSS rules override themselves. What is prioritized is mostly based on the specificity level. It’s a usual thing that styles below override the ones above, inline styles override external styles. These are the little things but it gets deeper when we use id selectors around our stylesheets. Ids have high specificity and there are uncalled for as we don’t want unnecessary spikes in our specificity graph. This css-wizardry article tells why IDs can be the demons of our stylesheets.

I seldom use CSS frameworks, but I do know that bootstrap makes use of classes. If you are not taking advantage of many selectors available today, then you can just stick with the type (element) selectors and classes.

I just sounded like IDs were evil. What’s more evil is the !important. If you’re a beginner or intermediary CSS writer, then there is a big chance you use the !important which is a maximum specificity level and it’s why it usually overrules the other rules (predecessors and successors). Some designers/developers now find themselves in a quandary when told not to make use of !important they have gotten so used to. They ask questions like Then what should I use?, What else can do the job?.

Chained class naming bro! Chained class naming does it like a boss and then you don’t have to worry about doing something wrong. When you have a class like .box that you need to specify more. You can do it by chaining this way.

I had only gone on four chains. You could make this as long as you want. I recently had to go about 12 chains long to overrule an existing style on a wordpress child theme I worked on.

The class chaining should always be used in place of !important.

I made this pen to create a specificity war.

See the Pen A specificity test by Joseph Rex (@bl4ckdu5t) on CodePen.

If you look through the stylesheet of the pen you will see I had a 30 chains class selector, an id selector, and a class selector with !important. Well, I know, !important overrules our chained class naming but when we are on a specificity fight with normal class and id selectors, the class chaining will be king. So for no reason should we still use the !important over class chaining except we already have it used in the rules we are overruling. Then the order of precedence will be our win point.

Harry Roberts described how the specificity graph of your project should be. He spoke of our helper classes that usually tend to carry !important. As much as I avoid the !important, I have it occurring once or twice in my helper classes. Before I ever put specificity to consideration, I’ve always imported my helpers at the bottom of the stylesheet. You can see that of a jekyll project I just worked on here:

The reason for this as mentioned by Harry is for our specificity graph to be upward trending.

I used the online specificity graph tool to analyze that pen and here’s what it gave:

specifity-graph

This graph is great and it has worked fine in giving me a graph of bigger projects. There’s a downside to it though. It doesn’t include rules with a !important value in them. I have my codepen demo giving me the selector with !important as the most specific but then the graph has its highest specificity at the end of the stylesheet to be the 30 chained class selector. The other rise in the middle is the id selector.

Parker is a command-line npm package that analyzes CSS and also shows elements with highest specificity.

Conclusion

Avoid ID selectors, avoid !important, start with selectors like *, html, and other element selectors that aren’t too specific, then move on to class selectors. If there is a need for class chaining or !important in your helpers, they should be at the bottom. If there is no need for them, the helpers partial of your project should still be at the bottom if you want it overruling other styles by precedence.

Moving from sqlite3 to postgresql database for your rails project

Rails uses sqlite3 by default on development. If you are not careful enough, you may get so comfortable with sqlite which I did. After a while, there will be a need to push the application to production and at this point, you wouldn’t want sqlite on your web server. I’m using heroku for my app and they stated some good reasons not to use sqlite. On heroku, you wouldn’t be able to push your application to production if sqlite3 remains in your Gemfile.

If you are starting a fresh project, you can just begin this way:

On an existing project you’ll have to replace modify your Gemfile to replace

with

run

After which you should change your database.yml in config directory. It should look somewhat like this:

The adapter has been changed from the default sqlite3 to postgresql.

Next you should create this db in postgre with rake

If you are like me, you should encounter an error at this point. You can’t access psql. This is because the username (joe) is not set as a role in psql. To create one

If you’re on psql < 9.3 you may encounter an error with the –interactive switch so it’s best you try to upgrade.

Now you can create a password for the user that has been created. Log in to psql

and alter the role of the user created with:

If for any reasons this fails, you should modify your pg_hba.conf file to use md5.

Using OpenDNS as your machine’s default DNS

I was working on a rails app last week and at some point, it failed to fetch the google fonts I had used within it. After about 2 days, everything was fine again so I didn’t have to worry about anything. Earlier today, I was developing a jekyll blog and the same thing happened. This time I really needed my fonts to be the way I wanted them from development. Chrome failed to fetch the woff2 google fonts displaying the following error.

Failed to load resource: net::ERR_NAME_NOT_RESOLVED

Then I tried out my firefox developers edition and it suggested it was a CORS problem which I didn’t totally agree with.

cors on firefox-dev

click to enlarge

After all these, a friend from the IRC suggested I changed my DNS and try out OpenDNS. I did that and it all came back fine. Here’s the short article that guided me through changing to OpenDNS

http://debian-bits-and-snips.blogspot.co.uk/2010/09/using-opendns-as-your-default-dns-in.html

FYI, I use a Debian machine and I believe that should walk on Ubuntu and Mint as well. I heard it’s a very easy thing to go about on OS X too.