I’ve spent the last week working on some initial ideas on and off and you can see the fruits of my labour at http://fakedarren.github.com (preferably on an iPhone, and definitely in a webkit browser).

I’ve got some basic styles down, with not one image in sight so far (CSS3 is amazing), and the most interesting thing so far is extending my friend’s existing Touch class with Gesture support. I can now add events to elements such as ’swipe left’ and ‘pinch’ – pretty damn cool. I want to make this very important part of the toolkit rock-solid and a joy to use, so how far it has come in such a short time is really encouraging.

Over the coming weeks I’ll be completing the HTML templates – forms need a lot of work, for instance – and I want to get a really solid set of templates and easy-to-manage CSS so theming is a cinch.

Once that is done, I’ll push on into getting animations between pages done; sliding, flipping, rotating, fading etc. That’ll keep me busy for the foreseeable future but there are a lot of other things I want to be able to support in the final version.

Check it out on your iPhones or fork it on github and let me know what features you’d like to see!

This will be incredibly useful. As we add more and more JavaScript and rich media to web pages, performance is affected. One easy way we can mitigate the effect this has is to leverage the power of CSS to reduce the number of background images we use; for instance for rounded corners and gradients. Border-radius is still not implemented in IE (rumoured to be included in IE12 when it’s out in 2043) but gradients are, and we should all start using them now.

Example

Here’s a real-life example. This is just a link; this style can be applied to any element; <button>, <input type=”submit”>. <a>, whatever.

I’m a button

Dependent on what browser you are using, it will look different.

How it looks cross-browser

Firefox 3.5

Firefox 3.6

Internet Explorer

Safari and Chrome

The CSS

