Now that plain old HTML, CSS and JavaScript have made the web quite sophisticated, Flash isn't really as necessary as it once was. Nonetheless, I still see Flash being used to make things, well, flashy. Flash is often used just to add a touch of animation, like things moving around when the user moves their mouse, and other simple effects.

Well many, if not all, of these kinds of effects can be achieved with plain old CSS and JavaScript, thanks to animated GIFs. Yes, those awful animated GIFs. Just like JavaScript was until recently, animated GIFs are associated with the ugly web of the past (think dancing hamsters). However, if used carefully, animated GIFs can be used to make a web site very lively and feel more interactive in the same way Flash is used.

To demonstrate this, I've put together probably the most boring proof-of-concept ever. You'll have to use your imagination to see how this technique can be applied in much more creative and better-looking ways.

First, I created a simple animated GIF of a white bar moving left to right over a transparent background. I actually used Flash to create this. In fact, you could take a Flash interface, and publish the different pieces to animated GIFs in order to eliminate the need to use Flash. Anyway, here is my boring GIF on a black background, so that you can see what's happening:

Now, I'm going to use this together with CSS to create an animating hover effect. Here is the CSS and HTML I will use:

<style type="text/css">
/* IE 6 needs a:hover to be defined */
a:hover { width: auto } 

a.shine:hover span {
    /* don't take up space, and appear above the text */
    position: absolute;
    display: block;

    /* set the background to the animated GIF */
    background: url(shine.gif);

    /* the width and height of the animated GIF */
    width: 230px;
    height: 50px;
}
</style>

<a href="/blog/cat/javascript" class="shine">
    <span></span>
    JavaScript
</a>

I'm using an empty span inside the link to act as a placeholder for the animated GIF. When the mouse is hovering over the link, the span comes to life by expanding to an animated GIF which appears above the text. Since the background of the GIF is transparent, and the background of the text is white, the effect is that of a "shine" washing over the text.

Click here to see the code in action.

And there you have it. Yes, I know, my demo is boring. But you have to use your imagination to think of all the amazing things you can do by combining animated GIFs with CSS and even JavaScript effects. You can do something as simple as an animated roll-over image, or as complex as an interactive game. The possibilities are only limited by your ability to design them.

Did you know you can use <a> by itself without href, name, id or any other attributes?

The W3C says this in the HTML 4 specs:

Authors may also create an A element that specifies no anchors, i.e., that doesn't specify href, name, or id. Values for these attributes may be set at a later time through scripts.

Weird, eh? How often do the HTML specs talk about putting elements in for scripting purposes? I had assumed never.

So why would you want to use an empty <a>? I don't think it's so practical for scripting purposes, because it'd be better to dynamically add a link using scripting. But it does make sense from a styling point of view.

If you are using a list of links for a navigation or tabs or something, you probably don't want the active link/tab to be clickable. This can confuse users, because they may think that this link/tab goes somewhere else, when really it just points at the current page.

Normally to approach this, I would just remove the <a> from the <li>. But my CSS relied on there being a link there in order to set a background on it. So instead I just removed the href and used an 'active' class like this:

<ul class="nav">
   <li><a href="/">Home</a></li>
   <li class="active"><a>Page 1</a></li>
   <li><a href="/page2">Page 2</a></li>
</ul>

<style type="text/css">
.nav li {
   list-style: none;
   float: left;

   /* put a repeated background image on the list item */
   background-image: url(nav_background.gif);
}
.nav li a {
   display: block;
   height: 25px;
   padding: 0 15px;

   /* put a separator image on the right of each link */
   background: url(nav_separator.gif) top right no-repeat;
}
.nav li.active {
   background-image: url(nav_background_active.gif);
}
</style>

Now the separator image nav_separator.gif is still used on the empty <a>.

Most browsers will render the link differently, like removing the underline and colouring it different. They seem to treat it as if it's just a <span>.

You might argue that this uses unnecessary markup for purely display purposes. I'd argue that it's better to have a link that can't go anywhere than a link with an href that still goes nowhere.

