When authoring HTML, if you find yourself writing an <input> element, chances are that you are going to need to label it. The proper way to label an <input> element is by using a <label> element. I don’t know how many times I’ve seen web developers omit this tag. Start using it. It aids in the accessibility of your site.

The main component of the <label> element is its for attribute. The value of the for attribute is the id of a form element. Form elements can be one of <input>, <select>, <textarea>, or <button>. The for attribute can be omitted if the <label> element surrounds the form element.

The only issue that I have with omitting the for attribute is in Internet Explorer 6 in which clicking the label will not activate the form element. I don’t have too many customers that still use IE6, so I omit the attribute depending on my customer. The W3 at one time did consider the omission of a <label> element’s for attribute a failure criterion in accessibility, due to a lack of its interface control being determined programatically, but I do not believe that this is still the case.

See below for an example of labels in use. Hint: click on the label, and not the checkbox.

I wanted to set up mutt to check my Gmail over IMAP. Mutt is a highly configurable TUI email client. Since it is so configurable and I am already conditioned to using Gmail’s keyboard shortcuts, I have decided to share my mutt configuration to emulate Gmail.

A couple of months ago, Fog Creek came out with WebPutty, a “simple CSS editing and hosting service.” It is a fantastic tool which hosts CSS files for me. This feature in itself is not that special, but what does make this service awesome is that it lets me write my styles in SCSS and it also has a pretty slick interface for letting me see style changes on the fly. I was loving it, but then I ran into a stumbling block, which I’ll get to in a bit.

Respond.js

I’ve been experimenting with responsive web design for a little bit now. To aid me in accomplishing this with older deficient Internet Explorer browsers, I turned to Respond.js. Respond.js will parse all of a web page’s CSS styles and emulate the supported media queries it finds with JavaScript to the best of its abilities.

To be able to retrieve the external CSS files, Respond.js performs an Ajax request. Since Ajax has a same origin policy, Respond.js cannot access stylesheets that are stored externally on a separate domain, such as webputty.net. Respond.js does have a solution for this: a proxy HTML file that must be on the external site hosting the CSS. I asked the guys at Fog Creek to implement this, and they have so kindly obliged.

WebPutty Responds

From: “Dane Bertram”
Date: Oct 5, 2011 4:05 PM
Subject: Re: (Case FC2120156) [webputty] Respond.js
To: “Kaleb Hornsby”

Hi Kaleb,

I just wanted to touch base quickly to let you know that we’ve added the Respond.js proxy to WebPutty and that you’re welcome to start using it now.

We’re still working on adding documentation, but for the time being, you can use the following to get Respond.js working with WebPutty (provided you’ve already got respond.proxy.gif and respond.proxy.js already on your own server):

<link id="respond-proxy" rel="respond-proxy"
  href="http://www.webputty.net/respond-proxy.html" />
<link id="respond-redirect" rel="respond-redirect"
  href="respond.proxy.gif" />
<script src="respond.proxy.js"></script>

We don’t have the proxy working in the editor just yet though, so if you’re trying to test your media queries in older versions of IE, you’ll have to visit your website directly (rather than via the preview pane in WebPutty’s editor).

Let me know if I can be of further assistance, if indeed this was helpful, or if this raises any other questions.

All the best,
Dane

For six months now, I have been a bad person. Love can make a person do funny things: to make compromises, to re-evaluate one’s own principles. In my case, it was the love of my Cr-48. It is sleek and lightweight, simple and not fancy. I do not ask for much and in return it gave me the two things I really ever needed in a laptop operating system: a web browser and SSH.

As attractive as the Cr-48 is, it blinded me to a major flaw in its SSH client. It lacked any and all support for SSH keys. I overlooked this flaw and made a compromise; I decided to allow password authentication on my home server, exposing my poor little machine to the evils that lurk in the dark corners of the internet. Fear not, I have since re-disabled passwords. I would like to say that it was because I learned my lesson and repented from my slovenly ways, but I am not disabling password authentication because it is the right thing to do. It is rather that Chrome OS now supports SSH keys.

SSH key support has been available in Chrome OS since at least before May, but it was not until today that I noticed it. There is no SSH agent, and the syntax to use a key while connecting to a host is a little annoying, but these are some freedoms I am willing to give up for security.

From crosh, the Chrome OS terminal, this is how I discovered the ability to use SSH keys:

crosh> ssh
ssh> help
connect                       - connect
dynamic-forward port          - dynamic socks proxy (-D)
forward port:host:port        - static port forward (-L)
help                          - this
host <hostname>               - remote hostname
key <file>                    - sets private key to use (-i)
nocmd                         - don't execute command (-N)
port <num>                    - port on remote host (-p)
exit                          - exit ssh subsystem
user <username>               - username on remote host
Note that this program can only bind local ports in the range
8000-8999, inclusive.
ssh> key
File '' is not a valid key file. Key files must reside
under /media or /home/chronos/user. Key files in the Downloads directory may
be specified with an unqualified name.

The next few sections will be a step by step setup guide for using keys on SSH.

Generate a Public/Private Key Pair

I generated the keys on my home server. Your syntax may vary.

$ ssh-keygen -f vinz-clortho
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in vinz-clortho.
Your public key has been saved in vinz-clortho.pub.
The key fingerprint is:
01:23:45:67:89:ab:cd:ef:fe:dc:ba:98:76:54:32:10 zuul@example
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|        o . .E  .|
|       . = .o..+.|
|        S .. oo++|
|         .   .*.=|
|             oo.*|
|               o=|
|                o|
+-----------------+

Add Public Key to Server

After the keys are generated, the public key needs to be appended to the SSH authorized keys listing.

$ cat vinz-clortho.pub >> ~/.ssh/authorized_keys

Add Private Key to Chromebook

I copied the public and private keys from my SD Card to my Downloads directory. To open up the file browser, hit ctrl + m.

Establish SSH Connection

Even though the SSH help mentions a -i option, I cannot seem to get it to work, and I am stuck with the following syntax:

crosh> ssh
ssh> host example.com
ssh> user zuul
ssh> key vinz-clortho
ssh> connect
Enter passphrase for key '/home/chronos/user/.ssh/key-123...abc':

Shut Off Password Authentication

Finally, lets secure this sucker.

$ sudoedit /etc/ssh/sshd_config

Set “PasswordAuthentication no”.

$ sudo reload ssh

(Secure Shell Public/Private Key Pairs)

ChromeOS recently updated and added some new features. One of them was an unexpected addition, and the other was something that I’ve been waiting for since the defect was marked as resolved.

Split Windows

When ChromeOS first released, the only way to view a web page was to view it maximized. This was somewhat problematic if one wanted to view two pages side by side, e.g. writing a paper in Google Docs and viewing a work to cite at the same time. Panelize is a Chrome extension that made this process a bit more bearable. It has an option that the user to open the current tab as a docked mini page. The problem with this is that mini pages always obscured at least part of the underlying page.

Despite what may be evident at first, ChromeOS is not just a web browser. It has another useful application as well: a terminal. To open the terminal, all the user has to do is hit the familiar ctrl + alt + t. This terminal does not have many features, as it is not a fully functional shell. The most useful tool that it does have is SSH, and I use it often. The terminal has some of the same multi-tasking hinderences as the browser: the inability to view multiple windows at once; the terminal is always full screen.

The latest update that I recieved as of this writing fixed this issue. Windows can now be split vertically. Now when a new browser is created or when a terminal is opened, the new windows are no longer full screen by default. The user can now drag to the left or right the width of the window allowing two windows—whether it be a browser or terminal—to be viewed at the same time. It’s a boon to productivity. In the upper right hand corner of the browser windows there is now a maximize button so that the user may quickly maximize a window. Another change made was the functionality of one of the function keys. What used to be a button dedicated to switching windows—exactly the same functionality of alt + tab—is now used to maximize windows from the keyboard. If you want to be able to resize your windows with the keyboard, there’s keyboard shortcuts for that.

Keyboard Shortcuts

If the user hits ctrl + alt + > or ctrl + alt + < , the window will resize to the left or to the right respectively. Chrome has many other useful keyboard shortcuts such as taking screenshots or changing input language. By hitting ctrl + alt + / the user can view all the keyboard shortcuts in ChromeOS.

Killing SSH Sessions

One of the biggest issues that I had with ChromeOS was the inability to depart a hung SSH session. When logged into an SSH session and the connection drops, the terminal would stay open with no method of closing it. ChromeOS disables the standard the standard tilde commands for security reasons, so that route does not work to kill or reconnect the session. The only recourse that I had was to either open a new terminal window and ignore the hung window or if I really wanted the hung sessions gone, I would have to log out and log back in. Now, it is a simple shift + ctrl + w, just like in gnome-terminal.