Code

Somehow this slipped under my radar. Apparently both Mozilla and Webkit have gained experimental support for WebGL. WebGL is going to expose OpenGL ES 2.0 (the same version of OpenGL you find in an iPhone) in JavaScript to be rendered inside a canvas tag. This is without a doubt, the most exciting thing to happen for web-based games ever. It ends up being a standards based, platform agnostic, hardware accelerated rendering method bundled as an extension to JavaScript, using a tag that is already part of the HTML 5 standard.

This is a huge piece of the puzzle that is going to allow the creation of web-based 3D games that can take advantage of hardware acceleration. So which pieces are missing? Not too many as it turns out. New implementations of JavaScript in both Firefox and Safari are very fast, making render loops and input capture entirely possible within the browser window. Video and audio have both got standards support in HTML 5. The only thing I can think of that’s missing is server initiated communication and peer to peer networking that would be necessary for real-time multiplayer games. Yeah you can poll a server making it possible to have multiplayer turn-based games or even real-time games where latency isn’t an issue. For 3D shooters and MMOs however, I would wager the networking piece is still mighty important.

Can’t wait to get my hands dirty with this stuff.

I’m posting this so I don’t need to go hunting on Google (which was surprisingly tight-lipped about the right solution) the next time I have to do this. If you want to convert a certificate issued in the .crt & .key formats for Apache to the .p12 format favored by IIS you need to run this command in linux:

openssl pkcs12 -export -out iis.p12 -inkey apache.key -in apache.crt

Replace IIS / Apache with the appropriate filenames and you’re done. The .p12 file can be directly imported into the Certificates MMC Snap-In on Windows for use in IIS. The command works on any system that can run openssl, including Mac OS X.

Internet Explorer 8 comes with two different rendering engines. “Standards Mode” (they use the term loosely) and “Compatibility Mode”. I’m not going to debate the reasoning behind their choice to ship the browser in this form, smarter people than I have already beaten that horse to death. The problem I have with it is that by default IE ships with a setting that makes anything on your LAN show up in compatibility mode. The button to switch to standards mode isn’t displayed, and worst of all, there is nothing that tells you it is IN compatibility mode.

I recently discovered this when, after carefully testing a site in Internet Explorers 6, 7 and 8, I committed the release to the SVN repo and published it to the staging server. A quick test showed IE8 issues that weren’t there on my local version. Turns out the problem was this default compatibility mode setting. You can turn it off by going to “Tools > Compatibility View Settings” and unchecking the “Display intranet sites in Compatibility View” option. They did this to ensure old intranets are compatible with IE8 out the box, but in the process put every web designer in the awkward position of not knowing their site is broken until they upload.

Internet Explorer 8 isn’t all that bad. It does a pretty good job of fixing the (not so) little things that drove us crazy in previous incarnations, but it’s far from perfect. In the very likely event that you need to code some IE8 specific styles I recommend using conditional comments. In this case I needed one set of modifications for IE6, 7 and compatibility mode 8 (which mostly behaves like IE7) and another for IE8 specifically. To achieve this I used the following code:

<!--[if lte IE 7]><link rel="stylesheet" type="text/css" href="css/ie.css" /><![endif]-->
<!--[if IE 8]><link rel="stylesheet" type="text/css" href="css/ie8.css" /><![endif]-->

It uses one stylesheet for everything less than 7 and another for IE8 specifically. Works like a charm, hopefully until IE9 comes along.

I can’t count the number of times I’ve had to explain to clients that their beloved logo font simply cannot be used on the web. I explain that if the visitor doesn’t have the font you want to use installed then they can’t see it. Most of the time they are shocked that this is the case. And they should be shocked. It’s absolutely horrible that we have to deal with these limitations.

Technically it has been possible to use any font you choose through several existing techniques (plain old images or Flash/JavaScript/Canvas trickery like sIFR and Cufón). They all have limitations of varying degrees and body font choices are still limited to the usual suspects. So why is it so hard to use fonts on the web?

Copyright

The main issue is one of font copyright. Fonts are expensive. Making a font takes lot of time, dedication and talent. Font designers deserve to be paid for their incredible work. If you send the font over the internet when you visit a website it doesn’t take long to figure out what’s going to happen.

Font Delivery

The copyright issue had stopped the development of viable alternatives to Microsoft’s (ancient and proprietary) EOT format. Finally however, both Webkit and Mozilla (Safari/Chrome and Firefox) support the @font-face CSS attribute. Making it possible to create an all-browser encompassing font delivery mechanism.

Enter Typekit

The clever peeps at Typekit have managed to fix both problems in one fell swoop. By working with the type foundries directly, they have managed to gain licenses to distribute fonts over the web. They’ve also taken great pains to obfuscate the fonts they are distributing. More importantly for us lowly web designers, they’ve made this stuff ridiculously easy. Choose the fonts you want (236 options as of right now), get a snippet of JS and Bob’s your uncle. All the fonts are compatible with Firefox 3.5+, Safari 3.1+ and IE 5+ (!).

I just got my beta invite and am going to be reworking both this site and ActivElement to use my newly acquired library. Can’t wait to get my font on.

We had a fair bit of data piled up at our virtual server on The Rackspace Cloud’s Cloud Sites system (previously known as Mosso). When we decided to move off Cloud Sites and on to Amazon EC2 moving that data quickly became extremely important. MySQL offers several methods of transporting data from the database and mirroring/replication seemed to be the ideal fit since we’d get our data synchronized in real time with the old database. Unfortunately, because of the way Cloud Sites are configured we can’t use mirroring at all (it’s already being used internally by Rackspace for scaling).

