Well, I’m not any exception, until I got acknowledged of a JS project called php.js originally started by Kevin van Zonneveld. I have used this in more than one of my projects and it just works perfect for me without any hassles, so maybe I should feature it in return.

You can tell, the project is all about porting PHP functions into Javascript. Yes, many of those are there, but under a different name or one step away – like PHP’s sin and JS’ Math.sin. Some others however, are not that easy to obtain in Javascript – I’m talking about md5, date, serialize etc. and those array stuffs. It even deals with file system, with the support of the XMLHttpRequest object (therefore these functions may fail if the browser doesn’t support it).

The project is active and it seems Kevin, with the great help from other contributors, is constantly expanding it. A list of available (successfully ported) methods can be found here – nearly 300 (!) each with detailed code and examples. You can just copy the function code and embed it into your script to start using right away, or download the full packages for everything.

I, for myself, can’t understand how there are such good people in this world: put huge effort into something just to give away, expecting nothing in return.

Are you using of this wonderful project in your own? If so how about featuring it?

Whether you are a web designer or a server side guy, there are certain times when you must get your hands dirty with HTML codes. Since HTML is rich, and even getting richer with the coming HTML 5, many HTML coders tend to do it improperly to achieve what could have done differently (and better). This results in many bad habits that should be avoided.

Table designing

No, tables just won’t die (soon), and I’m not insisting them to. They will live happily so long as this internet still has some tabular data to display, or until W3C decides to replace “table” by “chair” which obviously sounds cooler for developers to write.However, for those who are still using tables to align the paragraphs, links, images, and other HTML objects out there, please dust away the cells and begin playing around with CSS design. There are some very good reasons why:

• Codes with table design are almost totally unreadable compared to CSS design
• Tables increase your page’s file size significantly in most cases
• Table design means more work for the browser, especially when you have nested tables (as most of table designers do)
• Finally, regardless of all those conservative heads out there, with all of its advantages, CSS design is the future of the web. Take a look around, now every design job posted on every freelance site includes this line: MUST BE IN CSS AND NOT TABLES, sometimes with 3 or more exclamation marks (!) following.

So, don’t be easy to yourself. In your next project, begin CSS. Don’t let tables’ “ease of use” prevent you from following the standard. Anyway, who told you that designing using CSS was that difficult to learn?

Relying on Javascript

I bet that you’ve seen this bunch of codes more than once:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<script type="text/JavaScript">
<!--
function MM_swapImgRestore() { //v3.0
    var i,x,a=document.MM_sr; for(i=0;a&&i<a.length&&(x=a[i])&&x.oSrc;i++) x.src=x.oSrc;
} 
 
function MM_preloadImages() { //v3.0
    var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array();
    var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++)
    if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}}
} 
 
function MM_findObj(n, d) { //v4.01
  var p,i,x;  if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) {
    d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);}
  if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n];
  for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document);
  if(!x && d.getElementById) x=d.getElementById(n); return x;
} 
 
function MM_swapImage() { //v3.0
  var i,j=0,x,a=MM_swapImage.arguments; document.MM_sr=new Array; for(i=0;i<(a.length-2);i+=3)
   if ((x=MM_findObj(a[i]))!=null){document.MM_sr[j++]=x; if(!x.oSrc) x.oSrc=x.src; x.src=a[i+2];}
}
//-->
</script>

Oh, you’ve not seen it ever? Well, I lost my bet… Under the name of a VERY popular HTML editor, these codes are VERY popularly used, for a VERY popular effect that you must have known (this time I bet, really!!!) – the rollover, or “image-swapping” animation. Basically, there are 2 images involved: one for “normal” state:

and the other for “hover” state:

When the mouse hovers that gray image, the orange one is shown up, which creates a “lighten up” effect and somehow tells the user: Click me, I’m sexy & ready.

So what’s wrong with this very cool method, you ask?

• First, the code is huge. See above. And you must implement a “preloading” feature too, or it will take time for the hover-state image to be downloaded and shown up.
• Second, this technique is totally useless if the user disables JavaScript.
• Third, as we have 2 different images here, the number of requests to server is increased.
• And, don’t you know that browser is painfully slow in displaying an image?

Convinced? Here is the most common solution: Instead of using two images for two different states and make them swap, the HTML experts out there are using just one background image for BOTH states and some attribute of CSS called “background-position” to create a “rollover” effect that doesn’t hurt. I won’t go into details here, since it will in no doubt lengthen this article unnecessarily, but I have a good resource for you. Using this very simple technique, all the disadvantages listed above will just vanish.

