First off, let me admit that I don’t know much about the next version of JavaScript (ECMAScript Edition 4) other than it supposedly has some new language features that the current and past versions don’t support. This is no surprise. Unfortunately, it is also no surprise that Mozilla and Microsoft disagree over JavaScript’s evolution. The heart of the disagreement is that Mozilla’s Brendan Eich wants to add functionality and features to the language, Microsoft’s Chris Wilson wants to create a new language.

As a web developer this is disappointing. It has a stench of the days when Netscape and Microsoft both decided that they knew best and implement incompatible HTML rendering engines. I hope both Brendan and Chris work out their differences and create a better language for us web developers to use.

Here are some links to more information about this disagreement:
Proposed ECMAScript 4th Edition – Language Overview (PDF)
IEBlog: ECMAScript 3 and Beyond
Chris Wilson: What I think about ES4.
Print Me: ECMAScript 4, the fourth system syndrome
Brendan’s Roadmap Updates: Open letter to Chris Wilson

A project that I am working on uses the font Creative Block BB for its headlines. I use sIFR for these situations. Unfortunately sIFR3r278 won’t work with Creative Block BB. I have tried creating the swf file from Flash Pro CS3 and from OpensIFR, neither work. More exactly, both encode the swf fine (OpensIFR with a reduced font set) but don’t work within a web page. I have tried other fonts, they work fine.

After a bit more testing I have found that Creative Block BB will render with sIFR2.0.3 but only when the swf file is encoded with OpensIFR. The solution is only partial though because Creative Block BB can’t be encoded with a space character, thus the rendered text doesn’t have a space. This is no good. If I had Fontographer or other font creating software and knew how to use it, I would try adding the space character to the font. I guess it is time to find another font.

Web 2.0 has been in full swing for a good year or so now. Lots of modern, advanced frameworks and best practices have come to light to fully take advantage of the Web 2.0 trends. Of those best practices, I would like to briefly address the notion of Progressive Enhancements and Graceful Degradation.

Progressive Enhancement and Graceful Degradation are complimentary practices. If a Progressive Enhancement won’t work, it should degrade gracefully. Some have said that
Progressive Enhancement has its limitations. True. When designing an interface, JavaScript can create such a easy and seamless interface that the non-enhanced version will have to be radically different. Also true. This, in my mind, is when Graceful Degradation comes into play. If a system fails, it must do so while being usable as long as possible. In other words, if JavaScript is disabled, a user interface should still work with traditional client-server requests.

Here is a quick view of some sites and modules that rely on PE and sometimes GD.

The Good

These modules degrade gracefully when JavaScript is disabled.

• Gmail - A standard version is available if JavaScript is disabled.
• Apple Video - When JavaScript is disabled, a message to enable JavaScript is displayed. Plus the option to download the video is available.

The Bad

These sites do not degrade gracefully when JavaScript is disabled.

• CNN Video - Sorry CNN. I love the new site, but video and other things fail when JavaScript is disabled.
• YouTube - Much like Apple, a message is displayed when you don’t have the appropriate technologies, but they do not offer a downloadable version of the video.

All in all this is a tough situation. A lot of time, resources, and money are required to fully implement a well PEGD web site. Trade-offs and priorities will ultimately win the current battle until more frameworks and best practices surface enough to become common place techniques for dealing with complex interaction solutions.

I found my first browser bug. Unfortunately, the bug surfaces in a browser that is fastly becoming obsolete, IE6 - I say that with great pleasure - and it is also a quasi-bug because the bug only surfaces with the famous iepngfix.htc hack to make PNGs work in IE6. I haven’t investigated the bug yet. I will when time permits, but, in a nutshell, if you are used the aforementioned hack on CSS background images and use the keyword !important, then the hack won’t work. You’ll get a ~20% gray background color instead of a nice clean transparent image.

All versions of Internet Explorer prior to 7 cannot correctly display the transparent PNG-24 images. In place of the transparent pixels are light gray pixels. The solution that I like the most is called the IE PNG Alpha Fix. It uses a .htc file that corrects the behavior of IE using javascript. The fix also requires the a CSS hook:

* { behavior: url(iepngfix.htc); }

I have used this solution on a couple of projects now, it works well and doesn’t require gratuitous HTML hackery.

Unobtrusive JavaScript, CSS, Flash typography  has been around for a while and is equally important as swfIR if not more so.

I’ve been thinking recently of how to rotate an image with javascript. I haven’t researched it too deeply and have not figured anything out. But then today came along a great stopgap. Use unobtrusive javascript and flash. Wow. This is a great idea!

With every new web site that I create, I use a very specific directory structure for the ui. This allows the root web directory to not become over saturated with folders that do not contain actual web content. My folder structure is as follows

• ui
• css
• images
• js

Essentially, I use one main folder to contain all user interface elements: cascading style sheets, images, and javascript. The css folder can contain numerous files depending on the complexity of the web site and interface. The images folders contains the images for the web site framework. This includes any images needed for the general design, icons, buttons, and any other design imagery. The images folder does not contain images as they relate to a particular page or article. Those images are handled differently depending on the complexity of the site. The js folder is used to hold all javascripts. I thought about separating them out into behaviors and other scripts, but in the end I decided not to. I don’t use a ton of javascript (yet) so I didn’t see the need for the separation.

If there are multiple designs for a project, I use the following structure:

• ui
• design 1
• css
• images
• js
• design 2
• css
• images
• js

In this case, I give design 1 and design 2 a name that refers to the design. If the design is a retro 50’s design, I use something like stylin50s. If it is an oceanscape sort of thing, I name it something like comotionontheocean. I have a little bit of fun with the names. It keeps me sane somehow.