Using ‘aria-labelledby’ as a styling hook

A couple of months ago, I was greatly inspired by an article on Smashing Magazine entitled Semantic CSS With Intelligent Selectors by Heydon Pickering. It goes into depth on how aria roles can be used as hooks for button styling among other things.

After using some of Heydon’s techniques, I got thinking about how they could be applied to layouts and suchlike. I harassed him on Twitter for his thoughts styling various elements with landmark roles and then stumbled on the aria-labelledby attribute. It turns out that this makes for a perfectly semantic styling hook.

Normally I would use classes when styling sections of content for example:


<section class="section-latest-products">
  <h2>Latest products</h2>
  <ul>
    ...
  </ul>
</section>

<section class="section-press-news">
  <h2>Press news</h2>
  <ul>
    ...
  </ul>
</section>

Now using ‘aria-labelledby':


<section aria-labelledby="latest-products">
  <h2 id="latest-products">Latest products</h2>
  <ul>
    ...
  </ul>
</section>

<section aria-labelledby="press-news">
  <h2 id="press-news">Press news</h2>
  <ul>
    ...
  </ul>
</section>

And the CSS:


section[aria-labelledby="latest-products"] {
  /* Latest products styling */
}
 
section[aria-labelledby="press-news"] {
  /* Press news styling */
}

Using ‘aria-labelledby’ not only increases accessibility, it gives us a styling hook with the bonus of being able to link to the relevant sections using anchors such as ‘#press-news’.

Having not been fan of techniques such as BEM due to them littering markup with unsemantic class names, this just feels right. I’m sure there are other ways that aria attributes could also be used.

Thanks again to Haydon and his article for opening a can of worms in my head, which lead to this solution.

See the Gist and the Twitter conversation.

OSX Terminal – Tab and window shortcuts

In a previous post, I shared a tip on Naming your Terminal tabs in OSX Lion. I’ve been meaning to share some additional shortcuts that I use day-to-day for opening new tabs and renaming them via the command line.

The workflow

We can rename tabs and windows as before:


# Rename tab
tabname "Funky Tab"

# Rename window
winname "Funky Window"

Or, leave out the name to base it the current directory:


# Rename tab to current directory name
tabname

# Rename window to current directory name
winname

…and to save typing, these are aliased as ‘tn’ and ‘tw’, so this will do the same:


# Rename tab to current directory name
tn

# Rename window to current directory name
wn

Now, for opening a new tab we have:


# Open new tab, cd into same directory as current tab and name it
tab

By default this will open a new tab, cd into the same directory as the current tab and name it based on it’s directory. You can optionally include a path:


# Open new tab, cd into specified directory and name it
tab ./path/to/directory

Of course, there is a lazy version of creating tabs too:


# Shortcut for 'tab'
t

The code

To get this functionality, just drop the following into your ~/.profile file:


function tabname {
  # Will use current dir name if called without arg.
  printf "\e]1;${1-$(basename `pwd`)}\a"
}
function winname {
  # Will use current dir name if called without arg.
  printf "\e]2;${1-$(basename `pwd`)}\a"
}
function tab {
  # Will cd into current dir if called without arg.
  osascript -e 'tell application "Terminal"' \
            -e 'tell application "System Events" to keystroke "t" using {command down}' \
            -e "do script \"cd `pwd` && cd ${1-.} && tabname && clear\" in front window" \
            -e 'end tell' > /dev/null
}
alias t='tab'
alias tn='tabname'
alias wn='winname'

See the Gist here.

Happy tabbing!

Git add -A and git commit one liner

When working with Git, I often find myself typing:


git add -A && git commit -m "My commit message"

This stages any changes including new files (which "git commit -am" doesn’t), marks any files that have been deleted from the working copy as removed and commits to the repository.

Following a quick Google search, and thanks to this handy git alias article, I created a “ca” (commit all) alias using:


git config --global alias.ca '!git add -A && git commit'

Now committing all changes is as simple as:


git ca -m "My commit message"

This is a good solution, however I prefer adding the following function to my ~/.profile file:


function gca {
  git add -A && git commit -m "$1"
}

Which gets us to:


gca "My commit message"

Quickly pushing your public SSH key to a server

I find myself needing to do this on a regular basis, so here’s a handy snippet for adding your public SSH key to a server’s authorized_keys file, assuming your public key is at “~/.ssh/id_rsa.pub” (the default).


ssh user@host "echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys"

…or pop this in your ~/.profile file:


function push-key {
  ssh $1 "echo '`cat ~/.ssh/id_rsa.pub`' >> ~/.ssh/authorized_keys"
}

and run the following when you need to push your key to a server:


push-key user@host

Edit: Christopher mentions in the comments that you could use ssh-copy-id which is great on systems that support it, however it’s not available by default in OSX.

Announcing Tache – Just enough Mustache for end users

