Web Tutorial: The Wayang Progress Bar (Part 1/4)

In my University days, we studied HCI (Human-Computer Interaction). And somewhat unavoidably, we learned from a charming gentleman by the name of Peter Bickford, an expert in the field. I quote him below:

Switching to a watch cursor during the wait delayed the subject's departure for about 20 seconds. An animated watch cursor was good for over a minute, and a progress bar would keep them waiting until the Second Coming - or Windows 98, whichever came first.

More at http://web.archive.org/web/20040913083444/http://developer.netscape.com/viewsource/bickford_wait.htm#bio

Granted, this was maybe two decades ago, but his words still hold true. However, to keep this up-to-date, we'll need to roughly halve the waiting times mentioned. This is the iPad generation. Bandwidth and data transfer speeds have quadrupled. Instant gratification is the in-thing. People are getting used to obtaining information with a swipe of the finger. These days, it takes roughly 2 to 5 seconds of waiting time before the user will turn to you and holler "Ah hia! Your website broken lah, dey!"

With that in mind, we're going to create a Progress Bar. Ostensibly, this displays how much of the current page has been loaded, and should keep the user content to wait. Except that this isn't a real loader. It's just an animated bar designed to harness the user's attention span. Hence, what I like to refer to as the Wayang Progress Bar. If you're neither Singaporean nor Indonesian and don't know what wayang is, wayang kulit is a form of shadow puppetry which originated in Java, Indonesia, and essentially means, in local parlance, "purely for show".

Shadow Puppet

And that's exactly what the Wayang Progress Bar is; purely for show. It won't speed up your website, nor will it actually display how much of the site has loaded. Its purpose is merely to stall the user till your page is done loading!

This Wayang Progress Bar will have no graphics, because graphics take time to load and the whole point of the Wayang Progress Bar would be lost if it significantly increased waiting time. Instead, we'll be leveraging heavily on HTML, CSS and JavaScript.

This is your layout:

<!DOCTYPE html>
<html>
    <head>
        <title>Progress Loader test</title>
    </head>

    <body>
        <div id="loader" class="loader_box">
            <div id="loader_content" class="loader_content" style="margin-left:-500px;">

            </div>
        </div>
    </body>
</html>

Now add the CSS declaration to the head tag.

<!DOCTYPE html>
<html>
    <head>
        <title>Progress Loader test</title>
        <style type="text/css">
            .loader_box
            {
                width: 500px;
                height: 20px;
                border: 1px solid #777777;
                overflow: hidden;
            }

            .loader_content
            {
                width: 500px;
                height: 20px;
                background: #440000;        
            }
        </style>
    </head>

    <body>
        <div id="loader" class="loader_box">
            <div id="loader_content" class="loader_content" style="margin-left:-500px;">

            </div>
        </div>
    </body>
</html>

This is how it's going to look like at the moment:

Nothing fantastic, huh? Just a long rectangle. Not to worry, we're just getting started! 500 pixels is a rough guide. You may want to make the progress bar longer or shorter, but you'll need to adjust the margin-left property of the loader_content div tag accordingly.

Now, add this JavaScript snippet to your header tag. Also, add the JavaScript event handler to your HTML.

<!DOCTYPE html>
<html>
    <head>
        <title>Progress Loader test</title>
        <style type="text/css">
            .loader_box
            {
                width:500px;
                height:20px;
                border:1px solid #777777;

                overflow:hidden;
            }

            .loader_content
            {
                width:500px;
                height:20px;
                background: #440000;        
            }
        </style>

        <script>
            var loader;

            function start_loader(varloader)
            {
                loader=setInterval(function () {process_loader(varloader+"_content")}, 500);

                function process_loader(varloadercontent)
                {
                    var inc=1;
                    var marginleft = document.getElementById(varloadercontent).style.marginLeft;
                    marginleft=marginleft.replace("px","");
                    marginleft=parseInt(marginleft)+inc;

                    if (marginleft>=0)
                    {
                        document.getElementById(varloadercontent).style.marginLeft="-5px";
                    }
                    else
                    {
                        document.getElementById(varloadercontent).style.marginLeft=marginleft+"px";
                    }
                }
            }
        </script>
    </head>

    <body>
        <div id="loader" class="loader_box">
            <div id="loader_content" class="loader_content" style="margin-left:-500px;">

            </div>
        </div>

        <script>
            start_loader("loader");
        </script>
    </body>
