• readme.html
• wp-admin/about.php
• wp-admin/includes/update-core.php
• wp-admin/plugins.php
• wp-admin/press-this.php
• wp-admin/setup-config.php
• wp-comments-post.php
• wp-content/themes/twentyeleven/languages/twentyeleven.pot
• wp-content/themes/twentyten/languages/twentyten.pot
• wp-includes/formatting.php
• wp-includes/js/plupload/changelog.txt
• wp-includes/js/plupload/handlers.dev.js
• wp-includes/js/plupload/plupload.flash.js
• wp-includes/js/plupload/plupload.flash.swf
• wp-includes/js/plupload/plupload.html4.js
• wp-includes/js/plupload/plupload.html5.js
• wp-includes/js/plupload/plupload.js
• wp-includes/js/plupload/plupload.silverlight.js
• wp-includes/js/plupload/plupload.silverlight.xap
• wp-includes/js/swfobject.js
• wp-includes/js/swfupload/swfupload.swf
• wp-includes/kses.php
• wp-includes/ms-functions.php
• wp-includes/script-loader.php
• wp-includes/user.php
• wp-includes/version.php
• wp-includes/wp-db.php

With the rise of touch screens I have been trying to avoid anything that relies on mouse hovering. A few months back I wrote a pull-down menu. Yesterday I went back through the code to tidy it a bit and sort out some accessibility tweaks. The script injects toggles in menu items that have sublists, allowing for easier navigation. If the user has JavaScript disabled the menu reverts back to a standard CSS dropdown.

Improvements

• The toggles are now buttons rather than spans.
• The toggles are injected after the list item title and before its sublist, this allows for better tab navigation.

You can see a demo here. The sourcecode is available on GitHub.

Usage

To use in modern browsers:
.translucent-background(255,0,0,0.25);

For IE8:
.translucent-background(255,0,0,0.25,ie8);

For IE7:
.translucent-background(255,0,0,0.25,ie7);

The code

.translucent-background (@r, @g, @b, @alpha, @next: all) {
	@hex-r: ~`(parseInt("@{r}").toString(16)).length < 2 ? parseInt("@{r}").toString(16)+parseInt("@{r}").toString(16) : parseInt("@{r}").toString(16)`;
	@hex-g: ~`(parseInt("@{g}").toString(16)).length < 2 ? parseInt("@{g}").toString(16)+parseInt("@{g}").toString(16) : parseInt("@{g}").toString(16)`;
	@hex-b: ~`(parseInt("@{b}").toString(16)).length < 2 ? parseInt("@{b}").toString(16)+parseInt("@{b}").toString(16) : parseInt("@{b}").toString(16)`;
	@hex: ~`"@{hex-r}@{hex-g}@{hex-b}"`;
	.set-alpha(@next, @hex, @alpha);
}
.set-alpha (all, @hex, @alpha) {
	@hex-hash: ~`"#@{hex}"`;
	background: @hex-hash;
	background: rgba(@r, @g, @b, @alpha);
}
.set-alpha (ie8, @hex, @alpha) {
	@alphahex: `Math.floor("@{alpha}" * 255).toString(16)`;
	background: transparent;
	-ms-filter: ~'"progid:DXImageTransform.Microsoft.gradient(startColorstr=#@{alphahex}@{hex}, endColorstr=#@{alphahex}@{hex})"';
}
.set-alpha (ie7, @hex, @alpha) {
	@alphahex: `Math.floor("@{alpha}" * 255).toString(16)`;
	background: transparent;
	filter: ~"progid:DXImageTransform.Microsoft.gradient(startColorstr=#@{alphahex}@{hex}, endColorstr=#@{alphahex}@{hex})";
}

Responsive design

Right from the start I knew I wanted to build a responsive site. I’d spent quite a bit of time researching RWD but until now hadn’t had the opportunity to put some of the things I’d learnt into practice. I’d looked at a number of responsive grid systems but a lot of them suffered from a couple of flaws: they didn’t do nested columns, and floating columns sized in percentages suffered from a rounding down of their size in Webkit browsers. The more columns that were floated the worse it got, leaving the right hand edge of the page looking ragged. Looking to get around this problem I found Chris Planeta’s Negative Grid used a method of setting a 100% negative right margin, then setting the left margin to push columns out from the left hand side of the page. This reduces the rounding as you’re not compounding the rounding errors from all the columns set previously in the row.

