By dropping the save/restore and alpha blending features, I was able to come up with a few candidates which I think look fairly pretty.

Unlike my previous allRGB and rot13 entries, where I had a definite goal in mind, here I’m really just playing with parameters until something cool appears on the screen. Which is kinda neat, it recaptures that innocent experimental spirit which was what first attracted me to programming when I was a kid.

Stained Glass (140b). A stained glass window, ever expanding and becoming more intricate. There’s a nice ‘grayscale’ effect due to anti-aliasing and the fact that we’re drawing over some lines at slight offsets, making them thicker and so appearing darker. I started off using ‘with’ in the code like @strager, but actually found I saved bytes without it, because setInterval code is executed in the global scope but we need to do the translate outside setInterval- it’s more succinct to just say ‘d.’ everywhere.

h=60,d=document.body.children[0];d.height*=h;d=d.getContext('2d');d.translate(h,h),setInterval("d.strokeRect(9,9,h/2,h++/2),d.rotate(90)",9)

Exploding Web (139b). This one starts as a spirograph then quickly destablises into a sunburst. But as soon as you think you know the pattern, a new one emerges – after running for a few seconds, you can suddenly see hints of beams of light seen through a forest. Or is it just a mess of lines? ;)

h=99,d=document.body.children[0];d.height*=h;d=d.getContext('2d');d.translate(h,h);setInterval("d.strokeRect(9,9,h/2+--h,h);d.rotate(h)",1)

Moonrise (140b). The interesting thing about all these demos is the way they evolve the longer they’re run. To me, this one really has depth. First it’s a new dawn with the sun shining, then the moon takes over and its light reflects over the waters of a rippling lake. As you scroll down the page, the lake transforms into an abstract network of shapes which have an inscrutible pattern.

h=99,d=document.body.children[0];d.height*=h;d=d.getContext('2d');d.translate(h,h),setInterval("d.strokeRect(10,9,h/3,h++/3),d.rotate(9)",2)

rot13 (138b). An entry which actually does something useful in under 140 bytes! Performs the rot13 substitution cipher on user input. Loops until you press cancel, at which point it quits with an error. Don’t think I can fix that in the 2 remaining bytes :( I’ve also written a ‘full’ version in 1000ish bytes, which I’ll tidy and submit later. Slap “javascript:” on the front and you’ve got a very handy bookmarklet :)

for(r=o='rot13';o=prompt(r,o).replace(/[a-z]/gi,function(c){return String.fromCharCode((n=c.charCodeAt()+13)>122||n<104&&n>90?n-26:n)}););

Blocks of colour (140b). This one I’d entered a few days ago as my first twitter sized entry. It’s 140 bytes including the #js1k hashtag, which is pretty funky. It’s similar to chrisfrancis27‘s ‘fence’ entry, and uses the colour randomising code from his entry. The “|0″ part performs type conversion, and seems to be required for Chrome.

r=Math.random;setInterval('with(document.body.children[0].getContext("2d"))fillStyle="#"+(1E6*r()|0),fillRect(r()*290,r()*99,9,9)',2)//#js1k

Cave of Evil (136b). Showing off three new features here, firstly a new way to access the canvas – most people so far are using document.body.children[0], but document.body.children.c is one byte shorter, which helps. Also, this demo sets the width and the height in one move: height=width*=h=9, which is pretty cool, and finally I’m using canvas’s globalAlpha property to create a really nice greyscale effect. Damn, this is addictive!
with(document.body.children.c)height=width*=h=9,c=getContext('2d'), c.globalAlpha=.008,setInterval("c.fillRect(0,0,h,h),c.rotate(h++)",1)

Update: Chrome doesn’t like globalAlpha’s <0.01, and Opera doesn't like <0.1, so I've updated the code.

with(document.body.children.c)height=width*=h=9,c=getContext(’2d’), c.globalAlpha=.1,setInterval(“c.fillRect(0,0,h,h),c.rotate(h++)”,5)

It's almost as pretty :)

For js1k, I’ve entered a port of my PHP allRGB entry. The allRGB project is a great idea in itself – create an image which contains every possible colour in the RGB space exactly once. That’s 256*256*256 colours (=16777216), in a 4096×4096 image. Quite a challenge for PHP, and certainly not the kind of thing you’d attempt in JavaScript, right? ;D