I’ve finally found some time (thanks to the xmas break) to have a crack at a ‘safe’ Mustache implementation in Ruby. By this, I mean an implementation that allows for templates to be edited by end users without fear of jeopardising an app’s security. This is useful in many situations, for example in a CMS or to allow users to customise email responses etc.

In order to gain a full understanding of how Mustache works internally, I decided to first write a full Mustache implementation from the ground up. Once this was done, I looked at ways to implement ‘safe views’ using Liquid as inspiration. Tache meets the current Mustache spec, apart from a few whitespace differences that I will be addressing shortly.

You can view the project on Github which contains the full documentation.

Happy New Year!

Embracing perfectionism as a long term goal

I’ve suffered for a long time with a condition known as perfectionism. It’s a debilitating disorder that hampers productivity through a constant pursuit of idealism.

There are many problems that come with being a perfectionist. Firstly, there is the aforementioned productivity impairment. But also, it’s hard to be happy with anything you produce or anything you’ve achieved in life, as you always believe you could have done better. This does have a side benefit of driving you toward your goals, the problem being that as a perfectionist, your goals are always evolving and often unrealistic.

I’ve fought with the productivity/perfectionism conundrum for a while now and have come to terms with the fact that I will always be a perfectionist at some level. Both my parents are perfectionists, it’s in my DNA. Instead of fighting this innate condition as I have done over the past few years, I’ve recently found a way of embracing perfectionism by treating perfection as a long term goal. So, what do I mean by this?

Let’s take an oil painting as an example. First the artist starts with a thick brush and large blocks of colour to give a general overview of his subject. At this stage he is much more agile and can easily change direction should he need to. Later, after the paint has dried a little, he adds more detail. He repeats this process until he is working with tiny brushes, on the minutest details. There is a great deal to be learned from this technique.

I am suggesting the long term goal of a perfect project, without getting bogged down by tiny details at the outset. Do just enough to fulfil the project requirements with a view to tweak (and perfect) further down the line; there is no point perfecting something that is subject to change. Giving yourself permission to let stuff go until later is the key, however it’s extremely important that this tweaking phase is included in the overall project plan.

Perfectionism is fine as a long term goal, just don’t let it hinder in reaching those goals.

A few notes on Responsive Design

I’ve been working on a few responsive design projects recently and an old friend of mine asked what I had leaned on my journey, below is my response (pardon the pun):

Basically, it’s seen as bad practice to target specific devices, instead you should just target the breakpoints that make sense i.e. scale the browser down until something looks wrong, then add a media query to fix it, rinse and repeat. That way you’re future proofing yourself as it will look good at any width, even on that device that hasn’t come out yet.

Ideally you should do ‘mobile first’ design whereby you start with the mobile version (duh!) and work your way up, this ensures that you focus on the content and that you don’t get into a situation where something won’t fit the mobile version. The problem with this approach is that old versions of IE will display the mobile version, as they don’t understand media queries without including something like respond.js.

I have not been following the ‘mobile first’ approach on the projects I’ve been involved in due to the IE factor. I have instead been starting with the full width version (keeping in mind how it will respond for narrow screens) and adding media queries where required to adjust the layout for a given breakpoint:


/* All */
.main .module   { float: left; width: 33.333%; }

/* 600 and down */
@media screen and (max-width:600px) {
  .main .module { float: none; width: auto; }
}

The design process becomes an interesting one, do you show the client a full width mockup, mobile, or both? Or should this be done at the wire-framing stage? I went with showing the client a full width mockup and just keeping in the back my mind how it would respond.

I am keen to try the ‘mobile first’ approach, however I will attempt this first on a personal project so that I can nail the workflow before unleashing it on a client project.

As an aside, the css and media queries for ‘mobile first’ would look something like this:


/* Mobile */
.main .module     { }

/* 600 and up */
@media screen and (min-width:600px) {
  .main .module   { float: left; width: 33.333%; }
}

So there we have it, my notes from the trenches of responsive design.

Pow, meet rbenv

I just ran into a problem with Pow when using rbenv for Ruby version management whereby Rails apps were not launching properly, giving the the following error message:

Error starting application
Your Rack app raised an exception when Pow tried to run it.

Bundler::GemNotFound: Could not find ??? in any of the sources

Turns out that Pow doesn’t know anything about rbenv unless you tell it. Thomas Fuchs tweeted a solution, suggesting that you just add the following to a ~/.powconfig file:

export PATH="/Users/username/.rbenv/shims:/Users/username/.rbenv/bin:$PATH"

Kill off your Pow process (I use the Powder gem for this i.e. powder down && powder up) and all should work just fine.

I personally prefer the solution mentioned in this related Github ticket as is saves having to hardcode your home directory:

export PATH=$(rbenv root)/shims:$(rbenv root)/bin:$PATH

Happy Pow’ing.