.sexybutton {
  background: #DEDEDE;
  background: -moz-linear-gradient(top, #FFF, #888);
  background: -webkit-gradient(linear, left top, left bottom, from(#FFF), to(#888));
  border: 1px solid #D6D6D6;
  color: #666;
  display: inline-block;
  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#FFFFFF', EndColorStr='#888888');
  font: bold 1.3em/22px Helvetica, Arial, sans-serif;
  height: 22px;
  padding: 0 10px;
  text-decoration: none;
  text-shadow: 0 1px 0 #FFF;
  -moz-border-radius: 5px;
  -webkit-border-radius: 5px;
}
.sexybutton:HOVER {
  background: #BEBEBE;
  background: -moz-linear-gradient(top, #DDD, #666);
  background: -webkit-gradient(linear, left top, left bottom, from(#DDD), to(#666));
  border: 1px solid #B6B6B6;
  color: #444;
  filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#DDDDDD', EndColorStr='#666666');
  text-shadow: 0 1px 0 #DDD;
}

Summary

I’m absolutely convinced that using CSS gradients is now viable. Gradients do make a difference, when used well, to the aesthetic of a webpage – more so, in my opinion, than a few pixels of rounded corner.

I’m also convinced that as we put more and more JavaScript onto our pages the performance hit of making a design work perfectly in all browsers gets less and less preference. We need to start leveraging CSS effects wherever possible; it is not fair to a user to have to wait for 100k of gradient images (and the extra HTML required) for something that can be represented by much less CSS.

I love this way of rendering gradients and will definitely be using it in my future work.

Some links

• Safari gradients
• Firefox gradients
• Internet Explorer gradients

Setting up the Virtual Machine

The first thing to do is go ahead and set up Windows in a Virtual Machine exactly as you would normally. I would recommend installing XP over Windows 7 because it will have a smaller footprint, and you don’t really need to ‘use’ it, just run it in the background.

If you’re tempted by IIS7’s ability to run multiple sites (something you cannot do with XP by default), I recommend IISAdmin.NET; this handy utility allows you to switch between multiple sites with IIS5.

There is one required setting, and that is that the Virtual Machine’s network connection is bridged, not using NAT. This will allow us to assign the Virtual Machine a static IP, which is vital if we’re to make working in OSX painless.

Sharing files between the two

The other choice you have to make is whether or not you want to share your OSX files. I’ve not bothered because I’m going to share the other way round – writing to the VM’s hard disk, instead of reading them from the Mac in Windows. Mac shares are seen by Windows as a network drive and IIS has some serious issues with these.

I have multiple sites running, and I stick them all in C:\Projects. If you’re just running with defaults and a single site, they’ll be in C:\Inetpub\wwwroot. Navigate to these folders in Windows Explorer and right-click. Choose ’sharing and security’ and set this folder to be shared and allow other users to edit these files. Give the share a sensible name like ‘Server‘ or ‘Projects‘.

Check your VM is all set up

You should now be able to

• Access the Internet in the VM
• Run your site in the VM as localhost
• Ping your VM’s IP from terminal (type ping x.x.x.x in Terminal, where x.x.x.x is the static IP assigned to the VM)
• The folder you store your site files in should be shared (depicted by a hand holding the folder icon)

As your VM has a static IP, it is connected to the internet; so I wouldn’t recommend completely disabling any firewall. You will need to configure your firewall to allow you to be able to access your VM from the Mac, but as there are so many different possibilities I can’t go into details here.

Viewing your ‘local’ site in OSX

You should now be able to access your site running under IIS in the virtual machine in OSX. Open a browser and go to the IP address you assigned the the VM. You should see the .NET site running.

Now we’ll map this IP address to a nice name; so I can access this site as http://dev/ or similar. Open your text editor of choice and go to the ‘Open’ dialogue (⌘-O) and then type ⌘-shift-G to open the ‘Go to folder’ dialogue. Type ‘/etc/‘ and open the ‘hosts’ file. Add your ‘nice’ name and the IP you assigned, save, close.

Viewing your ‘local’ site files in OSX

Open finder and hit ⌘-K. This brings up the ‘Connect to Server‘ dialogue. I mapped the host name ‘mvc‘ to my VM’s IP address, and shared my files as ‘Projects‘; so I will connect to ‘smb://mvc/Projects‘.

The username and password you connect as should have not affect anything; you can connect as a guest if you so wish. Anyway, you should now be able to view and edit your .NET site in OSX!

I’m loving it

I’ve only had a few weeks with this setup but I can confirm I am nothing short of delighted with it. I currently am in love with Coda and TextMate. Coda seems to have the best ‘out of the box’ syntax highlighting for .NET / C# code, and that’s why I use it.

I’m also going to look into auto-mounting the shares but because I use my job for three ‘jobs’ (Abacus, GigJunkie and MooTools) this isn’t really practical. I also foresee some potential problems with source control and permissions; but I’ll tackle these issues as and when they come around.

Hopefully this post was of vague interest and help to some of you looking to achieve the same. It works well for me and I hope it works well for you too.

I’ve recently been working on the upgrade layer for MooTools, that allows users of MooTools 1.1 to easily upgrade to the latest version of our favourite framework. If you have a complex site, the following may not be relevant, but hopefully following the steps below will help the majority of users to update their code.

This isn’t a complete guide – but these are the steps I would take. Make sure you read through the readme first; there are a few breaking changes and subtle API differences. But for simple sites, the following should work.

Element getters and setters

One frequently used part of the API from 1.1 was Element setters and getters. Previously, you had methods such as $(el).getValue(val) and $(el).setText(text). These changed to $(el).set(’value’, val) and $(el).set(’text’, text). This is a quite simple change and a good one to start with. The complete list of methods that need to change:

• getText() and setText()
• getHTML() and setHTML()
• getTag()
• getValue()
• setOpacity()

Simple Fx

This is another relatively simple change to make, and again, commonly used. To upgrade is a case of:

• Fx.Base becomes Fx
• Fx.Style becomes Fx.Tween (with some differences, see readme)
• Fx.Styles becomes Fx.Morph
• el.effect() becomes el.tween(), and el.effects() becomes el.morph() (again some subtle differences, see readme)

Selectors

Next up is replacing $E and $ES.

• $E(selector) becomes document.getElement(selector)
• $ES(selector) becomes document.getElements(selector)

There was also a second optional parameter you could pass in that defined what element you wanted to search in. An example:

• $E(selector, ‘.myDivs’) would become $$(’.myDivs’).getElement(selector) or
• $E(selector, ‘#myOtherDiv’) would become $(’myOtherDiv).getElement(selector)

Ajax requests

Last of the common changes to be made is to the MooTools 1.1 Ajax and XHR classes. These need to be replaced with Request. Have a look at the readme for exact changes.

Fx methods

We updated a few Fx methods earlier, now let’s just finish the job. The following changes should be made:

• myFx.custom() has been changed to myFx.start()
• myFx.clearTimer() and myFx.stop() can both now be written as myFx.cancel()

If you follow the above steps most of your code should be good to go. If you need any further help just jump on IRC and someone should be there to help. Also, please check the docs for 1.1 and 1.2 to check you are passing the correct arguments.

We will also be working closely with the Joomla! dev team to convert the most popular plugins for you. Once these are done, we’ll be putting them in the Forge. You can request conversions in the MooTools Google Group but we can’t convert everything -so please don’t be offended if we don’t convert your favourite plugin.

Please read the original post on the MooTools blog for more details – and have fun upgrading!

My home setup

My work setup

I think it’s frikkin’ cool!

We had something similar in San Francisco a couple of months ago which I also had the pleasure of attending. I mentioned that the guys from Europe should have one, suggested London as a venue and now here we are. The awesome company I’m working for at the moment have let us use their Regent Street office for the event and I cannot express how grateful I am about that.

We’re going to have quite a high turnout – about 15 of us I think – and for a lot of us it’s going to be the first time we’ve all met up. The San Francisco one and this one have and will really help the MooTools dev team get closer. Working with people in your spare time in different countries can sometimes be difficult and I think everyone meeting face to face is going to really have a positive impact on how we work together.

Follow the @MooTools Twitter feed for regular updates on what’s going on; we’ll have live video chat if people want to chip in and give us a hand with what we’re working on. I can’t promise (we may be busy coding!) but hopefully we’ll get a chance to go out for a drink or two and if any MooTools users are around in London you can come and meet the devs. We’ll tweet the details if that happens.

Also early next year, I hope to organise a more public event, for users as well as devs; we’ll be discussing this over the weekend. I’m hoping to get a sponsored bar and a couple of the devs over to do a couple of talks about our favourite JavaScript framework.

Totally looking forward to it. It’s going to be amazing

I currently work at an awesome company called Abacus E-Media and I enjoy it, I really do; but recently I’ve been getting more and more involved with open source projects like MooTools and I get so busy at Abacus I really don’t get time to contribute.

Next year though, I get to go (hopefully) down to a part-time contract; this gives me 2 days a (working) week to do something that pushes my skills that bit more; to do things that are closer to the ‘bleeding edge’; it’s really exciting for me. I’ve got a lot of options and I’m excited by all of them.

First of all I want to continue the great work we’re doing at Abacus. I’d love to help on the next iteration of their CMS which could turn out to be something quite special.

I also have a burning desire to finish my CMS, ‘Excalibur’. WYSIWYG content editing in the purest form. I also hope to release the codebase as open source, and also hope to be able to provide some demos / examples in the real near future.

I also have an opportunity at GigJunkie that I’m super-excited about; I really think I can help them with their front end and it sounds like they have their head screwed on with regards to how they want to take their site forward. I’m intrigued, and would love to be involved.

Last of all…..MooTools. Goddamn. Next weekend I get to host a hackathon for some of the best JS developers in the world – more about that next weekend – but I think the MooTools project has everything it needs to really be a success in 2010. So many awesome, passionate developers; a very solid codebase; so many ways it can grow.

We have so much awesome just waiting to be unleashed. Server-side implementations, a brand new and stupidly good selector engine (Slick), the new Class system; that’s without the massive improvements to our community, demos and tutorials.

Basically – 2010, regardless of what the Chinese calendar tells you, is the year of the Moo. And I for one am looking forward to it loads.

So I made this little demo thingy and thought I’d see what people thought of it.

How it works

First off I separate each ’slide’ with a <div class=”section”>. I’m also using <pre> tags and the excellent Lighter.js for code highlighting.

I then have a small class that lets you navigate through the ’slides’. Each time a slide is shown, the HTML, CSS and JavaScript are injected into an iframe (which I called a ’stage’) and you can show the stage by adding a class of ’showstage’ to the section.

The code is really messy at the moment but it is more of a proof-of-concept than a finished class. I’ll definitely clean it up, and I may in time make it into a WordPress plugin – I’d also love it to be easily used with MooShell.

Anyway, have a play and tell me what you think!

A demo of the demo thingy

.box {
	height: 100px;
	position: absolute;
	width: 100px;
}
#box1 {
	background-color: #222;
	border: 1px solid #ccc;
	left: 20px;
	top: 40px;
}
#box2 {
	background-color: #94CC25;
	border: 1px solid #222;
	left: 450px;
	top: -3px;
}

run script 1 | run script 2

$('runscript1').addEvent('click', function(e){
	e.stop();
	$('box1').tween('background-color', '#f00');
	$('box2').tween('opacity', 0.7);
});

$('runscript2').addEvent('click', function(e){
	e.stop();
	$('box1').tween('top', 50);
	$('box2').tween('left', 300);
});

run script

$('runscript').addEvent('click', function(e){
	e.stop();
	$('box1').morph({
		'background-color': '#00f',
		'left': 400,
		'top': 15
	});
	$('box2').morph({
		'background-color': '#ff0',
		'border-color': '#94cc25',
		'border-width': 12,
		'left': 30,
		'top': 5
	});
});

run script

$('runscript').addEvent('click', function(e){
	e.stop();
	$('box1').set('morph', {
		duration: 'long',
		link: 'chain',
		transition: 'bounce:out'
	});
	$('box1').morph({
		'background-color': '#00f',
		'left': 400,
		'top': 15
	}).morph({
		'background-color': '#ff0',
		'border-color': '#94cc25',
		'border-width': 12,
		'left': 30,
		'top': 5
	});
});

fade in | fade out | toggle fade | fade to 0.5
 |
highlight | highlight red

$('fadein').addEvent('click', function(){
	$('box1').fade('in');
});
$('fadeout').addEvent('click', function(){
	$('box1').fade('out');
});
$('fadetoggle').addEvent('click', function(){
	$('box1').fade('toggle');
});
$('fadehalf').addEvent('click', function(){
	$('box1').fade(0.5);
});

$('highlight').addEvent('click', function(){
	$('box2').highlight();
});
$('highlightred').addEvent('click', function(){
	$('box2').highlight('#ff0000');
});
$$('A').addEvent('click', function(e){
	e.stop();
});

We all kind of agree on how we structure our HTML – in a way that is semantically sound, and accessible – but one thing I’ve noticed is how different my views on how I structure my CSS are compared to my colleagues. I thought I’d explain myself, and hope to gain some insight into what others think about my style, given my reasons for choosing it.

I always capitalise my tags

I can’t actually remember when I started doing this – I guess it was right from the start – but I always capitalise any HTML element in my CSS. For instance:

DIV LI.selected A

I do this because I really believe it’s more readable. IDs are very recognisable because of the # sign – classes, when quickly scanning CSS, are less easy to spot, because the period isn’t the most noticeable of characters. By capitalising my tag names, I can easily differentiate between IDs, tags, and classes.

I always order my properties alphabetically

When I mention this I normally get accused of having horrific OCD, which is probably quite true; a lot of people prefer to group properties by type; as in, top, left, right or border, padding, margin.

My argument for this is that if you order alphabetically you eliminate two possible problems; first of all, duplicates (however unlikely); second of all, gotchas like specifying a font rule after a line height. Compound properties (like font, background etc) implicitly include other rules in them. The main one – font declaration implicitly includes line-height.

line-height: 16px;
font: 1.2em Helvetica, Arial, sans-serif;

In the above example, the line-height declaration means nothing. It is overriden by the font declaration. Ordering alphabetically eliminates this as a potential problem.

It also means when I’m looking quickly for something I know whether to look at the beginning or end of a set of properties.

Single-line declarations FTL

This is something that me and some of my colleagues can agree to disagree on. I HATE single line declarations. I find them so unreadable. One of my first experiences with single-line CSS was this horror show of a 2,000 line stylesheet – each one on a single line. First off – no way should you have 2,000 lines of CSS in one file – but the single line format killed me.

5 or so years ago this could have been considered best practice, given the prevalence of dial-up.  Now with broadband, whilst abusing a user’s connection is not encouraged, it’s not so much of a problem. The extra line breaks aren’t going to add up to much in terms of file size – so do yourself a favour and put your properties on separate lines.

It’s worth noting that whenever you see a ‘CSS formatter’ (like this one) if you format it as ‘readable’ then it takes the multi-line approach. Single-line declarations are rubbish.

Also the argument that it’s harder to find a rule if you don’t put them all on one line is, in my eyes, invalid – Firebug tells me exactly what line it’s on.

I put IE specific hacks in separate stylesheets

Again, I find it extremely annoying when people put IE hacks in the stylesheets. They should be separate. I have a whole blog post in the works dedicated to IE hacks so I won’t go into any details here

I indent my CSS to show when a declaration is a child of another

UL {
  list-style: none;
  margin: 0;
  padding: 0;
}
    UL LI  {
      color: #CCC;
    }

By doing this I can clearly see what rules belong to what definition – again I chalk this down as personal preference but I find indenting like this to be much more readable.

Use the server to compile your CSS – then break it up into chunks

If you are working on a site that has so much CSS that it’s a performance problem to have lots of small, manageable CSS files, you need to invest the time on building something that collates and compresses them for you. This is NEVER an excuse to not break your CSS up into small manageable chunks, but rather a failure to use the tools you have to make something manageable and maintainable.

I’ll definitely be doing some posts in the future about this subject with simple C# and PHP examples.

That’s how I do it – what about you?

That’s how and why I structure my CSS like I do. I find that having a structure for CSS is something that a lot of people don’t do – it’s often an afterthought for a lot of Front End developers I know. I’d love to know what you think of my eccentric CSS-based behaviour and what works well for you.

I’ve been meaning to for absolutely ages, just never got round to it. But recently I’ve been getting more and more annoyed with myself for not taking the time to do so.

Hopefully, the content on this here blog will be of interest to people. I’ve got grand plans – how well they are executed remains to be seen – but basically I hope to be able to write a ton of awesome articles about the various tricks I’ve learnt over the years. I’ll mainly be covering MooTools, CSS, C# and PHP, with the odd sprinkling of HTML5, accessibility, ActionScript and hell, maybe even some jQuery.

And goddamn am I looking forward to it!