Phantom Spacing On Inline-Block Elements

This was a hard problem to solve the first time I ran across it. Until flexbox gains better support, front-end developers have a couple of simple ways to align block elements side-by-side, each with its own distinct problems. You can float elements but then you have to worry about clearfix on parent elements. It may seem simpler to use display: inline-block instead.

Although that does mean you can leave off the clearfix, it also comes with a problem of its own. If you write good, readable HTML with indentation to show nesting of elements, inline-block is going to cause you some heartache. If you like me, you’ll start looking for some padding or margins you hadn’t accounted for, but the real culprit is much more difficult to find if you don’t know where to look.

Setting display to inline-block is going to effectively turn your block elements into inline elements. Let’s imagine I have a couple of divs with this display property set. Here’s my code:

     <p>Some content</p>
    <p>More content</p>

So, I have two inline elements amply spaced to make my code readable. Let’s think about this in terms of text, the most ubiquitous inline element. What happens to white space between two inline elements like characters of text? The whitespace between them is collapsed down to a single character. That means this:

I had
root    beer

will render as this:

Today, I had a root beer float

The same rules apply to our once-block-now-inline elements. We put in tabs and newlines thinking that’s just for us and the browser won’t care. While that’s true for true block elements, it’s no longer the case for inline elements. The browser inserts a single space between the elements and ignores the remaining newlines, spaces, and tabs we’ve used.

I built a pen on CodePen to demonstrate this and the havoc it can wreak on your layout.

You could always get around this and still use display: inline-block by cramming everything together, but who wants to read that code after the fact?

<div><p>Some content</p></div><div><p>More content</p></div>

My recommendation is that you instead use floats for the time being and hope for the day when flexbox comes to save us all from our element positioning nightmare!

Test Web Sites In Chrome For Android On A Mac

This tutorial assumes you already have Android emulators up and running on your Mac. If you don’t, I highly recommend you check out Julien Desrosiers’ article on setting up the Android emulator on the Mac. It’s an excellent guide to getting the basics in place for testing Android browsers on the Mac.

On iOS devices, all browsers must use Webkit to render pages. Alternative “browsers” are no more than wrappers around the default browser’s rending engine. When testing Android, proper display on Chrome, Firefox, and others doesn’t necessarily follow from proper display on the default browser.

Once you have your Android emulator configured and running, it’s not at all obvious how to install other browsers. You’re already set to test the default Android browser, but that’s only half the battle — perhaps even a smaller fraction of the battle than that!

In order to install an Android not bundled with the OS, you’ll need to get that app’s apk file. Unfortunately, this requires Google searches leading to really shady sites that primarily exist to enable Android software piracy. Since Google offers no official path to Chrome for Android testing on the Mac, this is the only way.

Once you have procured the Chrome apk, you’ll have to load it up on your device. First, start the emulator with the command emulator @<avd-name> from the terminal. The emulator should remain running while you run the install.

Pull up another terminal and run apb install <path-to-apk>. This should push the apk over to your emulated device. Launch the app by clicking the bottom-center button on the emulated screen to bring up the full app list. Then, simply click the app. If the browser runs and works as expected, you’re done!

This process isn’t especially difficult, but I found myself hitting two different roadblocks as I ran through it. First, I could not run apb from the terminal because its location was not on my PATH variable. To fix this, bring up your shell’s configuration file (~/.zshrc for some, ~/.bashrc for most). Add this to your configuation:

export PATH

Substitute your path to the SDK’s platform-tools directory when you add this to your config.

My second problem was a bit more difficult to nail down, but the solution was simple. I was able to get Chrome installed easily, but the rendering engine would not display. The browser would load web pages, but it would never display them. The interface also displayed odd behavior. The address bar would sometimes become invisible, among other things.

After trying several different Chrome versions along with the latest build of Chromium, I found the solution hidden in my device configuration. Run android at your shell to bring up the SDK manager. Go to Tools > Manage AVDs… Edit your AVDs turning on the host GPU option.