The code itself is pretty simple stuff – three nested for loops and you’re basically done. A few little tweaks to make sure it runs fairly smoothly in all browsers. Unlike the PHP version you can’t really just set and forget, so I’m using setTimeout to break the task down into smaller chunks, which means the browser won’t trigger its “This script is running slowly” message. I also use window.scroll to show the user that something’s actually happening on screen.

As I mentioned, this isn’t the kind of thing you’d normally turn to JavaScript for, and it puts quite a strain on the browser. It’s very interesting to see how the different browsers fare. Opera is the fastest, followed closely by Chome, then Firefox. Safari puts on a generally poor show, being slow and having some rendering problems while the drawing/scrolling is happening, but it does work in the end. It doesn’t run in IE 8 or 9, I’ll probably have a look at that at some point, it’s bound to be be something silly.

The final minified code comes in at 713 bytes. I could get that down further for sure, but there’s no need to just yet.

Check out the demo here.

Here’s the original source. Leave a comment if you can spot the IE errors :)

// declare shorthand vars
var o=document.body,c=o.children[0],w=4096,n=256,t=c.getContext("2d"),s=x=y=0;
 
// set canvas dimensions and background
c.width=c.height=w;c.style.background='#DDD';
 
// add a pretty description
h=document.createElement('p');
h.innerHTML='<p style="font-family:verdana;font-size:10pt;">All<b style="color:red;">R</b><b style="color:#0F0;">G</b><b style="color:blue;">B</b> entry in JS, in 719b. Rendering every RGB colour exactly once '+w+'x'+w+'px - '+(w*w)+' cols.</p>';
o.insertBefore(h,o.firstChild);
 
// draw function:
function d(){
  // draw the next few reds
  e=s+1;
  // draw full blue and green for each red
  for(r=s;r++<e;)for(g=0;g++<n;)for(b=0;b++<n;){
    // set the colour
    t.fillStyle="rgb("+r+","+g+","+b+")";
    // draw a pixel
    t.fillRect(x,y,1,1);
    // increment x and y if needed, and scroll the page so the user can see what's going on.
    if(++x>=w){x=0;y++;if(y>300 && y%5==0) {scroll(0,y-300);}}
  }
 
  // chunk the drawing so it doesn't cause a "this script is running slowly" message
  // this also prevents the browser from becoming completely non-responsive. You can still close the tab while it's running
  if(e<=n){s=e;setTimeout(d,1);} else alert('done');
}
 
// warn user
if(confirm('This will hang Safari til done. Run?')) d();

You can play with the final entry right here – http://10k.aneventapart.com/entry/details/243 – voting closes today so please be generous with your votes and comments. I’ve literally just now come back from holiday so I haven’t had a chance to badger everyone to vote yet. Go and vote! ;)

The idea’s been kicking around my head for a while: A desktop/bookmarking app with a google maps style interface. The general concept was that current approaches to bookmark management, navigation and retrieval focus on either tagging with keywords or hierarchical organisation into categories, but the idea of a “desktop” is a visual metaphor, and we tend to remember things better in visual and spatial terms. Also, with touch interfaces on the rise, reducing the keyboard’s role looked like a worthy goal.

So, ‘SkyTop’ is a mouse-navgiated landscape of icons which can be dragged, panned and zoomed. You can arrange clusters of similarly themed icons by dragging them closer together. In this way you can have all your work icons in one place, and when you’re done, zoom and pan across to your hobby icons. No need to type any tags or search through pages of bookmarks – just zoom right out and you’ll see where all your icons are. You’ll remember that you put google.com up to the right near the other search engines. I think it’s a powerful concept. I’m not sure I’ve pulled it off quite as perfectly as I’d have liked, but the basic interface is there and working in all major browsers, and for 10k I’m pretty happy.

In a future post I’ll do a technical write-up (lots of good stuff to talk about there!) and release the un-minified code, but for the moment just take a look over the app and let me know your thoughts on it. I think there’s definite room for improvement in the icon display, and I think having a background image which zooms and pans with the icons might help the user to understand the interface better. I’d love to hear what you think of the concept, and my implementation of it :0)

PS: Vote right now, then follow me on twitter.

