David’s Web Development Blog

John Resig has a really informative writeup at his site detailing the process of finding and reporting browser bugs.  In addition to describing a good bug report, he gives the following direct links for reporting bugs for each mainstream browser:

• Mozilla/Firefox
• WebKit/Safari
• Internet Explorer 8
• Google Chrome / V8 JavaScript Engine
• Opera

Not only this - he also gives some advice regarding downloading the very latest builds of these browsers.  Testing with these builds allows the development teams to nip problems in the bud and will therefore save you and many other developers future headaches.

Here’s some links for downloading the latest browser releases:

• Firefox Nightly Release
• WebKit/Safari Nightly Release
• IE 8 Betas, IE 8 Weekly Builds
• Google Chrome Nightly Builds
• Opera Desktop Team Blog

(via John Resig’s blog)

So you have your webpage.  And you have your visitors.  You’ve spent all your time trying to make a cool visual and interactive experience, but chances are you’re viewing your webpage mostly from the cache, and you never realize how slow your webpage is actually loading for everyone else, what with all of those images used in the layout.

Try deleting your browser cache and loading your page cold.  Kinda slow?  Here’s some things you can do to speed it up (many of these tips are from Yahoo developers):

1. Cache your dynamic webpages.

TONS of webpages these days are displayed dynamically, mostly from PHP-based webpages.  The classic setup is to have PHP fetch page data from a database, commonly MySQL.  So what’s the problem?  It’s slow.  It crashes when too many visitors try to access the database at the same time.

It’s a pity, too, since though these users are fetching “dynamic” content, most of them are actually fetching the same data.  In other words, data that might as well be a static HTML page until it’s updated again.  This is essentially a cache.  It works independently from the database, and thus and isn’t limited by its shortcomings.

If you run a blog using Wordpress, I recommend WP Super Cache (even though I’ve occasionally had some issues with it).

2. Use HTTP Compression (gzip)

Configure your server to gzip served components.  This GREATLY reduces the size of plain text content.  To use this in Apache, use mod_deflate.

3. Optimize images

Ooh, now we’re getting to the meat of it.  Unless you also host files or videos, images will be the largest part of your webpages.  As such, wouldn’t it be nice if there was a way to optimize them?  Well…

• For large images: Optimize using smush.it, which compresses images losslessly.  But sometimes it’s just not worth optimizing images, and in that case smush.it will let you know exactly how much space (or lack thereof) was saved during compression.
• For small images: consider using CSS Sprites.  To be honest, sprites are a pain in the neck to pull off, so try using an automator.  I hadn’t heard of webpage sprites until recently.  Think of this: you have 10 small icons that need to be loaded.  If they are separate images (traditional), there will be 10 separate requests to the server.  Instead, put them all into one file and position only the element you want with CSS.  The result?  Just one server request for 10 separate images.  Does anyone actually do this though?  Yes!  For one, Yahoo uses this for the navigation icons on their front page, and they pride themselves in having a fast load time.
• And if you’re planning on resizing content, resize it yourself.  You don’t want the user to download more than they have to, just to have their browser go ahead and downscale it after downloading.  I STILL see webpages with full-resolution photos used as thumbnails.  Stop doing this, people!
• Also, unless you want some sort of image animation, do use PNG instead of GIF.  Not only is it usually smaller and lossless, contrary to popular belief its transparency attribute is actually supported in all major browsers, including IE 6 (boo, hiss).  That is, if you’re using PNG8 with index transparency and not alpha transparency.

4. Minify Javascript and CSS (and maybe HTML?)

Once your Javascript and CSS is finalized and ready to go, use a minifier to remove at the very least extra unneeded spaces and comments.  The downside is you have to keep separate unminified versions that are actually readable by human eyes.  And they have to be reminified every time you make a change!

And if you’re adventurous enough, also minify your HTML.

5. Use YSlow for Firebug.

