The new iOS isn’t all bad. The animations feel snappier, Springboard is prettier, and it’s got the slick Apple feel which everyone so desperately wants to emulate. The big one, of course, is multitasking, and that I think they got right.

But then there are the problems. Apps crash with neither rhyme nor reason: the iPod app won’t even startup properly for me anymore. Google Sync is kaput (although I think Google should take some of the blame for that). The new folders, whilst useful, are, to be charitable, ugly. It all feels as though it was released without going through proper testing, let alone going through the spit-and-polish phase.

I was looking forward to this update. I thought that, like all the iOS versions before it, it would Just Work^TM. I hope that when they patch iOS 4, they don’t introduce any new features: there’s just too much that needs to be fixed.

Why am I bothering to tell you this? Because I enjoy what I do. I get to develop software that’s genuinely useful, that people actually appreciate, and that has concrete benefits. Oh, and I also get to play with all of the latest and most interesting new browser developments. One of the things I enjoy most about my job is getting out to sites and training people one-on-one. I love seeing people get caught up in what’s possible, and I particularly appreciate it when they come up with new ideas — ideas which can sometimes become central features.

I know, I know, this sounds a lot like I’m just banging on about work to earn brownie points. But the really weird thing is, it’s the truth. Yes, I’m young and idealistic. But then, I think that I’m work in a young and pretty-nearly ideal job.

There is, of course, a little bit more to it than that. Under the hood, I’ve got a series of HTML5 Audio objects that are used to provide polyphonic audio using a simple round-robin algorithm (I encoded the audio in OGG, so you’ll need to use an OGG-friendly browser, like Firefox). The particles are much simpler than those in my previous canvas dalliance, in that they don’t swarm, and their motion is more linear.

View (and hear!) it live

View it live

Essentially, 1 to 3 swarms of particles move around the canvas, reproducing when the conditions are just right, and dying of old age. Quite simple, but the patterns produced can be really quite pretty.

One interesting thing that I discovered whilst doing this is that you can’t pass around a canvas’ context at the instantiation of a MooTools class — it complains about wrapped natives. That’s why, if you like in the source JavaScript, you’ll see me pass the actual context around to various functions. I’d be interested in hearing if anyone has a workaround for this, because this is, well, a bit clunky.

The problem is that in Internet Explorer (tested 7 & 8), when your document is in quirks mode, uploading a file sometimes just sends through the file name, without the actual body of the request. Put the document into standards mode, and it all works. It should be noted that this is when you’re dynamically setting up the elements used with JavaScript.

The cause? In quirks mode, the enctype attribute isn’t supported. So whilst setting “encType” on the form element to the correct “multipart/form-data” will indeed set this attribute, it won’t actually cause the upload to include the file. Instead, you need to set the encoding attribute to this value, too. It certainly doesn’t help that the MSDN article on the <input type=”file”> element tells you to set “enctype”, but makes no mention of “encoding”.

• MSDN: ‘Encoding’ property
• MSDN: ‘Enctype’ property
• MSDN: <input type=”file”> element

I couldn’t find any reference to this problem on the intertubes (although maybe I just didn’t look hard enough), so hopefully this will help someone.

Element.implement({
	printElement: function() {
		var strName = 'printer-' + (new Date()).getTime(),
		styles = $$('link[type=text/css]').clone(),
		title = document.title,
		that = this,
		iframe = new IFrame({
			name: strName,
			styles: {
				width: 1,
				height: 1,
				position: 'absolute',
				left: -9999
			},
			events: {
				load: function() {
					var doc = this.contentDocument || window.frames[strName].document;
					doc.title = title;
					$(doc.body).adopt(styles, that.clone());
					this.contentWindow.focus(); // IE requires us to focus before printing, or the parent prints.
					this.contentWindow.print();
				}
			}
		}).inject($(document.body));
		iframe.dispose.delay(15000); // Destroy the iframe in 15s so that it doesn't hang around.
	}
});

This year, I am once again contributing. I just finished work on the track I will be contributing, so I thought it high time I let everyone know about this. Josh Whelchel, the organiser of the drive (and a fantastic musician to boot), has set a target of $10,000 for this year. If you donate $25 or more, you receive a physical copy of the (two disc!) album; otherwise, you receive the album digitally.

Here’s the official media release:

Indie Music Cancer Drive to Release Songs for the Cure ’10 Album

Twenty-eight artists join together to raise money for the American Cancer Society and aim to raise $10,000.

