Consider a nice feature in IE8, the inclusion of native JSON parsing.  If you are dealing with any mass of JSON data returned via Ajax parsing natively is a speed godsend.  Most libraries like jquery try to get advantage of browser native JSON using detection to see if it can be used or if we should rely on a rolled version.   To safely use such features you likely might use a little object detection.  Here for example, is a simple test to see if JSON might be around to use.

var nativeJSON;
nativeJSON = window.JSON ? true : false;
document.write("Native JSON Support: "+nativeJSON);

In the normal strict mode assuming you have a doctype properly set, the browser will display that indeed IE8 supports native JSON.

JSON is available in IE8 by default

Of course if for some reason you find yourself in compat mode either by button press – you know that broken document button or because someone is monkeying with the doctype to see if they can coax IE into rendering some old layout right, well then you might be in trouble. You see in compat mode you aren’t just changing markup compatibility, you are changing scripting too! So bye bye native JSON, hello potential scripting errors.

Scripting features may be disabled in compat mode

So the morale of the story – when Microsoft says IE is emulating another version assume they don’t just mean markup they mean everything!

Oh interestingly we have seen some more havoc that gets played as IE  compat modes.  The browser will actually send other user-agent headers when you flip modes.  This makes perfect sense it should, you see you are trying to emulate.  However, it turns out you can be quite mischievous with such a feature and maybe inadvertently. Really strong Web security systems may bind your user-agent with your cookie and if you start flipping in and out of one user-agent string and another during a session you are going to potentially flag yourself or just get plain booted.  For extra credit try doing such things on your bank site and see if they like it!

<div id="skip"><a href="#content">Skip to content</a></div>

Next using CSS you would set #skip {display: none;} and normal users are happy while screen reading devices will skip hearing your logo and navigation menu. This is the common way most Web developers build accessible markup, but is it right?

Thinking in an opt-in/opt-out kind of way, a person hearing such pages will be presented a skip to content link over and over and over again, very likely selecting it to get a sense of what is on the page before moving on.  It would seem to make more sense for the user to opt-in to the navigation and get the content by default rather than to opt-out of the navigation.

An alternative idea we have been experimenting with here at PINT on a few recent sites is actually to change the logic to skip to navigation instead.

<div id="skip"><a href="#navigation">Skip to navigation</a></div>

and then immediately show the <h1> heading of the page or content of note.  This seems to have dual benefit.  First it allows the screen reader to get to the page content quickly and only choose to deal with navigation when they want.  This makes the process more opt-in than opt-out.  Second, this small change allows us to put the content of the page higher up in terms of what a bot would see which likely would appeal to better indexing.  While we certainly don’t subscribe to the old wive’s tales of very restrictive bots only indexing a few things it does get to the content point a lot quicker which is what bots are at your site for in the first place.

A caveat here about the small change in approach.  The “skip to navigation” link makes sense on content page and the “skip to content” makes sense on navigation pages.  This would suggest the home page or primary section pages should probably be done as they traditionally are, but that other content rich pages use the logic we suggest.

I notice that my system has /dev/shm mounted as tmpfs. Turns out you can write up to 4G (maybe more) of files to it like it were any other partition, and it’s basically a ramdisk that can also be partially written to swap. It doesn’t use 4G of RAM, it grows dynamically as you add stuff to it.

For grins, I did the following:

1) in firefox, enter about:config in the address bar
2) Find: browser.cache.disk.parent_directory
3) If it exists, change it to /dev/shm, if not right click and add string browser.cache.disk.parent_directory, value /dev/shm
4) close your browser and restart it

I noticed right away browsing was way faster. I’m getting < 1 second loads of various sites. Your mileage may vary!

I verified the cache is indeed being managed in /dev/shm as well:

$ du -sh /dev/shm/Cache/
1.6M /dev/shm/Cache/

The downside?

You lose your cache when you reboot or shutdown then restart.

What’s nice about /dev/shm is you don’t have to muck with your startup/boot scripts to add a ramdisk, it’s already there.

I also did a meaningless benchmark. I copied a 350M file from hard drive to /dev/shm. First time it took 8 seconds, the second time (and 3rd thru nth) it took .5 seconds.  The 8 seconds was how long it took to read the 350M file into Linux’ filesystem cache; the 2nd time it copied from RAM to RAM.