But take its advice with a grain of salt.  For instance, most small-time websites (including mine) don’t use a CDN (content distribution network), so don’t worry when you get handed that F grade.

6. Put your CSS at the top and Javascript at the bottom

Position matters.  Yahoo found that putting CSS at the top of the page, will give the appearance of the page loading faster.

Likewise, it found that putting Javascript at the bottom of the page forced the browser to first render content above it before calling the script.  Makes a lot more sense to render visual content before interactive content.

Or, if you want to get fancy, you can even…

7. Dynamically load Javascript

Putting Javascript at the bottom of the page should work, but if you want full control of when your scripts are loaded, you can load them dynamically.

For example, if you’re using the YUI framework, the only Javascript you need to call from your HTML directly is YUI Loader, which acts as a seed and will dynamically load additional YUI components (as well as other CSS and JS components) after the page has finished loading.  Neat.

8. Dynamically load images “below the fold”.

A working example of this is Yahoo! Shine.  Notice that the images load as you scroll down the page.  This is accomplished with the YUI Image Loader utility.

While it’s awesome for performance, for some reason I don’t find the effect annoying at all.  By its description I would expect to be annoyed by it.  But as long as the images load fast as I scroll, it’s actually sort of a positive reinforcement that the webpage is responding to my scrolling.  Weird.

9. Reduce requests by combining HTML, CSS, and Javascript (but only if you have TONS of visitors)

Experienced web developers will DEFINITELY balk at this one.  “But David, we’re supposed to keep everything separated!”  I know, I know!  It’s been stressed many times that web developers should separate their content (HTML) from their styling (CSS) and interaction (Javascript).  No inline styling, no inline scripts, etc, etc.

While this is good for maintaining your website and just plain good practice, I’m unsure if it really speeds up loading of your webpages.  What makes me unsure?  Take a look at the sourcecode of the Yahoo frontpage.  Other than looking like a complete mess, notice that there’s a LOT of inline CSS and Javascript.

Ok, by now it’s obvious I’m really familiar with all things Yahoo, so let me use another big example.  Check out the code on Google!  Same thing: inline CSS and scripts.

What gives?  Like my previous tip on using CSS image sprites, it’s always good when you can reduce server requests.  Especially for hugely popular sites that live and die on “uptime” and serving webpages fast.

But this is probably not so useful for the average Joe, where those extra requests are really not noticeable.  In that case, keep your CSS and Javascript separated from your HTML!

10. For PHP: use flush();

Another trick that Yahoo pioneered.  By default, PHP will only send your browser data once it’s parsed together your complete webpage.  So while the header and footer content might already be rendered, it might take just a little bit longer to get the body content.  Using flush() will send to the browser all the content already rendered.  This will result in a faster response, so the user’s browser can start grabbing content requested by the outputted HTML.

Need more tips?  Check out these related articles:
Yahoo’s best practices for speeding up webpages
YUI Blog: Image Optimization (4-part series written by Stoyan Stefanov)
20 Tips and Tricks to Speed-Up Your Wordpress Blog
25 Ways to Speed Up your Website

Know a useful tip that’s not listed?  Leave a comment below!

http://www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf

Awesome! This looks vaguely familiar, but I’m not sure I’ve read it before.  There’s a lot of great tips here - definitely helpful to read before you start planning your website.  It’s easier to implement this stuff in the development phase than when the site is already live!

(via creativetechs.com)

As you may or may not know, there are users across the internet who don’t have Javascript.  Yes, that might be shocking and terrifying, but you have to deal with it!

Good websites try to code in such a way that allows all users to access content, with or without Javascript or other plugins.  This is what’s coded first.  Then all the cool Javascript interaction and such is added on top later, for Javascript-enabled users (the majority).  This is called Progressive Enhancement, a buzz word you should know about if you’re in the web development business.  I’m sorry to say that I myself didn’t know anything about this until recently, when I immersed myself into more modern web development.  Oh yeah, and when I was asked about it on my internship interview with Yahoo.  How embarassing that I had to confess I hadn’t even heard the term…