One thing that is starting to change is the way we fundamentally approach javascript. Not simply the recent popularity of libraries such as jQuery, allowing us to literally “change the way we write javascript”, but also there’s now much more awareness of the power that javascript has, and we’re doing more mission-critical stuff with JS. We’re moving from favouring simple procedural snippets of javascript that add twinkles to the page to fully object oriented JS applications, exporting great swathes of functionality away from the servers and onto the client.

This is a great thing. In fact it’s little short of a miracle; the servers are running faster and so are the clients! There seems to be no trade-off; by deeply integrating JavaScript into our web applications we’ve gained speed at both ends!

Not quite though.

JavaScript uses garbage collection to keep the memory usage down – if a variable is never referenced again in the code, it can safely be deleted from memory, freeing the resources associated with it. But there are various techniques to automatic memory management, and there are some pitfalls. For example, a common way to determine whether a variable is safe to delete is to count the references to that variable in the forward path of the code; when there are no more references, it can be deleted. But when two variables reference each other, that can create a circular reference from which there is no escape.

An article on Mozilla’s developer site explains how memory leaks are created, and how to avoid them. The trick is understanding when a specific type of circular reference is created. From the article:

function leakMemory() {
    var el = document.getElementById('el');
    var o = { 'el': el };
    el.o = o;
}

The circular reference formed above creates a memory leak; IE will not free the memory used by el and o until the browser is completely restarted.

Yes, you read that right, completely restarted. Not just when the tab is closed, that memory will stay locked until you restart IE. This is so crazy I’m actually a little dubious as to whether it’s still true.

Ok you may be thinking, but surely this doesn’t happen that often in practice? Consider this example:

function addHandler() {
    var el = document.getElementById('el');
    el.onclick = function() {
        this.style.backgroundColor = 'red';
    }
}

The article goes into some detail about how these examples leak, and how to spot and fix them, and I highly recommend reading the entire page, not just the memory leaks section.

I’m currently in the middle of “Javascript: The Good Parts” by Douglas Crockford and highly recommend it, it’s pretty thin at 100 pages not including the appendices, but it is of exceptionally high quality – you’ll start understanding and writing better javascript from day one. Crockford also has a great page on memory leaks in JavaScript.

Often, people spout PHP optimisation advice that is incredibly misguided, so I want to make it clear up-front that you should be benchmarking your scripts using xdebug before you start optimising, and very often the real bottlenecks cannot be avoided by using “micro-optimization”. Here’s a nice PDF on Common Optimization Mistakes.

Now I’ve got that disclaimer out of the way, I believe it’s OK to talk about making a faster array_unique because it’s often used on large amounts of data – for example removing duplicate email addresses, and as such there are genuine use cases for a fast array_unique in PHP. Also our fast_unique function can be several seconds faster than array_unique so we’re not necessarily talking about micro-optimisation here; on 200k duplicate entries, array_unique takes nearly 5 seconds on my windows dev box, fast_unique takes <1 second on the same data. On 2 million entires the results are staggering – performance graphs are given below (but then, why are you doing that kind of work in PHP?).

The function looks like this:

function fast_unique($input) {
	// Code documented at: http://www.puremango.co.uk/?p=1039
	return array_flip(array_flip(array_reverse($input,true)));
}

This will return a copy of the input array with duplicates removed and keys preserved.

When using this function, there are some important caveats you should be aware of:

1. The data is not returned in the same order as array_unique would return it. You can add a ksort afterwards, but this will reduce the speed savings. Key order preservation is often not required, so I haven’t included that by default. Key association is preserved, just not the ordering.
2. This only works with strings or integers for keys and values. You could hack together a __toString walk to get it to deal with objects too, and I may do that at some point.
3. I haven’t yet benchmarked memory consumption; memory_get_peak_usage doesn’t seem to work properly with the native array_unique. Help?
4. For smaller amounts of data (<50k entries) I would suggest keeping array_unique for code-clarity. fast_unique is still faster than array_unique, but at those levels, you’re talking less than 0.5 seconds difference.

To explain how it works, let’s go through an example: let’s say we start with this array:

0=>apple
1=>biscuit
2=>cabbage
3=>biscuit

When we array_flip it, we try to create an array like this:

