phoenixheart - portfolio & more » Client stuffs

Deal with browser incompliance using jQuery

phoenix.heart — Mon, 27 Apr 2009 07:34:51 +0000

Without a doubt, being a serious web guy you want your new site to look perfect on web browsers. Yes, mission would be simple – or sound simple – if there wasn’t something called browser wars for such a long time without any glorious winner (yet). The stupid result is, we poor web designers and programmers are still hopelessly struggling to keep our sites look the same on Internet Explorer (DIE PIG, DIE!!!), Firefox, Opera, Safari, just to find out that the oh so cool banner suddenly disappears from that new boy Chrome. FYI (psst) that was when I decided to stick with web that I started to learn cursing and swearing.

I am so proud to say that I decided to stop supporting IE 6 to save myself some precious life years and keep my head from getting bald long ago. But still, those guys in Microsoft they have IE 7 and 8 to haunt us. And despite of the so-called W3C standards, each of the remaining major browsers renders the pages differently here and there – margins, paddings, form elements, and so on. To deal with them, we use “hacks”. Perhaps the most well known hack is one below, called “conditional comments”:

When this technique is great, it has two limitations. First, only IE is taken into account. When most of the time dealing with IE takes the majority, there are still cases when your sites looks different on Firefox, Safari, Opera etc. Second, the HTML code looks very ugly and unprofessional – just like we are humbly telling: sorry this is beyond my control… I must use a hack here… and here… sorry again…

Then today when looking for a better solution, I stumbled upon a much better method that overcomes all of our current problems – well, sort of. The idea behind it is using jQuery to detect the browser and its version, then add the corresponding class names into the tag. For instance, if the visitor uses Internet Explorer 7, then “.browserIE” and “.browserIE7″ are added. Then, in our CSS we specify the styles for this browser:

#aPainInThe4ssElement
{
    /* generic styles for this pain */
}
 
.browserIE7 #aPainInThe4ssElement
{
    /* styles for this element on IE 7 */
}
 
.browserFirefox #aPainInThe4ssElement
{
    /* styles for this element on all Firefox browsers */
}
 
.browserSafari2 #aPainInThe4ssElement
{
    /* styles for this element on Safari 2 */
}

My hat off to Jon for this brilliant idea. Now dealing with different browsers is just a piece of cake!

Now the only thing I regret of is what took me so long to find out this solution.

php.js – Javascript equivalents for PHP functions

phoenix.heart — Wed, 11 Feb 2009 15:59:58 +0000

Being a PHP developer, there must be certain times when you have to deal with Javascript. And if you’re rather confident with PHP when in the meantime suck at JS just like me, you must have more than once googled for the JS equivalent of that very useful/powerful base64_encode, or htmlentities, or array_merge, or strpos, you_name_it.

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?

Google Search in an AJAX’ed way

phoenix.heart — Thu, 25 Dec 2008 08:07:40 +0000

I have a good news and a bad news for today. The bad news is, I got hit by a f-king drunker several days ago in a traffic accident (Saigon’s traffic is pure shit) and had to take some macro surgeries. The good news is, due to this accident I have some free time to think and do something – sense and nonsense, just for my habits.

So yesterday, this pal of mine showed (off) a web project he’s taking part in – a site called “HeyGoo“. This site uses Google’s AJAX Search API (and Yahoo’s too, I’m not sure) to find and display result in an AJAX’ed way – that is, no pagination involved, instead users have to scroll to bottom for the next results to be shown up. Rather interesting, eh?

Well, my friend he seemed to be very proud of this project and putting all his hope to its success, so I didn’t want to discourage him. But honestly, I don’t see it as any revolution. Not talking about the old design with tables everywhere, the annoying target=”_blank” anchors and the so-cliché logo, I pointed out for him some problems the site was having:

The search results are not so good. I searched for something on Google and it returned some hundreds of results, when HeyGoo told me it couldn’t find any. I don’t know why, hey, at least it is using Google Search API no?
There are certainly times that a user want to go to page, say, 3571, to see if his new forum ever reaches to Google. He can do that very easily with any “normal” search engine out there, but not with this HeyGoo where he must scroll 3570 times.
Biggest problem: the site currently doesn’t care about the loaded results. New results are appended, appended, appended, when old ones are still there in the top. Imagine how much memory the poor browser has to use up for this curious guy who’s scrolling over 317 pages and counting.