</html>

For more about JavaScript timer functions, click here: http://www.w3schools.com/js/js_timing.asp

Now refresh your browser, sit back, and enjoy the magic!

How do I use this?

You can slip the loader div anywhere you please. Though I'd recommend having it just after your body tag.

What the code does

There's an outer div with the id loader_box. And an inner div loader_content, colored brown (#440000), within it. The loader_content div is offset 500px to the left initially. The overflow:hidden CSS value ensures that any part of loader_content that goes out of loader_box is invisible.

As soon as the timer function process_loader() is triggered, it progressively alters the margin-left property of loader_content so that it appears as though the loader_box is filling up! You can adjust the speed of the animation by changing the value highlighted below. This line basically tells your browser to trigger the process_loader() function every 500 milliseconds, so decrease the value if you need to speed it up!

loader=setInterval(function () {process_loader(varloader+"_content")}, 500);

This Wayang Progress Bar should be good for an average page lag of 20 seconds. If you need a longer time, adjust the animation speed or the length of the Wayang Progress Bar.

Cool, eh? But that's not all. Look at the JavaScript in the If-Else statement. If the margin-left value exceeds 0px, which means the box is full, the display automatically keeps it at roughly 99%. So if it reaches 100% and your page is still not loaded, the user won't be asking why?

Let's make it pretty!

 Give your progress bar rounded corners! Add the following code to your CSS.

        <style type="text/css">
            .loader_box
            {
                width: 500px;
                height: 20px;
                border: 1px solid #777777;
                border-radius: 9px;
                overflow: hidden;
            }

            .loader_content
            {
                width: 500px;
                height: 20px;
                background: #440000;        
            }
        </style>

Now change the colour of your bar. For some cool color combos, visit http://www.colorzilla.com/gradient-editor/