apple=>0
biscuit=>1
cabbage=>2
biscuit=>3

but now that “biscuit” is a key it can’t have two values, so the “biscuit=>3″ assignment overwrites the first biscuit value, and we end up with this:

apple=>0
biscuit=>3
cabbage=>2

then we flip it again to get key=>value pairs again instead of value=>keys:

0=>apple
3=>biscuit
2=>cabbage

And there we go – duplicates removed! Now in this example, later keys (i.e. 3=>biscuit) overwrote earlier ones (1=>biscuit) – but with PHP’s native array_unique earlier keys are preserved, so in the fast_unique function above, we reverse the array before flipping to mimic that functionality – if you don’t care about keys then go ahead and strip it out.

I’ve benchmarked this code for speed against various input sizes: 2k,20k,200k,2m, and various levels of uniqueness: 0%, 50% and 100%. An “input size” of 2000 means we fed in an array with 2000 entries whose values are strings between 1 and 200 characters in length. 2 million duplicate entries took too long to generate, so I didn’t benchmark that size for the 0% unique test.

So there you have it; quite dramatic for large amounts of data. I feel I should mention that the “double flip” method is nothing new; there are notes on the PHP docs to the effect that “the array flip method is faster”, but I thought a rigorous benchmarking and documentation was worth doing, so please don’t hate me if you “invented” this years ago ;)

Also, if this is the first time you’ve read about PHP optimisation, do remember that most of the time it’s pointless trying to speed up PHP code. Array_unique is a special case because it’s often used on large arrays (and if your array is smaller than around 50k entries, it’s probably not worth using this function). Read that Common Optimization Mistakes PDF, and my other post on fast PHP for tips on how to correctly approach PHP optimisation.

Like most web applications these days, we make fairly extensive use of Ajax, sending and receiving JSON data across the net on hover events and so on.

However, we’ve found that all those HTTP requests can slow down the user experience, and causes unnecessary extra load on our application servers, so we decided to employ a client-side Least Recently Used (LRU) caching object, so that we can reduce the number of HTTP requests, and increase the response speed for cachable queries. It employs lazy garbage collection, just like memcached does. In fact we see this as a kind of “memcache for javascript”, if that makes any sense at all.

• Get Cachejs now on Google Code. I’d love to see what you do with it ;0)

It depends upon no external libraries. Here’s a simple usage example:

var myCache = cache();
// tell the cache to use an array for its internal storage system
myCache.setStore(arrayStore);
 
// setting a value which does not expire:
alert(myCache.has('foo')); // false
myCache.set('foo','val');
alert(myCache.has('foo')); // true
alert(myCache.get('foo')); // "val"
 
// setting a value's expiry:
var tomorrow = new Date();
tomorrow.setTime(tomorrow.getTime() + (1000*3600*24));
myCache.setExpiry('foo',tomorrow);
alert(myCache.get('foo')); // "val" (until tomorrow, then null)
 
//deleting from the cache
myCache.kill('foo');
alert(myCache.has('foo')); // false

You don’t need to worry about serialising values; the cache internally json encodes the value if needed when setting, and parses it again before returning it back to you, keeping the interface nice and clean, and allowing you to store any kind of data – raw JSON, XML, variables, objects, strings, etc.

What’s more, it’s designed to be future-proof, with pluggable storage modules allowing you to extend the caching object to use any kind of storage system. The cache API abstracts the storage API away so you can swap stores without changing your caching code at all; you just change the setStore line and the rest of the code will still work just fine.

We’ve written an arrayStore which caches data for the current page only, a cookieStore which works for the whole domain but has the usual cookie limits, and a localstorageStore which uses the funky HTML5 Web Storage specification (AFAIK supported by IE8, FF3.5, Safari4, Chrome4, Opera10).

The full API documentation follows.

Cache API Documentation:

Storage API Documentation:
You only need to know about this if you’re implementing your own stores – this API is abstracted away in the cache object. If you do want to implement your own stores, I have written some simple javascript unit tests to make sure they comply with the required API.

The cache object uses the lovely Module pattern and is well documented. You can download and hack it up on google code. Please share your modifications.

The Future

What you see above is a pretty simple solution packaged up nicely. I’d like to see the following features:

Expiry Callback. So when a key is requested and has expired, it is removed from the store and a callback is executed with the keyname, then the value is checked again and returned. The idea being that the cache can automatically refresh itself when a key expires.

Cache Size Limit. At the moment the cache will grow arbitrarily large. This could become a problem.

Eager Garbage Collection. As an option, in case someone finds a use for it. I suspect lazy will be best for most applications though.

Manual Cache Clear. In case you ever need to manually flush the entire cache.

Helper Methods. Like .incr(key) to increment a key’s value, .toJSON(key) to get the JSON’ed value, .setFromJSON(key,json_val), and probably others. Is this a good idea?

Default Values. So you can say foo = myCache.get(“fooKey”,”defaultValue”). Will need to think about how get this working alongside the callback mechanism. I guess we can detect the type of the second argument – if a function it’s a callback, else it’s the default. I want to avoid the second parameter being some json (eg .get(“fooKey”, {default: “def”, callback: method, expiry: tomorrow}); I find that a little ugly.

If you feel like adding your ideas, features, new stores (ajaxStore?), etc, the MIT license is very open – far more so than GPL, so hack away at it and let us know what you think!

I’ve been working on a colour-related project on and off for about a year now, and part of that has involved creating visualisations of the RGB colour space – plotting red on the X axis, blue on Y, green on Z. So I thought it would be interesting to map XKCD’s 954 most common colour names in three dimensions – his charts are nice n’ all, but sexy javascript 3d is, well, sexier:

If you click that, you’ll be taken to the demo page, where you can interact with the cube. It’s a bit juddery, working entirely with divs and DOM manipulation, rather than canvas. Here’s a view from the side angle that shows off the “3d-ness” a bit more:

Of course, a canvas is really a better solution, so here’s a version that renders onto canvas, which is much much faster, but currently omits the names:

Again, click for pretty swirlies in anything other than MSIE (updated to include chrome, opera and safari).

In a later blog post, I’ll be tidying up and releasing the 3d library, which is heavily based on the cunningly named JS3D library and I’ll also be using xkcd’s data set, among others, to do some really nice machine-learning based image recognition stuff. You’ll have to wait for all that though.

In the meantime, if anyone wants to pull apart the js3d canvas library I’ve hacked together from WXS’s dhtml library and suggest improvements I’ll be glad to hear them :)

So it’s quite a common problem that people find their large PHP web applications running quite slowly.

Here are some frequently encountered bottlenecks found in web applications generally, and PHP specifically:

1) The Database

So often we treat databases like big persistent arrays. They’re not.

First of all, remember that anything that goes in or comes out of the DB is going to have to be transferred to your web server. That’s a network hit. So storing images or other binary data in the database is generally a Bad Idea (for other reasons too). But it’s not just images – all database traffic will happen over the local network, so if you’ve got big chunks of HTML or thousands of rows of data flicking back and forth you need to be aware that that will entail a network hit. mySQL compression can help with this, but be sure to benchmark for your own scripts – it may be that the CPU overhead cancels out the benefit of mySQL compression for your servers.

Secondly, a great many databases are thrown together without much thought for optimisation. You need to look closely at what queries you’ll be running, and optimise the structure of the database for them. Often it’s as simple as adding an index, but sometimes you might need to examine your queries to make sure they’re doing what they should be.

The database is a very very common source of speed problems – you will often find that simply adding an index to a table will solve your troubles. Look to the database first!

Here’s a very neat tip from google’s php optimisation page:

Avoid doing SQL queries within a loop

They note that it’s faster to run one query like this:

INSERT INTO users (first_name,last_name) VALUES("John", "Doe"),("Jane", "Doe")

Than it is to run two queries like this:

INSERT INTO users (first_name,last_name) VALUES("John", "Doe")
INSERT INTO users (first_name,last_name) VALUES("Jane", "Doe")

A great little SQL optimisation tip. Construct one query in a loop and run it once outside the loop rather than running the query inside the loop.

2) Client-side optimisation.