With all these drawbacks vs. the only ajax advantage (personally I don’t see it as an advantage but another failure however), I doubt this site will do anything big. Anyhow as a friend I still wish it the best.

Now to the main part: despite of my skeptical thoughts, I still see the AJAX dynamic scroll content something interesting, and might be useful sometimes. So I sit down and wrote my own (very basic) version of the AJAX Search, where no pagination is involved and you must scroll for something new It took me 30 minutes for the core, and some 30 more for the layout tweaks. Before getting into the code, you can see the final working result here.

It’s rather simple. The whole “trick” was done in 2 part: the client JavaScript, and the server PHP.

1. The JavaScript

As usual, jQuery is my choice. First, bind to the “submit” event of the search form to handle searching.

$("#f").submit(function(e){
    e.preventDefault(); 
 
    // don't search if there's a search in action, or the form is not valid
    if (busy || !validateForm(this)) return false;
 
    $("#result").html("");
    $("#loading").fadeIn();
    var q = $("#q").val();
 
    // indates that there's a search on the stage
    busy = true;
 
    // do an ajax call
    $.ajax({
        url: "search.php",
        data: $("#f").serialize(),
        success: function(msg){
            $("#loading").fadeOut("fast", function(){
                $("#result").html(msg);
                $(document).data("start", 0);  // the start position of result is 0, since this is the first page
                $(document).data("q", q);      // save the last used keywords
                expired = false;                    // the search has not expired (just started ;))
                busy = false;                       // not busy anymore, ready for the next search
            });
        },
        error: function(){
            $("#loading").fadeOut("fast", function(){
                // do something here?
                busy = false;
            });
        }
    });
});

With the Dimension plugin now natively integrated into jQuery version 1.2.6, it’s 4 lines of code to detect if the user has scrolled to the bottom of the page and go get the next results.

$(window).scroll(function(){
    if ($(window).scrollTop() == $(document).height() - $(window).height()){
        searchMore();
    }
});

Now, the searchMore() function:

function searchMore()
{
    // if the site is busy with another search, or if the search has expired
    // (no more results can be found), don't search
    if (busy || expired) return;
 
    // if we don't have a previous search, don't search
    if ($(document).data("q") == "") return;
 
    // i'm working, i'm working...
    busy = true;
 
    // the start page is increased by 1
    $(document).data("start", $(document).data("start") + 1);
    $("#loading").fadeIn();
 
    // make another AJAX call
    $.ajax({
        url: "search.php",
        data: "q=" + $(document).data("q") + "&start=" + $(document).data("start") * 10, // multiplied by 10
        success: function(msg){
            $("#loading").fadeOut("fast", function(){
            	// we have the next result, perfect
            	// append it into the current result
                $("#result").append(msg);
 
                busy = false; // not so busy anymore
            });
        },
        error: function(){
            $("#loading").fadeOut("fast", function(){
                // do something here?
                busy = true;
            });
        }
    });
};

There, the JavaScript is almost done. Of course there is a “validateForm()” function, but I guess it’s not necessary to include it into this post…

2. The server stuff

In order to retrieve the search results from Google, there are at least 2 ways:

Using its AJAX API. Unfortunately, for some mysterious reasons, this didn’t work so well with me, as only 8 first pages can be retrieved. Any attempt to get the remaining results were answered with a 400 bad request error. I guess I missed something, maybe API or ATM but hell with it.
Making use of the traditional and very powerful cURL. My choice

Here is the entire content of my search.php page.

$url = 'http://www.google.com/search?hl=en&q=' . urlencode($_GET['q']) . '&start=' . intval($_GET['start']);
 
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $url);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_REFERER, $_SERVER['REQUEST_URI']);
$body = curl_exec($ch);
curl_close($ch);
 