I'm just going to go with a nice flamingo pink. This is CSS3, but you don't need to learn it all right now, we're just having a little fun.

        <style type="text/css">
            .loader_box
            {
                width: 500px;
                height: 20px;
                border:1px solid #777777;
                border-radius: 9px;
                overflow: hidden;
            }

            .loader_content
            {
                width: 500px;
                height: 20px;
                background: #ff4444; /* Old browsers */
                background: -moz-linear-gradient(top, #ff4444 0%, #ff9e9e 52%, #ff4444 100%); /* FF3.6+ */
                background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#ff4444), color-stop(52%,#ff9e9e), color-stop(100%,#ff4444)); /* Chrome,Safari4+ */
                background: -webkit-linear-gradient(top, #ff4444 0%,#ff9e9e 52%,#ff4444 100%); /* Chrome10+,Safari5.1+ */
                background: -o-linear-gradient(top, #ff4444 0%,#ff9e9e 52%,#ff4444 100%); /* Opera 11.10+ */
                background: -ms-linear-gradient(top, #ff4444 0%,#ff9e9e 52%,#ff4444 100%); /* IE10+ */
                background: linear-gradient(to bottom, #ff4444 0%,#ff9e9e 52%,#ff4444 100%); /* W3C */
                filter: progid:DXImageTransform.Microsoft.gradient( startColorstr='#ff4444', endColorstr='#ff4444',GradientType=0 ); /* IE6-9 */     
            }
        </style>

A This is just a simulation of how the final result will be. Get creative!

There are more enhancements you may like to consider for your Wayang Progress Bar. They'll be discussed in the following parts of this web tutorial.

Next...

How to turn your Wayang Progress Bar off! You didn't think I left that out, did you?

To the Strong and the Bold

With the introduction of HTML5, there has been a fair bit of confusion regarding the tags <strong> and <em>. Many developers have regarded these tags as replacements for <b> and <i> respectively. Even HTML Editors such as CKEditor and Adobe Dreamweaver have introduced these as defaults. Click on the  button in either of these applications and you're likely to get a <strong> instead of a <b>. Likewise, click on the button and you'll get <em> instead of <i>.

What people don't realize is that, unlike certain tags like <font> and <center>, <b> and <i> have not been deprecated. That's right, they are part of the HTML5 specification.

HTML5 Specs for the STRONG tag: http://www.w3.org/TR/html5/text-level-semantics.html#the-strong-element
HTML5 Specs for the EM tag http://www.w3.org/TR/html5/text-level-semantics.html#the-em-element

What exactly are these tags for?

We'll start with the difference between <strong> and <b>. Once you understand this, <em> and <li> should follow quite easily.

On the surface, to the human eye, there is no difference. <strong> and <b> both turn text bold, as shown below.

This text is <b>bold</b>
<br />
This text is <strong>strong</strong>.

This text is bold.
This text is strong.

The difference is that <b> is purely cosmetic, while <strong> has semantic significance. You use <strong> when you want to put some extra weight on a word, to increase its importance. You use <b> when you only want to make text bold.

With semantic significance, you can change the entire meaning of a sentence.

He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.

Contrast this to the code below. The headers are rendered with the <b> tag, not because they have any special significance, but because it would look nicer to have them in bold.

<table>
   <tr>
                <td><b>Header A</b></td>
                <td><b>Header B</b></td>
                <td><b>Header C</b></td>
                <td><b>Header D</b></td>
   </tr>
   <tr>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
   </tr>
   <tr>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
   </tr>
</table>

Result:

Header A	Header B	Header C	Header D
Data	Data	Data	Data
Data	Data	Data	Data

Of course, one could argue that we could just solve this thing with CSS (and you'd be quite right), but CSS is not the subject matter here. Just to be pedantic, the CSS descriptor font-weight:bold is also purely cosmetic.

Yes, to the human eye, this still makes no difference. <strong> and <b> will still appear as bolded text. It will, however, make a great deal of difference to a machine. The builders of the HTML5 specification probably intended for semantic markup to play a part in SEO (Search Engine Optimization). Thus, the separate tags even though they both look the same to you. Because if everything in bold was important, that would lead to a lot of cranky search results!

New fun stuff!

Apparently, you can also nest <strong> tags.

<strong>He never said he stole <strong>her</strong> jewels.</strong>

To the human eye, this does nothing more than bold the entire block of text. When a machine reads this, however, it's supposed to place importance on the sentence, and even greater importance on the word "her" within that sentence.

What about <em> and <i>?

So now, apply everything I just said about <strong> and <b>, and apply it to <em> and <i>.

What does this mean for future development?

Well, at this point in time, until everyone gets used to the idea and starts applying this standard, you could probably get away with using the tags interchangeably. But looking to the future, you're advised to adapt. Heaven knows when HTML5 syntax will finally stop fluctuating though, so take your time.

Until then, fortune favours the <b>, so go get <em>!
T___T

Five Things Not to Say to a Web Developer

In the course of searching for a web developer, a company is definitely going to go through a few resumes and it's almost a certainty that interviews will be conducted. However, depending on the size of the company, there will be different kinds of interviews being conducted. Those dealing with the technical aspect, and those dealing with the human resource aspect. And assuming both interviewers stick to their scope, all's well and good.

The problem tends to begin when a non-technical person (usually HR personnel) is sent to conduct the only interview for a web developer. Miscommunication can arise, not because HR is unprofessional per se, but because HR is rarely equipped to understand the technical aspects of a web developer's repertoire.

Consider this conversation.

HR: May I know more about your work experience in your last company?

WD: Well, my first project was a CRM. It was on a PHP MVC platform and I was working under the Team Lead, and put in charge of testing the Reporting functions. After a year, I was put solely in charge of a medum-sized e-commerce portal with a ERDBMS back-end...

HR: Wait, what's a CRM?

The one nice thing about putting oneself through the hassle of an interview, getting dressed up and all, is that you get to brag about stuff you've done. But bragging to someone who can't tell a XML tag from an dog tag makes the entire exercise pointless.

Still, this seems to be inevitable and bearing that in mind, here are some things to avoid saying to a web developer interviewee. These things are almost guaranteed to produce an uncomfortable moment as the interviewee struggles with a mental eye-roll, or actually produces a look which plainly says Why am I talking to you, exactly?

Looking to the future.

1. Where do you see yourself in 5 years' time? Do NOT ask this question.

This has got to be the most overused interview question on the island. Unless you're hiring a web developer with intent to promote him AND you actually have some kind of company hierarchy that allows for this (three levels of reporting doesn't count), don't. Just... don't.

HTML is a programming
language? Really?

2. Get your terminology right.

It's fun to throw technical terms around like you mean it. But unless you have a pretty good idea what they
actually are, try to avoid doing so. Don't, for example, refer to HTML as a "programming language". Or MVC. Or AJAX, for that matter. If such distinctions are lost on you, you may want to consider letting someone else handle this part of the interview.

For more on this subject, see http://inventwithpython.com/blog/2013/12/15/why-is-html-not-a-programming-language/

Yes, I can fucking bold text.

3. Don't ask if he can bold text, or anything stupid like that.

I actually had an interviewer ask me this once before. Can you bold text? Italics? How about changing the colour? He must have caught the dude-are-you-fucking-with-me look on my face because he swiftly moved on.

Web development isn't the most glamourous job in the world. The pay can be shitty, the hours worse. And sometimes we're forced to produce work we're not proud of, work we would never acknowledge unless a loaded gun was pointed to our heads, just to pay the bills.

That said, web developers do have a certain amount of pride. Web development is a craft, and should be treated with a modicum of respect. Don't ask a web developer if he knows how to do these very simple, very banal tasks. That's insulting. Unless you just want a glorified HTML coder to write your EDMs. Schoolkids nowadays know HTML. Schoolkids can bold text, dammit.

THIS is web dev.

4. How many hours a workday would you say you spend programming? Do NOT ask this either.

I remember the first time I was asked this question. My first reaction was, is this some kind of abstractly worded test question I had to answer with tact and wisdom? I swiftly came to the conclusion that the truth was horrifyingly simple - I was being interviewed by an old-fashioned factory-style pencil-pusher.

Web development is more than just programming. There's UI, database, requirements gathering, the works. Hell, programming is more than just programming. I would hope the average programmer spends far more time testing than actually coding!

In other words, anyone who can ask this question with a straight face obviously has nary a clue regarding the process. You do not want to come off as that person.

Developers come in all shapes,
sizes and skin colours.

5. Don't ever suggest that he stands a better chance due to his nationality.

If you need someone who can speak a English fluently, sure, you would be justified in wanting a local. And even that is no guarantee that his communication skills are effective enough. Or perhaps you require this prospective hire to travel. Fair enough. But if you just want a local in order to boost your headcount quota, be smart enough not to mention it to his face.

You're hiring him and his skill-set, not his passport. You're hiring him because he represents the best value for your money. Anything less than that is a put-down.

And if you still manage to hire this person despite that horrific gaffe, do bear in mind that few things are more detrimental to your operation than a professional with zero pride. Unless he's entry-level. In which case, go to town on him because he's got to earn his dignity.

Before I sign off, any questions? Yes, I can bold text, smartass.
T___T

Synchronizing the Asynchronous

AJAX is a very useful technique of combining client-side and server-side capabilities to form a coherent whole. It drives many front-end UI features we see today and greatly extends the traditional client-server relationship. But it's not without its flaws. Chief of which, the asynchronous nature of AJAX may confound the programmer if not properly handled. The following is an example of what I'm talking about.

Let's say you have an interface with three textboxes. You want to enter a value into the first textbox, and upon the click of a button, the value will appear in the second textbox. And then the second textbox's value will be multiplied by two and appear in the third textbox. Wait a second, I hear you exclaim. You don't need AJAX to do that! Yes, that is quite right. Simple JavaScript should suffice. And should take the average programmer less than a few minutes. However, I'm trying to illustrate a point about AJAX here as simply as possible, so bear with me.

Below should be your HTML front-end:

<!DOCTYPE html>
<html>
   <head>
      <title>AJAX test</title>
   </head>

   <body>
      <input type="text" id="txtNumber" value="0">
      <input type="button" value="Display">
      <br />
      <input type="text" id="txtDisplay" value="0" disabled="disabled"> Original
      <br />
      <input type="text" id="txtDisplayTimesTwo" value="0" disabled="disabled"> x2
   </body>
</html>

This is what your interface should look like:

Original
x2

Now for the purposes of this exercise, we're going to prepare two server-side scripts. The following examples are in PHP, but you may use any server-side language you're familiar with.

display.php

<?php
$number=$_GET["number"];
echo $number*2;
?>

displaytimestwo.php

<?php
$number=$_GET["number"];
echo $number*2;
?>

So far so good? Now we're going to add JavaScript to your HTML file. And an onclick JavaScript handler to your button.

<!DOCTYPE html>
<html>
   <head>
      <title>AJAX test</title>

      <script>
      function display()
     {
          var number=document.getElementById("txtNumber").value;
   
         if (window.XMLHttpRequest) 
         {// code for IE7+, Firefox, Chrome, Opera, Safari
             xmlhttp=new XMLHttpRequest();
         }
          else 
         {// code for IE6, IE5
             xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
         }
   
          xmlhttp.onreadystatechange=function() 
         {
             if (xmlhttp.readyState==4 && xmlhttp.status==200) 
            {
                document.getElementById("txtDisplay").value=xmlhttp.responseText;
            }
         }

          xmlhttp.open("GET","display.php?number="+number,true);
          xmlhttp.send();
      }

      function displaytimestwo()
     {
          var number=document.getElementById("txtDisplay").value;
   
         if (window.XMLHttpRequest) 
         {// code for IE7+, Firefox, Chrome, Opera, Safari
             xmlhttp=new XMLHttpRequest();
         }
          else 
         {// code for IE6, IE5
             xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
         }
   
          xmlhttp.onreadystatechange=function() 
         {
             if (xmlhttp.readyState==4 && xmlhttp.status==200) 
            {
                document.getElementById("txtDisplayTimesTwo").value=xmlhttp.responseText;
            }
         }

          xmlhttp.open("GET","displaytimestwo.php?number="+number,true);
          xmlhttp.send();
      }
      </script>
   </head>

   <body>
      <input type="text" id="txtNumber" value="0">
      <input type="button" value="Display" onclick="display();displaytimestwo();">
      <br />
      <input type="text" id="txtDisplay" value="0" disabled="disabled"> Original
      <br />
      <input type="text" id="txtDisplayTimesTwo" value="0" disabled="disabled"> x2
   </body>
</html> 

If you're familiar with AJAX, you will understand from the above that we've just added two JavaScript functions, each with a server-side call to their respective PHP files. Upon clicking the button, the value in the textbox will run these functions, one after the other.

Try it. What happens? A big fat nothing. The code was syntactically correct. But, the asynchronous nature of AJAX, so handy most times, works against you here. Instead of running in sequence, it tries to run display() and displaytimestwo() at the same time. And ends up clashing because displaytimestwo() and display() both require the object named xmlhttp! A solution here might be to use different variable names. But that's just a band-aid over the root of the problem. A far more elegant solution would be to force these two functions to run in their intended sequence. That's where your foundation in structured programming comes in.

Alter the code as follows:

<!DOCTYPE html>
<html>
   <head>
      <title>AJAX test</title>
      <script>
      function display()
     {
          var number=document.getElementById("txtNumber").value;
   
         if (window.XMLHttpRequest)
         {// code for IE7+, Firefox, Chrome, Opera, Safari
             xmlhttp=new XMLHttpRequest();
         }
          else
         {// code for IE6, IE5
             xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
         }
   
          xmlhttp.onreadystatechange=function()
         {
             if (xmlhttp.readyState==4 && xmlhttp.status==200)
            {
                document.getElementById("txtDisplay").value=xmlhttp.responseText;
                displaytimestwo();
            }
         }

          xmlhttp.open("GET","display.php?number="+number,true);
          xmlhttp.send();
      }

      function displaytimestwo()
     {
          var number=document.getElementById("txtDisplay").value;
   
         if (window.XMLHttpRequest)
         {// code for IE7+, Firefox, Chrome, Opera, Safari
             xmlhttp=new XMLHttpRequest();
         }
          else
         {// code for IE6, IE5
             xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
         }
   
          xmlhttp.onreadystatechange=function()
         {
             if (xmlhttp.readyState==4 && xmlhttp.status==200)
            {
                document.getElementById("txtDisplayTimesTwo").value=xmlhttp.responseText;
            }
         }

          xmlhttp.open("GET","displaytimestwo.php?number="+number,true);
          xmlhttp.send();
      }
      </script>
   </head>

   <body>
      <input type="text" id="txtNumber" value="0">
      <input type="button" value="Display" onclick="display();">
      <br />
      <input type="text" id="txtDisplay" value="0" disabled="disabled"> Original
      <br />
      <input type="text" id="txtDisplayTimesTwo" value="0" disabled="disabled"> x2
   </body>
</html> 

Now type "10" in the first textbox, click the button, and what do you get?

Original
x2

What we basically did was to move the displaytimestwo() command to the middle of the function display(), just after the part where the AJAX is successfully called. Which means displaytimestwo() runs only after display() runs!

Remember! When your code fails, make AJAX-ments!
T___T

The Ecology of the Modulus

The four most commonly-used mathematical operators in programming are obvious - addition (+), subtraction (-), multiplication (*) and division (/). But there's a fifth.

The Modulus, commonly known as "Remainder", is used to derive the remainder from a dividend (a) and divisor (b). Basically, when you ask for the Modulus of 3 and 2, you get 1. (3 divided by 2, remainder 1) That is what you would get, assuming that both your dividend and divisor are positive whole numbers.

The Modulus can be an elusive and frustrating operator as its execution varies from language to language. Useful enough to warrant fairly moderate usage, yet not frequently-used enough to stick in the mind. I have found myself looking it up repeatedly whenever I needed to use it because I would forget it soon after. Admittedly this happened because at that time, I was switching between languages, a necessary evil when one is  maintaining legacy code.

Just for posterity, I have included the various forms of the Modulus in some of the different languages I had to use it in. (Note that this list is by no means exhaustive)

Language	Operator	Example
PHP, C++, C#, JavaScript, Flash ActionScript, Python (and most other languages whose syntax is based on C)	%	a % b
Coldfusion, Basic, VBScript	mod	a mod b
SQL	mod(x,y)	mod(a,b)

So, what can the Modulus do for you?

Beyond the obvious function of giving you the remainder when a is divided by b, The Modulus helps you determine if a given number is odd or even. Or if the number is divisible by another number. Basically, if x%2 equals 0, then x is an even number. If x%y equals 0, then x is divisible by y. Again, this only works if both your dividend and divisor are positive whole numbers, so adjust your exceptions accordingly!

Thus, it also follows that the Modulus is great at pattern sequences.

If, for example, you need a table with 5 rows that is colored differently every alternating row, you might do this:

<table>
   <?php
     for ($i=1;$i<=5;$i++) 
    {
   ?>
  <tr>
      <td style="background-color:<?php echo ($i%2==0?"#AAAAAA":"#EEEEEE");?>">Test row</td>
  </tr>
   <?php
     }
   ?>
</table>

That would net you this:

Test row

Test row

Test row

Test row

Test row

 Or if you wanted a table of 20 rows with a different colored row every 5 rows...

<table>
   <?php
     for ($i=1;$i<=20;$i++) 
    {
   ?>
  <tr>
      <td style="background-color:<?php echo ($i%5==0?"#AAAAAA":"#EEEEEE");?>">Test row</td>
  </tr>
   <?php
     }
   ?>
</table>

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Test row

Note that CSS3 has built-in this particular functionality without the need for coding. However, the point here is to illustrate, as simply as possible, the Modulus operator's capability.

In fact, try the above exercise with a nested loop. (see below) Or recursively. The possibilities are endless. And this is just the simple stuff!

<table>
   <?php
     for ($i=1;$i<=5;$i++) 
    {
   ?>
  <tr>
   <?php
        for ($j=1;$j<=5;$j++) 
       {
           if ($j%2==0) 
          {
   ?>
      <td style="background-color:<?php echo ($i%2==0?"#AAAAAA":"#EEEEEE");?>">x</td>
   <?php
           }
           else 
           {
   ?>
       <td style="background-color:<?php echo ($i%2==0?"#EEEEEE":"#AAAAAA");?>">x</td>
   <?php
            }
        }
   ?>
   </tr>
   <?php
     }
   ?>
</table>

x	x	x	x	x
x	x	x	x	x
x	x	x	x	x
x	x	x	x	x
x	x	x	x	x

Signing off with much Modu-love
T___T