Windows

The Windows XP solution, and it’s really fast too!

http://www.romexsoftware.com/download/

Download the free ramdisk software from the above link and install it.

Run the program and set up a ramdisk. I set up R: and used the default 64M (or 69M, whatever).

Use the same instructions as in post #1, but use R:\ as the value for browser.cache.disk.parent_directory.

Remarks

I didn’t do any particular before/after benchmarks, but the speed improvement is quite noticeable.  Hitting http://apple.com takes about 3 seconds (Linux) after clearing my cache.  The 2nd thru nth time takes 1 second or less.  Hitting apple.com (Windows) takes about 2.5 seconds with a cleared cache, .9 seconds otherwise.

The difference in speed between Windows and Linux is dependent on the browser add-ons I have installed (Linux is generally faster than Windows).

Simplicity of communication rules, so I’ll just answer directly.  NO this really isn’t a good thing unless you are quite careful or you make some of your living as a security consultant.

The bottom line with JavaScript based Web services is that if you include remote script in your page it can OWN you.  The very nature of JavaScript is that it can rewrite your objects as it likes.  That is it nature it isn’t a security flaw.  Futher it has quite a few ways of communicating and can leak information out quite easily from history and cookies and maybe more.

In the Ajax book we demonstrated the security concern with JavaScript being mistrusted over and over.  If you haven’t seen a demo here is a parasitic JavaScript binding on to your underlying XMLHttpRequest object that powers everything and watching your data.   If you pull in remote script it can do these kind of things and worse.  This isn’t a tech flaw, this is a trust flaw on your part as a developer.

Given the nature of JavaScript and how it is generally employed you should have extreme trust with any remote source be it linked script, retieved code or even fetched JSON packets.  Unfortunately that just isn’t the situation in most cases.   We talk all about the features in new Firefox but it takes until the very bottom this cold bucket of water is acknowledged.

A Note on Security

In general, data requested from a remote site should be treated as untrusted. Executing JavaScript code retrieved from a third-party site without first determining its validity is NOT recommended. Server administrators should be careful about leaking private data, and should judiciously determine that resources can be called in a cross-site manner.

So read that carefully you should determine validitiy before using script from 3rd-parties, but here is the rub, is that going to stay constant?  If you look once and then just use what’s to say that source doesn’t change or gets owned and then owns you?  Absolutely nothing unless you are monitoring the script for changes with some proxy.  Great idea, almost never done.

Don’t get me wrong.  I like new features and in fact am pro Web service, but the reality is that you are given implicit and significant trust here.  Even with just data pass back people have seen interesting hacks overriding the GETTER/SETTERS for array values.  In short even pure data responses have issues unless they are carefully wrapped.  Mix in the dynamic nature of JavaScript and it is a recipe for disaster.  Trust is the concern and you should not trust implicitly.  Further you should be minding your store lest you get owned by what Web service you link to or script you include.

I am certainly not the only one who sees this and can’t say that this type of alarm ringing is novel.  In fact we have been down this path before.  Flash supports similiar technology using its CrossDomain.xml file and folks like Jeremiah Grossman clearly pointed out that out in the wild quite often it is done wrong and in many cases quite wrong.  Now that Firefox and other browsers are supporting it natively I think we are going to see an explosion in cross-origin calls before there is a retreat as quality and security problems explode.  Though that isn’t all bad, you do usually have to exercise something to shake out the problems, just be careful!

So if you have written any significant amount of (X)HTML you likely have had an occasion to insert a special character using a named entity like &nbsp; or &copy; or maybe even as a numeric entity like &#160;   and &#169; which are equivalent to the named entities presented. Dealing with these entities isn’t fun but they are relatively predictable and looking them in a book or online with a chart or even a nicer tool isn’t that hard. However, there is a bit more to know than you might think, you see writing a “Complete Reference” I get to look very closely at things and uncover lots of interesting little oddities.

Entity Case Sensitivity?

Question: Are character entities case sensitive?  Answer – mostly, er…kind of?