Anyhow, long story short, the <noscript> tag comes in handy.  Code rendered inside this tag will only render when the user doesn’t have Javascript enabled.  So at the very least you do something like this:

<noscript>Sorry, this site requires Javascript.  (and I was too lazy to make the site work without it)</noscript>

I’m sure someone will find this useful, even though it might seem obvious to the veteran developers.  Someone who might benefit might be this site I came across today (to be fair, it looks like it was developed a while back, since the layout uses tables).

I was a bit confused at first because I saw the common “This page requires that JavaScript is enabled on your browser” message.  I thought something was wrong with my computer, since obviously I have Javascript enabled.  But then I realized the text is hard-coded and displays for all users.

All the developer had to do was put that text in <nocode> tags!  But instead it results in some confused visitors.

I’m starting to dabble in some JQuery just for fun.  After learning a lot about YUI over my summer internship at Yahoo, I wanted to see how other Javascript frameworks accomplish similar tasks.

So far I like the selectors in JQuery.  Their similarity to CSS selectors makes a lot of sense.  It makes sense to retain a common selector schema when possible.  It makes learning new stuff that much easier.

But I ran into something that’s a bit unexpected and annoying.  Apparently the JQuery masterminds have decided to change the expected functionality of the “change” event.  Long story short, if you want the intended functionality of the “onchange” event (simply “change” in JQuery), you must use the “onkeyup” event (”keyup” in JQuery).

Ok, now for a longer explanation!

JQuery’s change event

Try this bit of code (live demo here):

<!doctype html>
<html>
<head>
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript">
$(document).ready(function() {
    //JQuery change event
    $("#typeHere").change(function() {
        alert("JQuery: change");
    });
});
</script>
</head>

<body>

<textarea id="typeHere"></textarea>

</body>
</html>

If you type something in the text box, you’ll notice that nothing happens.  That is, until you click somewhere else on the page.  Then you get the alert.  Try just clicking on the text box and not changing anything, then click somewhere else again.  Notice that nothing happens.  That’s because you didn’t change any text.

So in effect, JQuery combined two classic events: onchange and onblur.  Instead of executing “change” instantly, as I expected, it waited until the “blur” event - that is, until I shifted focus away from the text box.

But I want the classic handling of “onchange” - something that fires the instant I change the text!  Then I have to use the “keyup” event in place of the “change” event.

JQuery’s keyup event

Now try this bit of code (live demo here):

<!doctype html>
<html>
<head>
<script type="text/javascript" src="js/jquery.js"></script>
<script type="text/javascript">
$(document).ready(function() {
    //JQuery keyup event
    $("#typeHere").keyup(function() {
        alert("JQuery: keyup");
    });
});
</script>
</head>

<body>

<textarea id="typeHere"></textarea>

</body>
</html>

Disclaimer: when the alert shows up, press the “OK” button with the mouse.  If you hit enter, keyup will be triggered again.  Infinite loop!

Now type in the textbox!  Instant feedback!  This is the behavior that’s expected!

One of the first things I learned at my internship over the summer was the difference between Standards and Quirks mode.  Basically, the idea behind quirks mode is for browsers to be backwards-compatible.  If a webpage is missing a DOCTYPE tag or has some sort of “transitional” doctype tag, the page will be rendered according to the previous version of the browser.  So say we’re using IE7 and we run across a page that has no doctype specified.  IE7 will assume it’s an old, outdated page, and will render the page just as it looked in IE6.  That’s quirks mode.

So obviously it’s pretty important to have a doctype tag if you want your webpage to display in Standards mode, as expected.  For instance, it’s mostly recommended to use this this code right before the <html> tag:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Dustin Diaz at Google, taking into account the fact that “every byte matters”, chopped down the doctype to the following:

<!doctype html>