Cincinnati, OH, January 24th, 2010. – The Indie Music Cancer Society will release it’s 2010 compilation, Songs for the Cure ’10 on March 1st, 2010 and forward 100% of all donations and profits to the American Cancer Society through its Relay for Life event held on April 23rd, 2010 at the University of Cincinnati. The album will feature music from over twenty-eight (28) diverse artists, including Select Start, big giant circles, Alec Holowka, Two Seconds Away, Jay Tholen, Josh Whelchel, Renee Winter, and others. The organization is currently accepting donations, and all donors of $25 or more before MARCH 1, 2010 will receive a free physical copy of the album. Supporters with $10 or more will receive a free digital copy. Genres represented include Pop, Rock, Alternative, Chiptunes, Instrumental, Opera, Classical, Avant-Garde, Jazz, Fusion, and many others. The organization raised over $6,000 for the event last year and is still forwarding profits from last year’s album, available on iTunes, Amazon, and others. A full list of artists can be found at the Songs for the Cure ’10 website at http://www.cancerdrive.org. The fundraiser aims to raise $10,000 by April 23rd, 2010, preceding a digital release of the album to iTunes, Amazon, CDBaby, and other retailers. Donations are accepted through http://www.cancerdrive.org.

For more information please contact:

JOSH WHELCHEL
(513) 549-2336
http://www.cancerdrive.org

So there you have it. And for good measure, here’s the promotional video:

This new one makes extensive use of CSS3 properties, such as gradients and shadows. It looks best in Firefox >= 3.6,followed by Safari >= 4, then Chrome >= 4, Opera >= 10, and IE >= 8. Theoretically, Firefox and Safari/Chrome support the same level of features, but the webkit gradient syntax is absolutely awful. It’s confusing, needlessly complex, and poorly thought-out, in my opinion. Contrast the following two lines:

background: -moz-linear-gradient(top, #111, #333);
background: -webkit-gradient(linear, left top, left bottom, from(#222), to(#333));

See what I mean?

Gecko (Firefox), Webkit (Safari), and Trident (IE) rendering.

String.implement({
	sanitiseWord: function() {
		var s = this.replace(/\r/g, '\n').replace(/\n/g, ' ');
		var rs = [];
		rs.push(/<!--.+?-->/g); // Comments
		rs.push(/<title>.+?<\/title>/g); // Title
		rs.push(/<(meta|link|.?o:|.?style|.?div|.?head|.?html|body|.?body|.?span|!\[)[^>]*?>/g); // Unnecessary tags
		rs.push(/ v:.*?=".*?"/g); // Weird nonsense attributes
		rs.push(/ style=".*?"/g); // Styles
		rs.push(/ class=".*?"/g); // Classes
		rs.push(/(&nbsp;){2,}/g); // Redundant &nbsp;s
		rs.push(/<p>(\s|&nbsp;)*?<\/p>/g); // Empty paragraphs
		rs.each(function(regex) {
			s = s.replace(regex, '');
		});
		return s.replace(/\s+/g, ' ');
	}
});

If you’re not using MooTools, the function will look something like this:

String.prototype.sanitiseWord = function() {
// function body here...
};

Usage

var s = "(some awful Word markup)".sanitiseWord();

In one of the tests I ran, the input went from around 7000 characters to just 700.

Example

Some of the regular expressions I used were adapted from C# ones in a post by Jeff Atwood.

When styling text <input> elements, it’s fairly common to run into a serious problem: they don’t behave like block-level elements.

Note: In all of the examples, the container element is filled with blue, and the <input> itself is filled with red and has an opacity of 50% so that you can see it under- or over-flowing the container.

<div  style="background: blue; width:200px;">
  <input  style="display:block; padding:4px; background: red; opacity:0.5; border:0;" type="text" value="text input"/>
</div>

You can see how the input doesn’t automatically flow to full width, as the “display: block” style suggests it should. The kneejerk response is to set the width to 100%:

<div  style="background: blue; width:200px;">
  <input  style="display:block; padding:4px; background: red; opacity:0.5; width:100%; border:0;" type="text" value="text input"/>
</div>

But notice now how the input overflows its container’s boundaries because of the left padding. At this point, people may resort to non-semantic markup (removing the padding on the <input> and putting it inside a padded <div>) or JavaScript solutions that set the pixel width whenever the container’s width changes (by the addition of scrollbars, for example).

The (semantic) solution

But wait! There is a way to achieve this effect without resorting to an extra <div> or JavaScript:

<div  style="background: blue; width:200px;">
  <input  style="display:block; padding:4px 0; background: red; opacity:0.5; width:100%; border:0; text-indent:4px;" type="text" value="text input"/>
</div>

Do you see what I did there? I removed the horizontal padding on the <input>, so the 100% width now works correctly, and replaced it with “text-indent”. To the user, this looks no different, and it has the advantage of requiring no extraneous markup or tedious scripting.

Drawbacks

1. Should the user enter a long string, their text will bump up against the right edge. But I think that that’s a boundary condition that I can live with.
2. Any vertical borders on the <input> will cause it to overflow its container. Personally, if I want a full-width <input>, though, I generally don’t want any borders on its left or right other than those of its container.
]]> http://www.barryvan.com.au/2010/01/full-width-text-inputs-without-extraneous-markup-or-scripting/feed/ 1