There are probably other ways to take advantage of this. I'd love to hear any other ways that you think this might be useful.

If you're revisiting the site, then I'm sure you've noticed the new design. If you're reading over RSS, well, then you'll have to pop over and check it out.

I got bored last night, started sketching out what a logo might look like for The Future of the Web, and ended up sketching a whole new site layout to match it. Then I painted it in Paint.NET, was surprised how much I liked it, and spent the rest of the night wrestling with CSS until it came out the way I wanted.

Here are a few notes on the design:

• This was the first time I used Internet Explorer's Conditional Comments. I have a single CSS file that works for both Firefox and IE 7 (no hacks), but I use the extra CSS file to get rid of some of the png transparency files, and to fix a couple of bugs.
• I tried to keep the HTML the same and just change the CSS. I ended up having to change a few things (the search form of course, adding some classes, moving a few elements around) but it was fairly minimal.
• I encountered some of the strangest CSS bugs I've ever seen, like things disappearing/reappearing when scrolling down and up, or things moving around when making a link active. For IE 7, my greatest friend was zoom: 1, forcing things into hasLayout mode. This always fixed weird behaviour.
• I opted for a fixed width design to improve readability. I think a lot of web designers developers have huge resolutions, and having the text stretch out so wide makes it harder to read.
• I feel the site looks a lot cleaner and simpler than the original design, even though there is really just as much stuff on the page. I think this is due to the text being in a white area in the center of the page instead of stretched out filling most of the page.
• There are random slogans at the top of the page. Refresh and collect them all!

I'm looking forward to your comments. This is the first web design I've done that I'm actually really happy with. Not bad, I think, for not being a designer.

Update: For those of you who are new to the site, or if you just want to compare, here is a screenshot of the old design.

Unobtrusive Ajax is about keeping all JavaScript and CSS out of the HTML. This is a good idea. You certainly shouldn't be using onclick or onmouseover attributes in your HTML, and you should really avoid using the style attribute. But what about putting JavaScript inside a <script> element or CSS in a <style> element directly in the HTML?

Most people would recommend that you never do this, that you keep every line of your JavaScript and CSS in an external file. I'd say, never say never. There are certainly occasions I do this, although rare, but I think these scenarios make sense. So let me outline some of these scenarios where you may want to use inline JavaScript and CSS:

• The JavaScript or CSS is specific to one page

  You may be doing something really specific, such as some animations or ajax in a web application interface, where this code won't be reused on any other pages on your site. In this case, you won't gain any benefits of reuse in an external file.

• The page won't be accessed very often

  If the page is an obscure page in your web application that users only access once, or only once every few months, then you won't gain the benefits of having the browser cache these external files. You'll actually slow things down by making the browser make two extra requests for the JavaScript and CSS.

• You just want to use a few lines of JavaScript or CSS

  This is a common scenario with a lot of JavaScript libraries. The instructions often involve including an external file, then putting maybe 1-3 line of JavaScript on the page that initializes some widget. It would be totally wasteful to create an external file containing only 1-3 lines of code. The time wasted downloading an extra file would counteract any benefit gained from caching the file later.

These scenarios don't happen so often. As long as you don't care about the browser caching the CSS and JavaScript separately, and you don't need to reuse the CSS and JavaScript throughout your site, or it's just a few lines of code that isn't worth caching, I see nothing inherently wrong with using inline JavaScript and CSS. Your visitors won't notice or care. It's even valid still, as long as you keep the <style> in the <head> and wrap your JavaScript in a CDATA (for XHTML). So if it makes things a bit easier for you, I say go for it.

Joe tagged me. So now I have to tell you 5 things that the blogosphere doesn't know about me.

I know, these things are totally boring, and you didn't come here to learn about my pets, so I'll try to keep them slightly interesting and on topic:

1. I ran a number of BBSes from 1993-1995. They were called "The Dreaming" and "Pepperland", and my handles were "Morpheus", "Zippo" and "Fone Bone".

2. When the Internet came out, I thought it was just another crappy network for "lamers", something like AOL or CompuServe, and hoped it would go away. After a while I gave up and jumped on the bandwagon.