After using the huge ugly doctype declarations for years, I can see why someone would be skeptical that this simplified doctype achieves the same results.  I was skeptical myself, so I tried it out.  With the help of Browsershots and a little Javascript property called document.compatMode, I was able test out the doctype in various browsers.

The test I used: when a document is in Standards mode, document.compatMode is equal to ‘CSS1Compat’.  Otherwise, the document is in quirks mode and document.compatMode is equal to ‘BackCompat’.  I wrote a little script that simply tests for this property.

Ok!  So does our shortened doctype actually force pages into Standards mode, as we hoped?  Yes, for 100% of browsers I tested.

Based on my own tests and thanks to BrowserShots, I was able to see that all of the A-grade browsers are forced into Standards mode.  That means IE 6.0 and 7.0, Firefox 2.x and 3.x, Opera 9.5x, and Safari 3.1x.  That’s the majority of web browsers right there.

But the test also passed on other browsers.  In my opinion, Google Chrome and IE 8.0 should both be A-grade by now, but aren’t officially listed as such by Yahoo (yet).  But don’t worry, they both passed, as well as a host of other crazy browsers I’ve barely heard of or never heard of (mostly *nix-based): Navigator 9.0.0.5, Mozilla 1.7.8, SeaMonkey 2.0, Avant 11.7, Flock 2.0, K-Meleon 1.5.0, Epiphany 2.22, Galeon 2.0.6, Minefield 3.1, Iceape 1.1.10, Iceweasel 3.0.1, Shiretoko 3.1.

So did anything fail the test?  Well, as it turns out, IE 5.5 and below don’t define the Javascript property document.compatMode.  So they simply leave it undefined.  In other words, they have no Quirks mode.  They are the older browsers.  For them, there is no Standards compliance mode.

That’s it.  Nothing outright failed.  It’s perfectly safe to use that simple doctype if you want Standards compliance mode.

Related:
Link to my test script
Simplified doctype now in use in Google search (view the source code)

(Ajaxian via Dustin Diaz’s blog)

Since I’m in the middle of transitioning from beginner Javascript to what I consider intermediate Javascript, I’ve often been faced with the intimidating task of using Regular Expressions.

It’s no easy task.  The syntax is ridiculously difficult to read and probably harder to write, at least for the uninitiated (i.e. normal people like me).  Javascript guru Douglas Crockford agrees, as can be seen in part 4 of his video “The JavaScript Programming Language” and also in Chapter 7 of his book “Javascript: The Good Parts”.

A LOT of people, including myself, learn best by doing.  That means a lot of trial-and-error.  And a good way to learn by doing is by using the great online tool txt2re.

The interface has a lot to be desired, but it’s still very useful.  For example, I can type in the following string into a textbox on the site: Example “text”!

And I get this kind of bewildering and colorful output:

Notice my original text at the very top.  It took me a while to see it (due to the bad UI), but once I saw it, it started to make sense.  Notice that each character is contained in its own colored box.  By clicking the links below the characters, you can filter out specific stuff.  For instance, I can click on the quotation mark link ” below each quotation mark to filter.

txt2re will take my two new rules to filter out the quotation marks and spit back the Regex code in whatever code I so desire: Perl, PHP, Python, Java, Javascript, ColdFusion, C, C++, Ruby, VB, VBScript, J#.net, C#.net, C++.net, or VB.net.

I happen to only be interested in Javascript at the moment, so I click on the Javascript tab and get my code:

var txt='Example "text"!';

var re1='.*?';	// Non-greedy match on filler
var re2='(")';	// Any Single Character 1
var re3='.*?';	// Non-greedy match on filler
var re4='(")';	// Any Single Character 2

var p = new RegExp(re1+re2+re3+re4,["i"]);
var m = p.exec(txt);
if (m.length>0)
{
var c1=m[1];
var c2=m[2];
document.write("("+c1.replace(/<!--,"<")+")"+"("+c2.replace(/</,"<")+")"+"\n");<br /--> }