// do a simple preg_match to get the results
// let's pray that Google won't change its HTML structure for search results so soon ;)
preg_match('/(.*?)
/i', $body, $matches)
 
// no match?
if (empty($matches) || empty($matches[1]))
{
    if (intval($_GET['start']))
        die('No more results were found.
'); // set the "expired" JS var to true if this is called from searchMore() function
    else
        die('Your search did not match any documents.
');
}
 
// Google uses relative path for the image sources and video links on its search pages
// so we turn them into absolute links
echo utf8_encode(str_replace('"/', '"http://www.google.com/', $matches[1]));

That’s all of the core part. Of course we must prepare the index HTML with all the form, div, ol, img and so on before getting into action, but it’s not that tricky. So you can visit the result here and do some tests. Remember, this search tool is very basic, and I don’t have any intention to turn it into anything advanced

Bad practices (and how to avoid them) in web development

phoenix.heart — Thu, 23 Oct 2008 07:40:15 +0000

(Yet another post taken from the ruins of Tekaboo)

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:

<script type="text/JavaScript">

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

More than often I encounter websites in which every text content is contained in

…

tag pairs, where the titles and headers

’s are formatted to be bold, with bigger size, underlines etc. to differentiate from other normal

elements.

It is a misuse of

is intended to display paragraph content, while heading tags like

,

etc. are for heading and title texts. Though you can always use CSS to make a specified
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, 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
be
. There’s no special
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.

Things I hate on a web page

phoenix.heart — Wed, 22 Oct 2008 14:12:30 +0000

(This is one of my article from Tekaboo)

I’m a die-hard web surfer. Internet takes me at least 7-8 hours a day. I read almost everything web: tech and non-tech news, wiki, Google, mythology, game reviews, forum discussion, manga, even pr0n sexy content. After years of web surfing, I’ve come up with a list of things that I really, really HATE to see on a web page. I would almost close the page right away or never come back again if the site I attempt to visit:

1. Disables right clicking and/or text selecting

These are certainly on top of the most stupid Javascript techniques have been “invented”. It’s still a mystery to me why should one need to prevent right clicking on his site, and how effective such a method can be. Right, if you don’t want your precious text and pictures to be copied (read: shared), why bother posting them up? Just keep them to yourself, Mr Ego. Don’t you know that Javascript can be disabled in every browser? Lame.

2. Underlines those non-link texts

Yes, you may call me a picky old man, but believe me, it sucks to click on that underlined text and realize that it’s not a hyperlink at all. It’s almost a standard to reserve underlining for links, and this move against standards is not acceptable (at least, by me).

3. Opens links in a new tab

Or worse, in a new window – yes, even in tabbed browsers. Whenever I click on a link and it pops up a new tab, I go “WTF?” Hey, haven’t I no choice? If I want another tab, I can hold down my Control key and click (or simply middle-click, depending on the mood). There’s no point in trying to act smart reading my mind! And what is it for, that new non-resizable window? Thanks, but no thanks.

4. Plays the clock

More than often I see this text on the web pages: “The time is now 3:26:43PM, Tuesday, October, 07, 2008″. And it’s flickering with each tick. Heck, don’t they have some better news to show? I have a watch on my left wrist, a big rounded clock hanging on the wall before my eyes, another on the bottom-right corner of my desktop, yet another on my iPhone’s waiting screen. Do I need another clock? If you don’t have anything interesting to show off, just leave that space blank please.

5. Plays sound on background

This usually happens with teenagers’ blogs, and is one of the main reason I rarely visit them. Okay, totally agreed, that song is sweet and it fits your (mournful) mood. But goddammit, it’s 1:27AM here, you know? How cool is it to hear someone groaning at midnight? And where, for God’s sake, where is the Stop button?!? Help!

6. Has banner ads that won’t stay put

Many (or all) sites have banner ads, as they are the main income. It’s totally understandable. I don’t hate ads, really, and don’t use Adblock Plus’ “Adblock images…” feature very often. But there is one exception: those fancy sliding banners. Holy cow. I scroll down – they go down, I scroll up – they follow up. And flickering. And flashing, boom boom. Why don’t you let go of me? Leave me be!

7. Has marquees running across my screen

Similar are the marquees, the shameful ruins from 90s that you may still encounter on some sites about financial, forex, and (especially) weather. Thanks for the forecasting, wow, it’s cool, tomorrow is going to be hot in Ho Chi Minh city, 32 degrees in the morning, and raised up to 3… hey, don’t run away! STOP!

8. Only displays content on hovering

I’m pretty sure you’ve seen them: those sites that won’t display content upon loading. Only until you hover the mouse over the link, poop, a small div pops out with some text contained. Is it annoying? Yyyes! Hola webmaster Sir, I visit your site for the content, so would you mind showing it out from the beginning?

9. Has its content being nothing but a BIG Flash file

Sure, Flash is still one of the best innovations ever seen in internet. And seems like people are overusing it a bit… or two. Despite of all those rocking animations, I still miss my browser’s context menu… and the ability to select and copy texts… and the back button… and the read-while-loading content… and my iPhone’s browser… If your site is nothing but Flash, please make sure that an alternative HTML version is there, or you will lose 2 visitors: me (who?) and Google (WHO???).

10. Doesn’t provide an RSS feed

There were times when I happened to visit a site whose owner was a humorous guy and contents were very interesting, something like a how-to-squeeze-milk-from-a-bull article or so. Naturally I wanted to be kept informed about his next how-to’s, so I took a look at the top-right corner for that orange icon. It wasn’t there. “Of course, he may want to put it at the bottom” I thought. But again I was wrong. The RSS link was nowhere to be found. It simply means that the cool site didn’t provide any feed. It pissed me up. Is implementing a feed that hard? Isn’t it just an XML file which any XML writer out there can do? Bye.

11. Doesn’t offer a search box

As far as I get, searching has become the top-most action of web users, who use Google about 2 billion times a day. So unless you want to keep your site a mysterious castle looking, please give me a search box. If it’s a feature that’s out of your ability, you can always leave it to Google.

12. Opens my Outlook composing window when I click on that “Contact Us” link

Today, internet business is real (take a look at Google!), and real business means real customers. Guess I don’t have to stress how important customer relationship is. So it shocks me everytime I click on a “Contact Us” link just to see an Outlook’s New Message window pop up. Shame on you, how lazy you are, the site owners! Will it take you millions or years to add a real contact form?

13. Goes back to home page when I switch language

I’m always happy to see a page with multilingual support (one of the best is definitely Wikipedia). It beats me however, if the language switcher brings me back home. No, I don’t want to find my way through the chaos to that great post again, I want the page to stay the same, with only the language changed to my needs!

14. Makes me install additional software(s)

Just like everyone else (well, may not be including you), I’m a lazy web visitor that wants everything to be already prepared. “Silverlight is required before viewing this content”? Fine, I quit. “To play this media you need Quick Time installed”? Nevermind, goodbye. “Please update your Real Media plugin in order to hear the song”? No, I hate to restart my machine.

15. Has a m.arvello.us domain name

How many times have you heard of a abc.def.us domain name, following del.icio.us? Or that “er-without-e” trying to be Flickr? For the first time, it sounds brilliant. For the second time, not very creative but still OK. From the third time on, it’s lame. Really lame. I can’t expect a site to have interesting contents when its name is just a parrot. Script.aculo.us is an exception, but still jQuery is my winner.

16. Makes me “wait while redirecting”

“Welcome back! Please wait while we’re redirecting you.” is a common message that can be seen in almost every forum. The question is, why must I wait? Why don’t you take me directly to the page I want? I know, there’s always a direct link, but what’s the purpose behind that waiting time? More than once, I view the source code of the page (HTML and PHP alike) but it shows me no light – there’s absolutely no running process in the background that can give that “Please wait” message any sense. So, I decided that it’s just an old nonsense habit that needs to be buried for good.

17. And some more

I also dislike sites that have a “designed by ThisVeryProudCompany” bottom line, or pop up a Javascript message box (alert!) instead of HTML messages, or have CAPCHA’s all over the place etc. Call me picky then, but it’s hard to change someone’s mind…