Often when we hear about “slow web applications”, people are actually talking about page load time, which can often be quite independent of the server-side code optimisation side of things. Take a good look at your images – are they uncompressed PNGs? Do you really lose anything by converting them over to 90% quality JPGs instead? You’ll certainly gain page load speed and reduce bandwidth. Also make sure you’re using gzip compression on the web server where applicable, and think about minifying your css, javascript and html code. Often user complaints about sluggish code is actually more related to the delivery rather than the processing. In certain use cases (eg toolbar icons), using CSS sprites is a good client-side optimisation, but don’t forget about the hit on initial devlopment time.

Install the firebug addons pagespeed and YSlow to get a good look at where the client-side bottlenecks are.

3) Slow Code

PHP is easy. Easy to get wrong that is. There are a lot of posts out there with micro-optimisation techniques, which can work wonders in very specific circumstances, but generally speaking these “tips” will be counter-productive in the long run, forcing you to code un-naturally and making your code resistant to changes. For example, using & to access 1d arrays is faster, but what if you add a dimension later on in development – will you remember that it hurts performance on >1d arrays? And what if the next version of PHP changes that behaviour?

However, there are a few optimisations that are so blindingly obvious, yet often ignored – caching the count() in a loop for instance:

for($i=0 ; $i < count($arr) ; $i++) {
}

versus

for($i=0, $c=count($arr) ; $i < $c ; $i++) {
}

In the first snippet, that count function runs on every iteration. In the second, it runs only once. This really can have a big impact not only on a per-script basis, but also on the server as a whole.

You should really work to make the second style a habit. It’s hardly any different syntactically but it offers a huge potential performance increase.

But aside from a few simple good practice optimisations like that one, how do you tell where the bottlenecks in your PHP code really are?

A lot of people just throw down echo microtime(); in a bunch of likely-looking places and run it a few times. Let me share a tip about code profiling.

Using the xdebug extension, we can get an insight into the speed footprint of every single line of function call in a script. Here’s an example of the output we can get:

We have a nice breakdown of the amount of time (percentage or ms) that each function call takes, how many times it is run, and whether the time is taken up within that function (self) or elsewhere (cumulative). And you can get this breakdown simply by appending ?XDEBUG_PROFILE to the GET request – no code changes required!

Sadly, there is one caveat: it’s not very stable on windows. I would moan at you and tell you that you should be developing on the same architecture as your live servers, but as you can clearly see from the screenshot, I’m still humping Bill Gates too.

Here’s a little post about setting up xdebug and wincachegrind for PHP code profiling. It’s pretty easy to do.

4) Repeated work is inefficient

So many content managed web applications feature code like this:

include "db.php";
include "header.php";
 
$sql = "SELECT Content FROM Pages WHERE PageID=5";
$res = mysql_query($sql,CN);
if($res) {
	$row = mysql_fetch_assoc($res);
	echo $row['Content'];
} else {
	echo "error fetching content";
}
 
include "footer.php";

And I mean, that’s one of the nice things about PHP – you can quickly slap together an interface between the DB and HTML – wonderful for rapid prototyping.

But think about it – how often does that page content change? Wouldn’t it be better to link to page.html, and when the administrator hits save in the backend CMS, overwrite page.html with the generated content?

That way the million users who request that page every month don’t even spawn a PHP process – apache can handle that entire transaction. This means the page is served super-quick instead of running the same code with the same input and the same output a million times. Everyone benefits – the server is running less duplicate code, and users get faster web applications.

It’s not just rarely-accessed parts of the site that can be optimised in this way either.

Consider an online store. Well, why not generate a pretty much static copy of the site – it only needs to be updated when product info changes. Obviously you’ll want to look at your own application to see where it makes sense to cache on the disk instead of generating on-the-fly, but it’s an option that’s too often overlooked.

That brings us nicely on to:

5) Caching

This is where the line between web developer and server admin starts to blur, but for large scale applications you will need to start thinking about opcode caching, memcache, squid, mySQL query-cache and other types of cache.

These types of solution are almost always highly tailored to the individual needs of the application, so I will not talk much about it – the chances are that if you need this level of caching, you already know more about it than I do, so I won’t pretend to be an expert in this area. Here are some links/pics from the guys who really do know about this kind of stuff:

• Reddit’s architecture
• Digg’s architecture
• Wikipedia’s architecture
• Some slides on accelerating PHP

That’s all for today. To recap:

1. Don’t transfer more than you need to across the network.
2. Make sure your tables are indexed properly.
3. Don’t write slow code.
4. Cache rarely-changing output in files on disk.
5. Draw out your architecture to identify where more serious caching can happen.

Thanks to Daniel at toosweettobesour for taking me to task about the micro-optimisations ;)

You read that right. This works in:

• Firefox >=3.6
• MSIE >=5.5 (!)
• Safari >=4
• Chrome

And it degrades gracefully in older browsers and Opera.

My boss Mike passed this little CSS gem to me, and now dear reader I pass it to you. It was orignally developed by FakeDarren, who posted a great little CSS button example. I find it useful for those times when designers get all fancy with gradiented backgrounds.

I’ve condensed Darren’s CSS down to these four lines plus comments, which will give you the lovely Green-to-Black CSS fade background you can see above.

  .gradientV{
/* thanks to http://blog.fakedarren.com/2010/01/cross-browser-css-gradients/ */
    /* fallback (Opera) */
    background: #008800;
    /* Mozilla: */
    background: -moz-linear-gradient(top, #00FF00, #000000);
    /* Chrome, Safari:*/
    background: -webkit-gradient(linear,
                left top, left bottom, from(#00FF00), to(#000000));
    /* MSIE */
    filter: progid:DXImageTransform.Microsoft.Gradient(
                StartColorStr='#00FF00', EndColorStr='#000000', GradientType=0);
  }

And as you may have guessed by the ‘V’ in the class name, you can also do horizontal gradients – here are some more examples for left-right gradients, and we see what happens when we apply animations to a gradiented DIV.

Horizontal Gradient CSS:

  .gradientH{
/* thanks to http://blog.fakedarren.com/2010/01/cross-browser-css-gradients/ */
    /* fallback (Opera) */
    background: #008800;
    /* Mozilla: */
    background: -moz-linear-gradient(left, #00FF00, #000000);
    /* Chrome, Safari:*/
    background: -webkit-gradient(linear,
                left top, right top, from(#00FF00), to(#000000));
    /* MSIE */
    filter: progid:DXImageTransform.Microsoft.Gradient(
                StartColorStr='#00FF00', EndColorStr='#000000', GradientType=1);
  }

So now we no longer need little 1px slices in the background-image property, just remember to make sure all the colors in each line of CSS match up, and that you choose a nice flat colour fallback that works with your content.

I’m very impressed with how slim the CSS needs to be to get this great cross-browser CSS background gradient. Just saying those words gives me shivers. Yay for CSS!

One other thing that this allows, which was never possible using css background images, is stretchable gradients. Not only can the content be allowed to expand ‘naturally’ via site updates etc, but we can actually animate gradiented DIVs and preserve the effect!

As in:

I have draft posts about all kinds of Good Stuff™, but none are quite publishable yet. So today I’m just going to point you at a few great resources I use all the time while doing my web development magic:

Before I start on the list proper, I’m going to assume you already know and love firebug, if not, go away and don’t come back till you’ve got it. I mean really, firebug has moved js development forward no end.

Cool (free) Tools That You Need:

• php.js – a project to port PHP functions to Javascript. Ever wanted to use number_format() in JS? Or date()? Now you can.
• IETester – a program that bundles Internet Explorer 5.5, 6, 7 and 8 together so you can open each one in a new tab and test your website in multiple versions of MSIE.
• The Regex Coach – you type the target string, then type the regex. It highlights the matches as you edit the regex. This will save you hours.
• Xenu – a program that recursively checks a URL for broken links. This should really be the final stage before go-live of any project.
• SQLYog – like phpMyAdmin in an application, but faster and more robust. Does need the firewall opening up though. Nagware.
• Paint.NET – If MS Paint and Photoshop had a baby, paint.net would be it. The image editor of choice for those of us who “just want something a bit better than paint”.

That’s my list of essentials. Sorry this isn’t a “proper” blog post. Hopefully one or two of the tools there will help you out. The Regex Coach is truly great. And completely compatible with PHP’s preg functions (ereg is now deprecated), and javascript regular expressions engine. Yay.

Any “OMFG I can’t believe he missed that” additions? btw, does anyone have a good color picker – one that I can easily copy the current colour from? Because most of the time I have to just remember that it’s #FE38C4 or whatever. Being able to Ctrl-C directly would be nice.