Don’t you hate such nebulous answers in something that should be well defined.  Test &copy; and &COPY; in most browsers it will will likely render exactly the same. However, case insensitivity isn’t always the case. Consider &Agrave; (À) and &agrave; (à) really are two different things.  Even in the cases where there isn’t something similiar case will matter, for example, &pound; will render as £ while &POUND; will render as well &POUND;

Case sensitive!

So we should assume case sensitivity, but what is going on, which entities are case sensitive and which aren’t?  Well roughly the pre-HTML 4 are not likely case sensitive while the post-HTML 4 entities are.   HTML 5 tries to formalize this whole mess and documents that &AMP;  &COPY; &LT; &GT; &QUOT; &REG; and &TRADE; can be written either way but nothing else.  Roughly save the trademark these are as I said the pre-HTML 4 named entities and even that could be argued since it used to sit inappropriately in a charset no-mans land in ASCII 127-159.

Victory – a small detail knocked down for HTML 5 and an important syntax point that a quick perusal of HTML books (mine included) has gone completely unnoticed for a decade.

Entity Parse Problems

So when we mess-up markup like forget a tag or don’t close a quote we see the browser parser “fixing” things for us, albeit sometimes wrongly.  Well it turns out that this also holds for entities.  For example, given this &QUOTE; entity which is clearly a typo for &QUOT; it will render in one browser as it gets fixed and not in most others.  No bonus points for guessing – yes IE blows it.

IE fixing entities for me?

Interesting they may actually be trying to be somewhat correct in their automatic insertion of the trailing ; in the entity.  If you read the specification there is some suggestion that problems be rectified.  However, the decision of how to fix an error in a predictable and consistent manner, well that isn’t agreed upon.  [ Take a peek at the HTML 5 spec chaos for more info]  On that note a very big change with HTML 5 will actually be to indicate what should happen in case of syntax errors.  I guess if you can’t beat syntax into the heads of the masses you might as well codify how their nasty “tag soup” should taste.

Explorer Fully Gets Entities-Finally!

Finally Internet Explorer supports all the common entities

It Ain’t Over Yet

Year after year I seem to meet Web developers and students who think that just over the hill the green grass and blue skies of standards land awaits.  Well kind readers such optimistic thinking may help you sleep at night but after doing this for quite some time it is clear to me that even with specs there are simply implementation mistakes and well market forces that will make this unlikely any time soon–if ever.  Need some proof?  Well even in entities which are much improved in browsers lots of little quirks exist, especially when we consider that Unicode is and has been here.

How about a unicode entity?  Do those work?  Maybe sort of, well not really, gotta go numeric otherwise it just spells out.

The fun continues with entities in Unicode!

Even then once you insert the entities you might wonder what they are going to look like.  Consider the friendly snowman dingbat here in a variety of browsers.

The Unicode snowman revealing the differences in browser entities

Happy or sad, with hat or not, buttons, or snow our little dingbat shows that making little details the same across all browsers is about as likely as building a June snowman in San Diego.  Not to spoil the ending of the book, but every chapter and appendix keeps showing the more things change, the more they really do stay the same.

IE8 retains data for some sites

It appears that Microsoft has made an interesting assumption, end users are ok with preserving their tracks with bookmarked “friends,” but certainly not various sites they may occasionally visit. I guess the idea here is that because you have favorited the site you have committed to a more long term relationship and thus saving a cookie for easy login or cached files for fast render is ok? Seems a bit suspect to us, at least Redmond could have started with an opt-in for this rather an than opt-out.

While we use these shortening services in some Internet mediums because we must it is questionable the value of the keyboard character conservation services when you really consider their motivation and overall costs.

Twitter Revives URL Shorteners

URL shortening services simply didn’t matter much until recently. Just helping people deal with email messages that had URLs that didn’t wrap lines or similar occurrences in message board posts wasn’t much of a motivator. However, add Twitter to the mix and what is old well becomes new again.

Twitter’s 140 character limitation in today’s semantic SEO focused linked naming world is too restrictive. Your tweet can say “Here is a cool URL: http://big.old.url.here/that/goes/on/and/on/and/on” and then you are out of space. URL shorteners save us!

<SNARK>
Why build around a 140character limitation? Are we trying to communicate by fortune cookie message!?! A tweet with a long URL brings shame to your family!
</SNARK>