Since, we were using Cloud Sites we didn’t have SSH access to our box. Rackspace recommended we use mysqldump on another server and connect to our MySQL instance to grab the data directly over the internet. Two problems with that:

1. Moving 15GB. of data on a single connection sequentially would take forever. (We were getting only ~200Kb/sec)
2. The data would not be compressed, so we’d have to move the full 15GB.

Our solution:

1. Setup a virtual Cloud Server on Rackspace Cloud with enough space for the data.
2. Use mysqldump on this new server to connect to Cloud Sites and grab the data. Since they’re in the same server farm you get much much higher transfer rates.
3. Compress using gzip and place in a web server document directory.
4. On the Amazon server use aget to download the newly compressed gz file. We used 10 parts and got about 1800Kb/sec.
5. Unzip and execute the SQL.

This reduced the amount of time needed to manageable proportions and therefore caused a minimal service outage.

Master pages are great time savers in ASP.NET and we use them extensively to simplify user interface management in our applications. Recently, I ran into a situation where the master page to be used needed to be set from the Database. Turns out this is relatively simple to do if you know the path to the master page. You need to harness the Page_PreInit event that fires before the Page_Load and set the master page at runtime:

protected void Page_PreInit (object sender, EventArgs e) {
    this.MasterPageFile = "~/path/to/masterpage.master";
}

The other problem I ran into was accessing a control on the master page from the web form that uses the master as a template. This is important because if all the inter-changeable master pages have the same control names they become useable from the web form irrespective of their location on the page. One way is to define the same content areas in all the master pages and set them accordingly within the child, however in many cases you’d be duplicating the code relating to the control on the web forms. The other option is to use the FindControl function on the Master object. In order for this to work it needs to be cast to the appropriate control class. In the case of a Literal the syntax works out like this:

((Literal)this.Master.FindControl("literalControl")).Text = "Foobar";

Nice and easy.

It turns out that my favorite JavaScript library has a rather weird chink in its otherwise impregnable armor. The Form.Serialize method makes a complete hash (no not an object hash, a right royal mess kind of hash) of serializing radio buttons. Google of course came to the rescue with this very excellent fix from Rex Chung.

This works great if you’ve got one set of radio buttons, I had an unknown number to deal with. So here is a slightly modified version that uses Prototype’s findAll:

Form.getInputs('formName','radio').findAll(function(rad){ return rad.checked; }).each(function(rad) {
     //Deal with each radio button here by referencing the method argument "rad"
     alert(rad.value);
});

Works like a charm.

IE7 has shipped and its probably (by and large) a decent browser now. But of course it wouldn’t be Microsoft if they didn’t mess up something. First in what will probably be a long line of security related “features”, Microsoft have decided to modify the way that the good old JavaScript prompt works.

The reason? Phishing sites impersonating or even superimposing themselves on real web sites were using the prompt to lure gullible users into providing credit card numbers, passwords and all sorts of powerful data. So now whenever a web page wants to use a prompt you have to click on the unnoticeable security bar at the top of the browser and “allow” temporary access. To make matters worse the prompt presented is ugly and out of place.

I’m not saying that a prompt is the best way to ask the user for data, but given the whole Web 2.0 movement there are numerous occasions where the prompt is a useful and elegant solution to on-the-fly input. The worst part is that the unscrupulous underbelly of the internet will end up using a modal window or a clever floating div about 15 seconds after they realize their old technique doesn’t work and then who loses? Why, the web 2.0 programmer that thought a JavaScript prompt was a no-brainer in terms of cross-browser support.

Phishing works because people are stupid, making your browser idiot-proof is a surefire way to drive yourself crazy.

Score one for stupidity.

Started messing with the most excellent Scriptaculous JavaScript library yesterday and almost immediately ran into a very frustrating problem. The Draggable Class exposed by the library has some annoying behavior built in by default. When you set revert to true it has this animation where it moves back to its original location.

I was trying to build a drag and drop toolbox and the effect I was looking for was along the lines of dragging it and dropping it into a particular location and then it reappearing back at the original location. So the toolbox lets you drag individual items over to the main area and then the item reappears where it was taken from.

Well after several hours of digging around in the internals of the Scriptaclous JavaScript files I have the solution, so here it is for the rest of humanity to enjoy:

new Draggable(element,{revert:true, reverteffect: function(element, top_offset, left_offset) {
  toff = top_offset;
  loff = left_offset;
  new Effect.Fade(element, {duration: 0.75, afterFinishInternal: function (effect) {
    new Effect.Move(effect.element, {x: -loff, y: -toff, duration: 0.0, afterFinishInternal: function(effect) {
      new Effect.Appear(effect.element, {duration: 0.75})
}}) }}) }});

The Fade and Appear durations can be tweaked but I found 0.75 to be perfect for what I was trying to achieve. I’ll probably post a link to the finished app when I’m done.

I’ve just completed my first design in pure CSS (sorry, can’t show it until it goes live) and the feeling I get is that it wasn’t harder than doing it with tables, just different. Well, that’s not true. It was harder because I didn’t know how a lot of the stuff needed to be done. But if I did know how it is supposed to be done the task wouldn’t have been harder than doing it the old-fashioned way with tables. I think it’ll be two or three designs before I get the hang of it. Then comes the cool part where I start doing things I never could before. Can’t wait for that to happen