3. The first web page I made was in 1995 (Grade 10). It was a one-page psychedelic propaganda page for a hippie cult I was trying to start called "The Mellow Revolution". It was hosted on Tripod, but it doesn't exist anymore.

4. My mom has one of the most successful quilt web sites on the Internet called Victoriana Quilt Designs. When I tell people this, they assume I made it for her. In fact, I only taught her how to use FrontPage one day and she did all the rest by herself (okay, I helped her integrate PayPal and add login security, but that's about it).

5. I've climbed up and stood on one of the pyramids in Cairo. If you don't believe me, here's proof.

Well, I hoped I didn't bore you to death. Now I'm supposed to tag 5 other bloggers and see if they actually find out, give a crap, and follow through with a list. Tag, Emil Stenström, Roger Johansson, Tara Hunt, Mike Papageorge, and Dan Webb, you're it.

I had a bit of a shock this morning. I was logged in to Google, doing a normal search thing.. you know, click a link, click back, and then WHAM:

Crazy times we're living in. Now, I don't even need to tell you how this will affect Search Engine Optimization. Now there's a whole new technique those black hat marketing people can use to make their pages rank higher: Make them more useful!

Update: It seems pretty random. It disappeared on google.com even when I was logged in, but then it showed up when I was on google.ca and wasn't signed in. I guess it'll just be a random thing like moderation on Slashdot?

I'm going to debunk another myth that might keep you from trying out Ruby on Rails (or any other new server language). MYTH: Once you start using Rails, you have to do everything in Rails.

I wanted to integrate a forum into my new Rails site. So I took a look at the Rails forums out there and found a whopping three: Beast, RForum and Opinion. Unfortunately, they all suck. Ok, to be fair, they're all rather new, and are still in development. But they still suck.

At first, I was okay with using a crappy forum. But I didn't just need a standalone forum — I needed to totally integrate the forum into my existing site, users and all. But rails apps want to run on their own server. I don't know why, they're all claustrophobic or something. When you try to get two of them to share a server, one tends to peck the other's eyes out like it's a rails-powered cockfight.

So after way too much time spent cleaning up feathers and blood, I decided to give one of the classic PHP forums a chance. I decided Vanilla was going to be my forum of choice, and I got to work.

It turned out that it took me less time to integrate Vanilla with my Rails app than all the time I spent recoding routes.rb to make Beast work. Here's some tips to get a PHP app to coexist with rails:

1. Install the forum inside /public/

   PHP apps are very happy to live inside a subdirectory inside another site. They love it. So what better place to drop one than inside a rails app's public directory. (Try doing that with a rails forum).

   This also has the benefit of having a single domain, which makes sharing cookies slightly easier.

2. Let the rails app and php forum share a database

   This isn't a requirement, but it just simplifies things slightly. Vanilla uses a table naming convention like LMU_*, and I'm sure most other (non-rails) forums do the same, so the two can coexist fairly easily. This way you can do stuff like joins across your own tables and the forum tables.

3. Manipulate the forum tables from Rails

   Rather than share a single 'users' table (which is pretty much the only way you'd be able to get two rails apps to coexist in a single database), just add rows to the forum's user table every time a user signs up on your rails app. And of course, don't forget to use a foreign key to relate the two.

   Vanilla makes a single sign-on feature easy through a "Remember me" feature. Basically, if 2 cookies are set ('lussumocookieone' for the UserID, and 'lussumocookietwo' for the VerificationKey by default), then the user is automatically logged in. So all you have to do is look up (or write) the VerificationKey in LMU_Users and set these cookies whenever a user logs in to your rails app.

4. Delete PHP's cookies to destroy a PHP session

   This is a really easy hack. Just erase the 'PHPSESSID' and '_session_id' cookies, and the user will be logged out from the forum. This way you can have a single sign-out too.

Okay, this post got pretty specific. But the lessons can be applied to the coexistence of any server-side apps. Communicate via the database and cookies, and you can pretty much do anything.