With all this blahblah, however, I’m not stressing on a rollover effect alone. What I’m trying to tell is that sometimes you just don’t have to Javascript at all. We know that not everything can be done in CSS instead of Javascript, as JS has undeniable pros. But keep in mind that pros come with cons, and whenever you can, avoid it.

Overusing images

I know, “A picture speaks a thousand words” as they say. What a pity that doesn’t apply in web designing – if the term “picture” implies an “text displayed as image”. Following the innovation of Web 2.0 where only content matters, images are being reduced from websites, and yes they have good reasons to do so:

• Images weigh. A small image can easily weigh ~10KB, that is (how coincident) ~1000 words. If you have a busy site, that image can easily cost you gigabytes of bandwidth each month. It’s money. So how to save some of that bandwidth/money? Use some meaningful texts instead. How about replacing that fancy button with the “Click me” text now?
• Those are fat, slow. Images are not an exception. A site loaded with images will load v……e….r…….y s…..l….o……..w…….l…..y. And researches have shown that 4 seconds is the maximum loading time a web surfer accepts (some say that it’s 8 sec anyway). Then, if your page takes more than ten seconds to load, unless it has some real pictures about aliens on Mars, users will leave. So, following Mc Donald’s rule: if you want your visitors to stay, don’t make them wait.
• Images are very bad in term of accessibility. Web visitors with limited seeing ability tend to use the built-in “Text Size” tool available in almost all browsers to increase or decrease the size of text, thus can have a better reading experience. With images, they simply can’t. Very bad, I must repeat.
• Pages with images all over the place suck in printing. When the acceptable print resolution is 300dpi, normal web image resolution is only 72 dpi or so. This results in a terrible print quality.

With all these proofs (and maybe more that I’ve not come up with), along with the fact that 90% of images on your page are totally replaceable by plain text, let there be text!

Everything is <p>

More than often I encounter websites in which every text content is contained in <p>…</p> tag pairs, where the titles and headers <p>’s are formatted to be bold, with bigger size, underlines etc. to differentiate from other normal <p> elements.

It is a misuse of <p>.

<p> is intended to display paragraph content, while heading tags like <h1>, <h2>, <h3> etc. are for heading and title texts. Though you can always use CSS to make a specified <p> to stand out of the crowd to be an article title, and it seems to make no difference or problem in displaying or accessibility or readability or whatsoever, it’s perfectly wrong. According to Wikipedia, <h> tags have something to do with “the document’s structure and organization” and “some programs use them to generate outlines and tables of contents”. So, to human eyes, your page may look like a document, but with cyber programs, it may not. Talking about SEO this misuse will likely result in a low rank in Google.

So here’s the final line: let <p> be <p>. There’s no special <p> in this web development world, please.

“Look what I can do” style

(I must admit, this is the bad habit I’m trying to give up too).

Thanks to the open source wave in web development, now creating cool user experiences is easier than ever. Back in the old days, a drop-down menu was a breathtaking effect, and you attracted user attention by making the text blink. Now, it’s a massive number of killing javascript stuffs out there: slide up down right left, fading in and out, shaking, scaling, folding, bouncing, exploding, fish eye, light box, drag and drop… each with one or two lines of code. And you don’t have to care about cross browser compatibility, as they (jQuery, mootools, script.aculo.us, Dojo) have done that already for you. Web developers, we’re at your service!

Ok, wait…

Since effects are all cool, you may want to show them off. “Look this, and this, and this, hey, impressed?” that’s how your website is saying. But (I hate this word, but I have to use it yet again), beware, those fancy stuffs may be something that make your site not accessible. Like, a user may have to click on a link and wait for the invisible div to slowly fade in just to read its content. Isn’t it something tiring? Why must the content be one click (and five seconds) away from him? Why wasn’t it there from the beginning?

Unless you have a very good reason to, don’t ever hide your content from the users. Sure, fading divs are candies for the eyes, but a rushing user’s eyes don’t need any candy. By the way may I ask who’s not rushing today?

What else?

Actually I had something more in mind before starting this articles, such as “Click me” linking, frame structure, Ajax overuse etc., during writing I got a feeling that those are too much into details, so I decided to omit them. Maybe I will put them back into the table (not that table) in the near future.