Beyond snark we do use bit.ly, tinyurl.com and others URL shorteners is a pure function of the limitations of Twitter. Take that limitation away (which should hopefully happen sooner than later) and the relevance of these services goes bye-bye.

Some may argue that the succinct nature of the 140 character thought bursts is good to ensure focus, but regardless of your stance on the limit why Twitter doesn’t add this feature itself as it is obviously needed and it doesn’t force users to use third parties is curious.  Probably Twitter is more focused on finding a good business model, so this is farther down on the list.  Regardless of who provides the service there are a number of interesting observations that can be made about shortened URL and their providers.

Keywords and Hashes

So the URL shortener takes our URL and makes it something like http://tinyurl.com/d4xd2u.  Cryptic yes- hash values like d4xd2u aren’t meaningful, they’re just short. If a shortened URL was http://tinyurl.com/shorturls then you might have value in balancing path length with meaning.  However, won’t a lot of other people want that URL then too?

Well in some cases we can actually make our keywords if it hasn’t been already taken.  For example, for this article I got http://tinyurl.com/shorturlpost

Of course this custom keyword is now taken, too bad anyone else who might want this.  So now we’ve just reinvented the idea of AOL Keywords.  We want a special “Go” word that is used in the URL or browser that gets us right to the object of interest rather than a nasty long URL.  It is a good idea, but it is not a new idea.

Networds, URNs, and a multitude of other name ideas that would aim to make the URL a short keyword system.  The current crop of shorten the URL services doesn’t do this (YET) nor does it even get the basics right. First consider if you are going to shorten or keyword URLs you really need a better domain name for the service.  TinyURL.com really isn’t that tiny and Bit.ly really isn’t a good obvious name.  Better candidates:

• http://go.com – ABC owned portal that isn’t doing much
• http://go.to – already doing something kind of like this but not right

Here we are 5 and 4 chars with some semantics in play.

Take the same idea and keep going and we get our second idea, a new TLD (top level domain) just for this duty.

• http://go/KEYWORD
• http://keyword/KEYWORD-HERE

Challenge with this is getting new top-level domain names going is a long process and frankly why do we need this?

The best idea really is to get the browser vendors to put this concept in a browser directly.  DNS would be to IP addresses as the keyword system would be to URLs.  Look up the special keyword resolve to the site.  Problem – we’ve tried this before.  Everyone wants to own this because it is a potential money minting business to sell keywords off it rather than cryptic hashes.  Do a Web history search lots of failed attempts here.  This is a hard problem, not technically – socially.  Everyone must accept this is the new way.

Watch Where You Are Going

