Pacific Side

Until today, I'd never really delved into when and when not to use a semicolon to close a line in JavaScript. I used to use them excessively, which is safe, but recently tried abandoning the semicolon after all closing brackets ("}"). This apparently broke some of my code today though, and I discovered that I need to keep the semicolon after the closing bracket of function expressions, while it is safe to leave it out after the closing bracket of a function statement. The different usage being illustrated here:

// Function expression

var myFunction = function(...) {
    ...
};

// Function statement

function myFunction(...) {
    ...
}

One of the projects I've been working on does a lot with communication between JavaScript and Flash. The ExternalInterface available in ActionScript 3 makes this a lot easier, and I've been wanting to do something cool with it. For now, I've worked on this example to illustrate the basics of how ExternalInterface works and its simplicity.

The relevant portion of the ActionScript:

// Add an ExternalInterface callback for communication from JavaScript

function flashCallback(data:String):void {
    textBox.text = "JavaScript: You clicked " + data + ".";
}
ExternalInterface.addCallback("flashCallback", flashCallback);

// Add listeners to communicate to JavaScript via ExternalInterface

circle.addEventListener(MouseEvent.CLICK, function(event:MouseEvent):void {
    ExternalInterface.call("jsObject.callback", "Green Circle");
});
square.addEventListener(MouseEvent.CLICK, function(event:MouseEvent):void {
    ExternalInterface.call("jsObject.callback", "Red Square");
});

The relevant portion of the JavaScript:

// Create a JavaScript object containing the callback for communication from Flash and triggers to communicate to Flash

var jsObject = (function() {
    var triggers = document.getElementsByTagName('a');
    var init = (function() {
        YAHOO.util.Event.addListener(triggers, 'click', function(e) {
            YAHOO.util.Event.stopEvent(e);
            YAHOO.util.Dom.get('mySWF').flashCallback(this.innerHTML);
        });
    })();
    return {
        callback: function(data) {
            YAHOO.util.Dom.get('flash_response').innerHTML = 'Flash: You clicked the ' + data + '.';
        }
    }
})();

View source on the example for more details.

• Example
• Download the FLA

Been working on some layering issues with our Yahoo! Finance interactive charts:

http://finance.yahoo.com/echarts?s=BRK-A

Making HTML/CSS/JavaScript content appear above the Flash portion is tricky in some Mac/Linux browsers. Today I fired up Firefox in my Ubuntu Linux virtual machine and went to Adobe's homepage. It seems that even the people who make Flash don't know how to fix all the browser layering issues because the dropdown menus there fall behind the Flash in the Linux/Firefox combination rendering them unusable:

http://adobe.com/

A survey of doctype and encoding usage across a couple of Yahoo and Google's international locales:

Yahoo!
- Doctype? Yes. HTML 4.01 Strict.
- Encoding specified? Yes. UTF-8.

Yahoo! Taiwan
- Doctype? Yes. HTML 4.01 Strict (but mixes in some XHTML syntax).
- Encoding specified? Yes. BIG5 (legacy traditional Chinese encoding).

Yahoo! Japan
- Doctype? No.
- Encoding specified? Yes. EUC-JP (legacy Japanese encoding).

Yahoo! China
- Doctype? Yes. XHTML 1.0 Transitional.
- Encoding specified? Yes. GB2312 (legacy simplified Chinese encoding).

Google
- Doctype? No.
- Encoding specified? Yes. UTF-8.

Google Taiwan
- Doctype? No.
- Encoding specified? Yes. UTF-8.

Google Japan
- Doctype? Yes. HTML 4.01 Strict (but mixes in some XHTML syntax).
- Encoding specified? Yes. UTF-8.

Google China
- Doctype? No.
- Encoding specified? Yes. UTF-8.

So, I setup this site with the intent of focusing on internationalization and localization as they relate to the web but have not done a whole lot of that yet. I have found that this is something I actually know more about just because I have developed in a multilingual (English, Chinese, Japanese) environment for a while. To kick this off, I thought I would put up a short blurb about the Unicode UTF-8 Byte Order Mark, otherwise known as the BOM. If you have ever seen  prefixing the first line of a file, then you have already been introduced. My thought here is not to discuss the nature of the BOM (you can check out the links below) but to mention some potentially lesser known facts about its use that developers may run into.

• When saving a file in Notepad, if you save with "Encoding" set to "UTF-8" then you are including the BOM at the beginning of the file even though you cannot see it. Similarly, in Visual Web Developer, if you save the file with encoding and choose "Unicode (UTF-8 with signature) – Codepage 65001" then you are also including the BOM at the beginning of the file.
• Properly using multilingual text on the web requires using files saved with Unicode encoding. There are usually a number of options. Generally, best practice is to not include the UTF-8 BOM, and I recommend choosing a Unicode encoding that both excludes the BOM and maintains a small file size. For example, in Visual Web Developer, I save files with the "Unicode (UTF-8 without signature) – Codepage 65001" encoding.
• Having said that, I ran into the same case twice on my former blogging platform where I was forced to include the BOM at the beginning of an ASP file in order for it to properly recognize the script as Unicode and correctly process Unicode text. If all else seems to be failing, give it a shot and see if it fixes it. Still, my recommendation is to exclude the BOM unless it proves absolutely necessary.

Check out these links for more information:

• http://www.unicode.org/faq/utf_bom.html#BOM
• http://en.wikipedia.org/wiki/Byte_Order_Mark