Armed with this knowledge I set about creating my own responsive grid system with nested columns using {Less}. The structure was made up of 12 column spaces, I then had mixins that set the column width using multiples of 1/12 and the same setting the offsets. So, if I wanted a half-width column on the right side of the page I simply added .col-offset(6,6) into my .less file. Using this method I was able to set up different column layouts for full screen, portrait tablets, and mobile screen widths.

CSS media queries are only a part of the responsive setup however, they only serve to push existing content around the page. It’s a waste of bandwidth to be loading large images on a mobile device, to prevent this you have to go back to the HTML itself.

Server-side responsive prep

Ideally, we’d be able to detect someone’s connection type to determine whether they’re using broadband, 3G, or (yuck) GPRS. A visitor to the site could be using an iPhone, sitting on the couch watching CSI. Similarly the laptop user might be surfing on a 3G dongle with a patchy signal. Which one is the mobile user? Unfortunately the only way to detect bandwidth has a nasty side-effect of using a lot of the stuff, somewhat counterproductive. This leaves us with looking at device types. I know detecting capabilities is generally thought to be better practice but I found I ran into problems with this method. It’s something I plan to revisit nonetheless.

My detection script puts visitors into one of four groups: computers (this is the default), tablets, advanced mobiles (iPhones, Androids, etc) and normal mobiles (old Nokias, Opera Mini, etc). Computers and tablets get the full monty, large images, all the JavaScript and fonts. The one difference is I give tablets more padding on buttons and links, and computers get the IE CSS fixes. Advanced mobiles get smaller images and only some of the JS. They also get a header menu and search box hidden behind some toggle buttons, this reduces the height of the header meaning there’s less scrolling to get to the content. Normal mobiles get a basic stylesheet and few images. For an example of this try looking at a portfolio page on a computer with the browser window narrowed, you’ll see three thumbnails and a large image, this page loaded on a phone will only initially display the three thumbnails, cutting down on using up bandwidth.

Icons

Early on in the design process I decided I wanted to use icons. I’d toyed with the idea of making a dingbats style font before so when I started reading about various projects offering symbol fonts I guessed I was on the right track. A nice side effect of storing all the icons in a font file is it’s only one http request, compared to one per icon. Being vectors means they’re nice and scalable too and look as crisp on an iPhone screen as they do blown up on a computer. I used TypeTool to create the TTF font, then ran it through an online converter to generate the various formats needed to cover most web browsers. The icons are in use on the menu, the mobile toggles (viewable if you resize your browser window to a narrow size) and the Twitter and LinkedIn icons in the footer.

That pretty much covers the responsive / new methods I’ve used in building this site.

1. Control-click on the Espresso.app icon and click Show Package Contents.
2. Go to Contents > SharedSupport > Sugars and copy the CSS.sugar file to ~/Library/Application Support/Espresso/Sugars/.
3. Open this new copy of the CSS.sugar folder, open the Languages.xml file and find the line <extension>css</extension>.
4. Under this line add a new line like this: <extension>less</extension>.
5. Save the file and launch Espresso, you should now see colourised .less files.

Seriously? It looks like a prop from a Doug McClure movie.

Today was my final day at Oxeye Daisy. I worked there for a little over four years. During those years I had the opportunity to learn jQuery, the ins-and-outs of WordPress, and some basic server management in the course of building a wide variety of websites. It is perhaps fitting that the first WordPress website I built was the Oxeye Daisy site in 2007 and today we put the finishing touches to a new version of the site, also based on WordPress. It was a great place to work, I will miss it.

By default the location of Lighttpd’s www folder is /private/var/www. You need to add an alias to this folder into either Textastic‘s or Koder‘s documents folder. The apps are usually located somewhere like this: /private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX, all those Xs would be a unique alphanumeric string.

The easiest way on a mac to find the location of the application path is to use Transmit. Log into your iPad, go to /private/var/mobile/Applications, select all the files and folders, then hit the right cursor key, this will expand all of the folders (it will take longer the more apps you have installed). You can then find the Textastic or Koder application location by typing their names.

Once you have the location of the app, log into your iPad via SSH and navigate to the app’s document folder, for Textastic it would be:
cd /private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/Documents

For Koder:
cd /private/var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/Documents/Project

You need to create an alias to the web servers www folder, type:
ln -s /private/var/www ipadwww

Finally, you need to set the /private/var/www permissions to 777 to allow the apps to save to this folder:
cd /private/var
chmod 777 www

Now open either Textastic or Koder, you should see a new folder called ipadwww.