I also recommend you change your device to the Nexus S. Its lower resolution in comparison to many of the other devices make the emulator perform much better.

Now, you’re ready to test your site against Chrome for Android on the Mac. The road may have been circuitous, but the payoff is assurance your site looks great in one of the most popular mobile browsers!

Make And Change Directory Shell Alias

If you’ve ever cursed the fact that you need to mkdir <dirname> followed by cd <dirname> to create and change into a new directory, this snippet is for you.

function mcd() {
    mkdir "$@" && cd "$@"

Just paste that into your shell configuration (.bashrc or .zshrc in your home folder), restart your shell, and start making and changing into directories with just mcd <dirname>.

The Pitfalls Of Chasing SEO

I’ve always thought the whole SEO thing was a little slimy. Trying to reverse-engineer Google’s ranking algorithm so that your web site can be engineered to exploit it just seems gross. Perhaps, then, you could argue my observations about SEO are simply confirmation bias. That may very well be true, and I won’t even attempt to defend myself against those accusations.

Fortunately, it seems that, with every update to the ranking algorithm, my feelings are vindicated as Google punishes those who have exploited the algorithm. I recently heard an anecdote from an organization which makes significant effort to manipulate Google search ranking. One of their strategies is to pay for inclusion in online directories related to their industry. Since Google ranking is heavily influenced by the number of incoming links, this helped their ranking… for a while.

It was apparently a common enough practice that Google took notice. They updated their algorithm to, instead, penalize any site listed in a paid directory such as this. At this point, the company instead needed to remove their site from the paid directory. The paid directory, knowing it was on the fast-track to irrelevance, found a way to make a quick buck on the way out. They began charging sites to be removed from their directory. It’s dirty, no doubt, but you’re unlikely to get much sympathy if you’re trying to pay for search ranking in the first place.

It seems like a fitting end to a story of unscrupulous attempted manipulation of an algorithm designed to measure actual value in the real world. That is the intent of Google’s algorithm: to measure the actual value of resources on the Internet to real users not to measure clever and morally confused opportunists’ ability to figure out the machinations of said algorithm.

All of this is not to say that no SEO knowledge is worth having. It’s worth knowing, for example, that incoming links influence your ranking, that sites need to be mobile accessible (and redirect to the correct mobile pages when they aren’t responsive), and that pages filled with h1s will not do well in search ranking.

Rather than treating every tidbit of SEO information as a sign to completely change your strategy, make your SEO knowledge a small part of your overall strategy. SEO should be considered but should never be the guiding principal.

Instead of chasing links, try these changes that will improve your ranking:

  1. Make your site a joy to use on mobile as well as the desktop.
  2. Produce the kind of great and desirable content that will organically make people link to you.
  3. Interact with your people, whoever and wherever they are.

These tips, besides being more fun than min-maxing an algorithm, are less likely to be mitigated in future updates to the ranking algorithm. If you’re delivering a great experience for your users, you’re devoted to a practice Google and other search engines will strive to reward for years to come.

Adding To .gitignore From The Terminal

I learned a trick a while back to make my .gitignore file (and add to it) directly from the terminal. Here’s a common ignore for Python development to illustrate.

echo "*.pyc" >> .gitignore

Run this command from the root of your project. I like to do this right after I git init. This will create the .gitignore file if it doesn’t exist and add “*.pyc” to it. If the file does exist, it will append the string to it. Substitue “*.pyc” for whatever you like. I also tend to keep my Sublime project files out of version control. (Not sure if this is a good or poor practice, but I do it anyway.) Here’s the command that would set that up for me:

echo "*.sublime-*" >> .gitignore

That will take care of your Sublime project and workspace files.

Now, let’s imagine you’ve totally flubbed your .gitignore file. You’re ignoring too much, and you want to start from scratch and only ignore pyc files.

echo "*.pyc" > .gitignore

Notice that, in this command, I use only a single angle bracket here. Where two angle brackets append, a single creates the file anew with only the value specified.

Also, you may find it difficult at first to remember the direction of the angle brackets. I always remember that they point toward the destination (the file).