Well putting aside the possibility for more meaningful shortened URLs, let’s discuss the simple problem of getting dumped to something unexpected (http://tinyurl.com/2w4apm).  Yes if you typed or clicked that you got Rickrolled.  Of course getting some poppy 80s video in your face is hardly a worry, you might find yourself following a Tweet to a Viagra ad or worse yet a drive-by malware site.  So with short URLs you can’t tell where you are going so now we need a preview URL.

A preview URL like http://preview.tinyurl.com/2w4apm now takes us to a page that reveals what the actual URL we are going to go to is. Try it in another window and take a look. Of course that doesn’t help too much but at least you know you are going to YouTube now so maybe your guard is up.  So now we have saved some characters and added some clicks to got to the verify page and verify the URL by providing what the real URL actually is!?

The concept of needing a preview URL really is kind of odd because no URL really can tell you what you are about to go tp.  Even if you see a URL like http://IamASafeSite.com/intendedPage/ what’s to keep that from being redirected to something just as bad as what a shortened URL?   The answer – absolutely nothing.  Every time you click any link you are taking that chance but likely it seems getting to know what the site as the shown destination you trust it is safe.  This hiding of destination is of course the same scheme phising uses.  What makes the cryptic short URLs bad is that you have no clues of good versus bad links at all, thus the preview URL introduction.

They’re Watching Where You Are Going

When you shorten a URL to save a few bytes you generally give away data about your readers and their interests. Most 3rd party short URL services track traffic to various URLs that are shortened or use advertising which similar may track as a way to offset the cost of the provided service.  Via link redirection the URL shortener obtains insight into a volume of Internet traffic but at the same time they become a critical link of Internet linking as well.

If a URL shortener service has problems lots of Internet links particularly in the Tweet-o-sphere have problems. Link consolidation to bounce off someone allows for observation and creates points of failure that don’t need to exist on the Web. In short links on the whole are more reliable when dispersed not aggregated.

Certainly one might argue that it is nice to get some statistics on what people click on. Some of the newer redirecting services provide this openly, but the question is should they and do you need them to get this data. The answer is it depends on where and why you use short URLs. In Twitter you needs these folks, outside Twitter you can easily do this yourself with a little JavaScript.

A simple JavaScript can be written to attach to outbound links and send a little request to your server when the link is clicked.  Simply attach an onmousedown or onclick handler to monitored links.  With this scheme you can fairly predictably watch people bounce away from you without a “site in the middle.” For a demo and example source take a look at http://ajaxref.com/ch2/recordlink.html.  The demo is quite basic and the scheme it employs is fairly widely used, check out the Google link result page with an HTTP monitor and you will see it employed.  The point being is that don’t assume you have to give away traffic data to a 3rd party to gain insight, you just don’t.  Then again most of us do so massively with Google Analytics, Google Toolbar, etc. willingly so what’s a little more info disclosure between Web 2.0 friends?

Summary

You probably have to use URL shorteners if you Twitter because of the 140 character limit in play but we should understand the following:

• These shortened URLs are currently not meaningful or SEO benefiting because of cryptic hashes

• These shortened URLs are worse for security because of easy destination masking

• These shortened URLs have privacy concerns as we share user traffic with a 3rd party

• These shortened URLs are less resilient than standard Web links because it consolidates and 2 parties the link

There are three real issues with server-side Javascript in general. These are the things I would be looking at before pronouncing that server-side Javascript is real enough to take off.

First, to DOM or not to DOM?  That is, it is debatable whether the Javascript engine on the server actually model the DOM.  My position is a resounding “NO!” as too much of the Internet has been about modelling the DOM on the server for far too long; it’s so Web 1.0, a 1990s way of thinking.  Modelling the DOM on the server has one advantage: you can use existing toolkits like Dojo or jQuery on the server side to manipulate HTML documents before sending them to the client.  The disadvantage is the cost of doing so; the startup time for instantiating a DOM and then processing it is quite costly, not to mention the amount of memory it consumes.  Think about how fast/slow your browser works and you realize that minus any rendering, this is the burden put on your servers. Aptana’s Jaxer is a well-known server-side Javascript solution that models the DOM, and may be the only such solution.

Second, standardization part one.  Javascript was designed to run in the browser, and with a DOM present.  Figuring out the order your scripts will be loaded and executed is trivial – it’s the order of the script tags you put in your HTML.  Server-side has no DOM and thus no script tags, so it’s rather nebulous how any script would get loaded at all, let alone multiple ones or the order.  Each implementation of server-side Javascript I’ve looked at have different philosophies that are not compatible with one another.  JsExt, for example, uses a subdirectory structure where a top level directory defines an object and the Javascript files inside define methods for that object; functions are often anonymous and the filename is the actual name of the function.  There are other obvious schemes, but all this leads to my next point.

Third, standardization part two.  Javascript is a very lightweight language once you take out the events and methods that are DOM oriented.  You have a few objects with a few prototypes and that is it (Strings, Arrays, Date, and so on).  The established server-side languages all have much richer and standard APIs; PHP has hundreds of functions and dozens of objects, for example.  There is no standards document that I know of that describes a similar set of functions and objects (and prototypes) that would enable server-side Javascript programs to be portable between server environments.  I’m talking about the server-side equivalent of jQuery or Dojo, and from my second point above you can see that the incompatibilities I described make this near impossible at this point.

It’s one thing for PHP to have it’s mysqli class and functions and Java to have JDBC.  These are language specific ways to access a MySQL database and you have to use what the language provides.  With server-side Javascript, you are using ONE language but might have to call Jaxer.db methods to access a MySQL database from Jaxer and JSEXT1.MySQL methods from JsExt.  One language, two radically different ways to access a database.

For the past year, I’ve been googling and watching out for viable server-side Javascript solutions but  I kept glossing over the ones that involved the Mozilla Rhino engine, thinking that we really want to be using whatever Firefox is using since we all benefit when Firefox is improved.  I found JsExt (http://jsext.sourceforge.net) to be about the best implementation of the bunch, but I really only ended up using it for its ability to run javascripts from the command line (in lieu of batch files or shell scripts).

Then I read this brilliant blog post by Steve Yegge of Google:

http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html

While the post and lecture is amusing and highly entertaining throughout, the gist is that the JVM (or .NET’s CLI) has a huge role in the future of computing.  These things are language agnostic; the goal is to turn source code into the virtual machine’s (VM) byte codes and let the VM implementors do their thing.  More specifically, you can compile Javascript into JVM byte codes and the resulting program not only runs in the JVM, but it also gets the benefit of Just In Time (JIT) compiling and optimization done by the VM.

I stumbled upon one of these JVM based projects, the Helma project, late last week and spent a few days over the weekend with it and came away quite impressed.  Turns out server-side Javascript has been here since 1998 when Helma first started up.

What is Helma?  It’s a full blown application server, built on top of the Jetty WWW server with the Rhino javascript engine.  It comes with a robust MVC framework written in Javascript, including an object persistence engine/database backend, and theme/skin/templating engine for the front end.

Helma can be downloaded at http://helma.org.  The download is under 5 megabytes.  The install took me about 1 minute to unzip.  To get started, all I had to do was run start.sh (or start.bat under windows).

The Helma configuration file is just a few lines, yet is rather powerful for defining the various applications you might serve with it.  It comes with two applications: welcome and manage.  Welcome is a small WWW site, a starting point for understanding what Helma is and how to get started using it.  Manage is a server administration back end that shows you the status of your applications, allows you to restart them or disable them, and so forth.

I highly recommend taking a look at Helma if you’re looking for a Javascript solution for the server-side of things.  I’ll mention a few of the highlights I found over the weekend, aside from how small it is and easy it was to set up.

The server comes with at least Rhino 1.7 which features a windowed debugger for Firebug style debugging of server-side code.

Javascript can trivially call any Java classes/methods on your classpath.  Seems easier to me to write a little bit of Java to extend your environment in a “native” code sort of way than writing C or C++ to extend a language like PHP or Perl.  This really puts a lot of power at your fingertips, like the ability to do image manipulation at Java speeds in your Javascript application.  Calling Javascript from Java is doable, too, but not as seemlessly.

The Helma server-side javascript library is quite rich, including Javascript classes/source code to implement FTP, SSH, SMTP, and several other Internet communication standards.

You can write text (HTML) to the browser or to the console (where you ran start.sh or start.bat).

There’s little overhead for defining a URL that runs a specific Javascript function to handle that URL.  It’s as simple as defining “function foo_handler() {  …}” to handle the URL /<appname>/foo.

You can use Jetty to serve static content, or you can serve static content through a trivial URL handler.  The extra overhead is almost zero!  So you can check to see if a user is logged in before serving a client-based .js file or you can check to see if the HTTP_REFERER for an image request is from your site before serving it (avoid bandwidth leaching).

I noticed two or three speeds when viewing the sample application I implemented to test things out.  There seemed to be a rather long page load time right after restarting the server (start.sh/start.bat) for the first page or so.  After editing a script and reloading the page, it seemed a lot faster, but still a tad slow.  But reloading that same page was just about as fast as I can expect a page to be served.  I assume this is due to the whole application being compiled into byte code upon restart, the incremental compiles as I change / edit source files, and the true production speed of JIT.

As far as performance goes, I would expect Helma Javascript code to be about the same as Java in this chart, due to it being compiled to JVM byte codes and JIT kicking in:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&d=data&gpp=on&java=on&ghc=on&csharp=on&sbcl=on&hipe=on&mzscheme=on&vw=on&lua=on&python=on&tracemonkey=on&perl=on&ruby=on&php=on&calc=calculate&box=1

Thumbs up from me for Helma!

A brief overview of some of the key features:

• Easy-to-read interface eliminates the need to pan and zoom.
• Well-designed sliding menu allows visitors to get the information they need faster.
• Scrollable galleries have a very natural, Apple-esque feel to them. Visitors think they are using an iPhone app!
• Google Maps integration
• Improved form validation, enhanced specifically for the iPhone.
• Fading and rotating graphics make smarter use of precious screen space.

See it for yourself by visiting www.pint.com from your iPhone browser, or see the screenshots.

See more screenshots.

If you want to read more about the technical aspect of the development, please see this post.

Designing for mobile aside, I will discuss the lessons learned from developing a minified version of a corporate web site for the iPhone. We wanted to include as many features as possible, to showcase the iPhone’s wide range of features available to Safari. What we discovered, however, is that it doesn’t offer several basic things that would be valuable to a corporate entity such as an ‘Add to Contacts’ option (perhaps available via hcard or vcard microformat?), ‘Download to calendar’ option (We can’t get some iCal love?), and easily findable documentation – hint: make sure you register at the Apple site. Below you will find some of the things that made developing a miniature version of our company site for the iPhone a challenge.

1. Animation – Leave it up to the browser

Webkit Transitions / Webkit Animation
When looking to do animation on the iPhone, CSS webkit transitions are the smoothest, if you can get them to work. There are many quirks in the implementation that make this method more difficult than expected, and there is a lack of documentation. We had trouble animating the height and opacity attribute, so in the interest of time, we moved on to something more familiar. We also were unsure how to simulate ‘before’ and ‘after’ handlers within the animation timeline, so we left those to JavaScript for now.

YUI Animation
We used YUI as our JavaScript library and for our animations. YUI was the best fit as a JavaScript library for several reasons:

1. It is the library PINT has chosen for regular web site projects, so our developers are all familiar with it.
2. When served by Yahoo!, the minified files are under 25KB and on a CDN, so they load quickly and get cached on the iPhone (See screenshots below). Souder’s rules suggest bundling objects for improved load time, but in this case we’ll take the cache benefit over a few less HTTP requests.
   

   Files under 25KB get cached

   When each file is served by YUI, the files are cached and loaded quite fast because on a CDN.

   

   Files over 25KB do not get cached

   When files are consolidated, filesize may become too large.

   

3. We were able to use existing in-house widgets to quickly create effects.

IUI Library
IUI Library is a well written library by Joe Hewitt that has built-in support for most of the UI effects one would want to do with a web app on the iPhone. Although we used some of Joe’s code in our own implementation, we still probably could have saved time and smoothness by starting out with IUI rather than mixing and matching YUI as we did.

2. Gestures / Touch Events – Take Advantage

Apple has given the iPhone Safari some new events to handle touches and gestures.

We used the touch events and their clientY values to determine if you slid your finger from the left to the right or vice versa. By doing some digging around, we found Matthew Congrove’s flick code. With a little work, we were able to get that talking with Joe Hewitt’s animation code, which allowed our menus to use the same slide code as our galleries. In the next version of our site, we’ll convert all javascript animations to webkit transitions and/or animations.

One problem we had with Matthew’s code is that up/down scrolling functionality is lost with his small example there, but it can be easily added back in with some clientX before and after comparisons.

3. Orientation – Let CSS do the work, not JavaScript

The iPhone supports two orientation modes: portrait and landscape. Some authors have recommended devising show/hide functionality to hide entire sections from one orientation or the other. What we noticed in our designs, however, is that our pages look pretty similar in both modes with the exception of images, which often become wider when in landscape mode. We decided to make the layout a flexible width of 100% with CSS, that way the page content looks and feels like it should at any orientation. To hide anything that shouldn’t be visible for that current orientation, we introduced an orient attribute to the body tag, updated that value when the ‘onorientationchange’ event was fired, and used a CSS selector to hide the content.

One of the things we noticed when switching across orientations was that common left/right slider mechanisms had adverse effects on portrait mode when coming from landscape mode. Some more prodding is needed here, but just be sure to check any pages that use relative or absolute positioning for slide effects in both orientations (if you are supporting both).

All troubles aside, it was a pleasure developing solely for Safari on the iPhone and I wish every project could be as creatively groundbreaking as this one. And boy was it good to drop IE6 support for once.

In case you don’t have an iPhone, here is a slideshow of some of the pages from the site:

Ultimate Lesson: iPhone Safari is Safari, but web site development for iPhone is different. Don’t do as normal web developers do.