One of the things I especially love about this is that the Regexp doesn’t combine the expression on one line, making it infinitely harder to decode.  Instead it takes each rule you specified and leaves them separated (notice the re1, re2, re3, re4, in the code).

By leaving them separated AND commented, you can, in theory, go back later and manually change your Regexp if necessary.  Intuitively, keeping the rules separated increases maintainability.

Or if you want, you can put all the rules on one line.  Just try to maintain and modify this code without having it break!

Image courtesy of cackhanded, from Douglas Crockford’s presentation “The JavaScript Programming Language” (Part 4)

Spam spam spam and bacon spam spam and eggs spam spam spam and sausage spam

If you’ve ever had a blog, you likely know the pain and frustration of dealing with comment spammers. Especially if you have a Wordpress blog.  All of the following is designed to help you out with that.

History

I’ve had a Wordpress blog since 2004, and I found out pretty quick that spammers flock like mad to try to post their links.  My first solution was to simply disable links entirely.  This worked at first, but then spammers came back in some shape or form and found out how to get around these measures.

So the next solution was to try to get Wordpress to block certain words in comments.  For some reason, at the time there was some loophole in the software that still enabled users to make posts with these words, so I made a bit of a hack.  The problem was that spammers would keep coming up with all sorts of crazy names of magic medical pills and the sort, and I would have to go in and update my filter list every time.

Turning on moderation was something else I tried, but spam remained a problem, since a large chunk of my time was spent looking for legit comments in the mess of spam comments.

The Solution (err, solutions)!

Akismet: saves you from the bastard spammers!

To a large degree, your comment spam woes can be solved by the positively awesome Wordpress plugin called Akismet.  There is a bit of setup involved, as you have to register over at Wordpress.com for your API key after installing.  But it’s definitely worth it.

After finding that Akismet automatically identified 35,000+ spam comments (!) on my personal blog and only let literally one or two get through unflagged, it definitely does a great job.  But I found that the spam robots don’t know when to stop.  They simply keep trying to post comments.  As a result, though your blog may be free from spam, your server is under constant strain from comment spammers.

At this point, things start to get a bit more creative…

On the assumption that most spam bots don’t have Javascript enabled, I dynamically added a hidden form field in /wp-content/themes/default/comments.php before </form>:

<?php

echo <<< HTML
<script type="text/javascript" charset="utf-8">
    document.write("<input type=\"hidden\" name=\"spamDetect\" value=\"JS\">")
</script>
<noscript>
    Due to the bastard spammers, you must now have JavaScript enabled in order to post.  Sorry!
</noscript>
HTML;

?>

Then I add the following to the very top of /wp-comments-post.php (after the <?php of course):

if (!isset($_POST['spamDetect']) ) {
    echo "You must have Javascript enabled to post comments.";
    exit;
}

I found that this pretty much eliminated spammers from showing up in my Akismet “Spam” tab, while still allowing normal people to post, and even post links!  The drawback, of course, is that people without Javascript are completely unable to post comments.

But now my server feels much better - it no longer has to receive spam comments and inserts them into MySQL.  It simply doesn’t receive them at all.

reCAPTCHA: Since one CAPTCHA is simply just not good enough.

An alternative solution, but one I always find annoying from the user’s perspective, is CAPTCHA, specifically reCAPTCHA, which has it own Wordpress plugin.  It also has audio CAPTCHA support for non-Javascript users, which is a bit more sensitive than my more drastic solution.

One more thing!  All this, save for Akismet, doesn’t stop trackback spam, which doesn’t use the traditional comment form.  So you’ll want to install the TrackBack Validator as well.

Summary

1. Akismet is awesome for identifying spam.  Install it.  Use it.
2. But spammers will still congest your server, so add more stuff to block them, like the custom code above.  And/or install reCAPTCHA.
3. Install the TrackBack Validator to prevent comment trackback spam.