Object-oriented folk may want to enclose these functions within an extended array object (or extend the Array object, if that’s your style):

var getArrayIndex = function(array, item){
    for (var i = 0; i < array.length; i++) {
        if (array[i] === item) {
            return i;
        }
    }
    return -1;
};
 
var deleteArrayItem = function(array, item){
    var index = getArrayIndex(array, item);
    if (index > -1) {        
        return array.splice(index, 1);
    }
    return array;
}

Using Array.indexOf might seem logical, but it’s mildly cross-browser problematic at the moment. Rather than using the common Array.indexOf workaround, I’m using a custom function because it’s less code and can be tweaked to suit any unique needs I might have.

var typefacehover = function (){                            
  $(".typeface-js").each(function(){
    //Get all the classes for an element. 
    var elementStyles = $(this).attr('class');
    elementStyles = elementStyles.split(' ');
    //Run through them and check for a :hover color property.
    var hoverColor;                                
    for (var i in elementStyles){                                        
      var temp = getCSSColor('.'+elementStyles[i]+':hover');                           
      if(temp) {
        hoverColor = temp;                                        
      }
    }
    if(hoverColor){
      var element = $(this).html();
      //Duplicate the element, create a new hover version of the element (hidden) and add a container to each one so that we can distinguish between the two.
      var hoverElement = '<div class="typeface-js-hover" style="color:'+hoverColor+';display:none">'+element+'</div>';
      element = '<div class="typeface-js-nohover">'+element+'</div>';
      var newElement = element + hoverElement;
      $(this).html(newElement);
 
      //Add the event listener. You could do fade transitions here if you wanted to be fancy.
      $(this).hover(
        function(){
          $(".typeface-js-nohover",this).hide();
          $(".typeface-js-hover",this).show();
        },
        function(){
          $(".typeface-js-nohover",this).show();
          $(".typeface-js-hover",this).hide();
        });
    }
  });
}
 
 
//Kudos: http://www.mail-archive.com/jquery-dev@googlegroups.com/msg03390.html
var getCSSColor = function(selector){                            
  var re = new RegExp('(^|,)\\s*'+selector.toLowerCase()+'\\s*(,|$)');
  var color;                            
  $.each ($.makeArray(document.styleSheets), function(){
    $.each (this.cssRules || this.rules, function(){    
      if (re.test(this.selectorText)) {                                        
        color = this.style.color;                                        
      }
    });
  });
  return color;
}

I hope to find the time to develop a more robust solution in the future. Let me know if this was helpful!

Months ago, in my mission to find a good solution for using fancy fonts on the web, I had a choice between sIFR and typeface.js. sIFR uses Flash to render text, and typeface uses the <canvas> element (or VML in IE). Other than the difference in implementation, however, their feature-set looked about the same, at least for my simple purposes: they were both javascript driven, both allowed text to be selected, and they both looked damn good.

But typeface.js had one crippling debilitation. It didn’t have :hover support. Weak. So I went with sIFR.

First, I found sIFR’s configuration to be a pain. Well, that’s OK. I only have to learn the setup once, then I can copy+paste my code.

Then I found that it had z-index issues in IE, particularly when using them as links and tying the :hover directive together with an image change. Annoying, but it’s flash based and IE is always a pain. Fine.

Then I noticed that my jQuery animations (slide effects) were slowed down when sIFR elements were included in the animated element. Hmmm.

Then I started using a lot of sIFR elements on one page… significant loading delay. Hrmph.

Then it came to my attention that every once in a while the sIFR elements would fail to load altogether in IE on those sIFR-heavy pages. Uh…. sIFR, we’re through. This just isn’t going to work out. It’s not me, it’s you. It was great while it lasted (wait, no.. not really). Ciao.

And then I said hello to typeface.js. Configuration? Piece of cake. Speed? Fast! Reliability? Hasn’t failed me yet. Z-index issues? None. Lack of :hover support?

I can live with that.

It’s also worth noting that a HEAD request also returns the content length and last modified date, and that jQuery has an “ifModified” option for the .ajax function that returns a boolean value.

Quick code snippet:

$.ajax({
    url:'http://www.example.com/somefile.ext',
    type:'HEAD',
    error:
        function(){
            //do something depressing
        },
    success:
        function(){
            //do something cheerful :)
        }
});

Couldn’t be easier!

The solution is to pass your variables on in an array. Here’s the template that I use whenever I code a new function:

function example($args="") {
    $variable1 = $args['variable1']? $args['variable1'] : 'default';
}

And this is how you pass variables on to your function:

$args = array(
    'variable1' => 'value',
    'variable2' => 2,
    'variable3' => $etc
);
example($args);

And what’s more, if you have an existing function that you want to convert to taking an array, but don’t want to change all of your existing function calls, you can do something like this:

function example($args="", $variable2, $variable3) {
    if (is_array($args)) {
        $variable1 = $args['variable1']? $args['variable1'] : 'default';
        $variable2 = $args['variable2']? $args['variable2'] : 'default';
    } else{
        $variable1 = $args;
    }
}

Clean, tidy, and easy as pie.

Step 1: You need to edit your .htaccess file to incorporate some mod rewrite rules. This is the code that we’re going to use (the same code that WordPress uses):

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /yourcode.php [L]

What this does is capture the “filenames” (really just a URI string that comes after your site root), and pass them on in an array to the file of your choice, “yourcode.php” in this case. It does all this without changing the URL on the user’s end. So now all we have to do is pick up those variables in our PHP code. We’ll do that with this code in yourcode.php :

$uri = $_SERVER['REQUEST_URI'];
$vars = explode('/', $uri);

So now we’ve captured the elements of the permalink in our array $vars, starting with the second array object, $vars[1]. The first array object, $vars[0] will return as blank. So let’s suppose the user is trying to go to this address:

http://www.yoursite.com/someuser/profile

$vars[1] will be “someuser”. $vars[2] will be “profile”. We can then use that information like so:

$user = $vars[1];
$page = $vars[2];

… and then use those variables to determine what data we output to the browser.

Easy as pie.

Pandora’s little black box is about to be opened. Soon, very soon, most common browsers will support the @font-face CSS directive. Web designers will have at their disposal any TrueType or OpenType font that legally allows for web embedding. What does that mean to you? Well, brace yourself for a web full of unreadable, kooky typefaces, messy grunge fonts, and lots and lots of imitation handwriting.

And that’s not all. Designers will want to use commercial fonts that are meticulously designed with readability and balance in mind. Unfortunately, because the directive requires that the font file be downloaded by the client machine (and therefore accessible to anyone on the web), the use of said fonts will constitute a legal violation. So the fonts we hate will be given free reign while the fonts we love will remain private treasures.

That having been said, there is a bright side. I have a few predictions: Reputed foundries will release free, limited web-versions of their commercial fonts. The prolific use of hideous typefaces will only make the good ones shine a little brighter. Web designers will be forced to learn more than a handful of fonts. Typography’s value will be clearer, and interest and appreciation of it will rise.

OK, want a taste of what it will look like? This post is an experiment—it uses @font-face—so all you have to do is load it in a browser with @font-face support (see link below for more info) and you can behold the wonder that is font embedding. My apologies if this post is a poorly executed example and hard to read (welcome to the future, friend). I only wanted to experiment and learn, which leads me to my next point.

I have two potential concerns for the practical use of @font-face:

One. While testing @font-face on this page, I noticed that some fonts just didn’t work. On top of that, fonts that worked in Firefox 3.5b didn’t work in Opera 10a. If anyone knows what’s going on here, please enlighten me. I realize that I’m working with alpha & beta versions of those browsers, so maybe this is an issue that will work itself out in due time.

Two. As usual, IE somehow manages to be both ahead of and behind the curve. While IE has supported @font-face since IE 4 (yeah, seriously!), they only support a font format called EOT (Embedded Open Type) that they created and no one uses. Naturally, being Microsoft, they decided to make the font conversion process a huge pain, which might just explain why no one uses it (hmmm…). IE’s lack of support for TrueType or OpenType is very troubling and can’t be ignored, but no one is going to torture themselves by using IE’s conversion tool unless the process is more streamlined. Solution: As usual, the rest of the world waits for IE to catch up.

All concerns and nay-saying aside, I really am very optimistic about the future of typography on the web. If you’re a web designer or developer, take some time to play around with @font-face! Here are a few links to get you started:

My hat goes off to Webfonts.info for being an extremely useful resource. Be sure to check out their list of commercial foundries which allow @font-face embedding. I expect that list to grow very quickly in the near future.

A nice summary of supported browsers & browser versions

A list of fonts available for @font-face embedding

Jon Tan has a detailed article on how to make @font-face work in IE