With more and more people embracing the idea of producing HTML5 mobile web apps, research like this is becoming vital. There are a lot of gotchas in this article, especially if you’ve been ignoring this space.
You should read the whole article, but I just want to point out a pair of findings before I send you on your way. One has been a known issue for a while (it’s a ySlow rule, after all,) but it’s still worth pointing out. The other… wow… my emphasis.
Results varied wildly across the three most recent versions of iOS. Astonishingly, Mobile Safari on iOS 3.1.3 did not cache components of any size, despite having an apparently unlimited page cache size. This is troubling since it means iOS 3.1.3 users are likely getting a suboptimal browsing experience, especially if they aren’t using wifi. The unlimited page cache size does little good here, since it only comes into play for back/forward navigations. This behavior is a significant change from what others observed in previous iOS releases and I can’t imagine any good reason for it, so I suspect this may be a bug.
Mobile Safari on iOS 3.2 (which is only available on the iPad) does not exhibit this bug. Its 25.6KB component limit and ~281.6KB total cache limit are better than nothing, but they still seem paltry compared to the other devices tested. Uniquely among iOS devices, the iPad appears to limit the size of pages in the page cache to 25.6KB, the same as its component size limit.
Browser Size does just what the name implies. Enter a URL, hit “go” and you’ll see just what percentage of the internet will see what without scrolling. Scrolling isn’t quite the bugbear it once was, but for certain types of pages immediate impact is still very important (campaign landing pages are a good example,) so having this as an easily accessible tool is really nice. Sure, designers have these guides in Photoshop and developers can resize the window with the Web Developer Toolbar, but this handy web-based tool is just the kind of thing to use in a meeting.
For some searches on both Bing and Google, the top result is enhanced with additional data. For simplicities’ sake (and because I’m selfish) I’m going to focus on one search for my personal site to compare the two.
I did some testing today with Google Chrome Frame. I wanted to see if it would mesh with my normal methods for serving IE specific code and, as far as I can tell, it behaves exactly as desired.
Between Palm letting me code directly on a killer handheld device, HTML5 starting to show up in real browsers and now Google saying things like the following [my emphasis], it’s a damn fine time to be coding on the front end:
Google Chrome OS will run on both x86 as well as ARM chips and we are working with multiple OEMs to bring a number of netbooks to market next year. The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies. And of course, these apps will run not only on Google Chrome OS, but on any standards-based browser on Windows, Mac and Linux thereby giving developers the largest user base of any platform.
This is also interesting for me personally, as I’m a big fan of my Dell Mini 9 Inspiron and I’d be tempted to dual boot it- just to double my geeky pleasure.
An older (2007) article, but still pretty interesting. I’ve been slowing working my way through some HTML5 stuff. This was part of that effort. If, like me, you’re fascinated by where the web is going*, you should definitely check the article out.
With event tracking open to everyone we’ve been going nuts with them at work. I’ve also been going nuts with them at home.
I’m basically smothered in event tracking.
I’m glad to have it. It saves me from doing non-standard stuff (faking page views) and it saves our analytics analyst the time of having to filter out fake page views from the data.
While I’ve been messing with “real” fonts on the web using Cufon, it’s still a hell of a lot easier to just use old school fonts. The referenced article does a great job of pointing out some neglected fonts that might come in handy on a project.
Attaching an event handler to the document and then delegating based on the target has been on my mind a lot recently. I like the idea and it’s actually come up in two code reviews this week as an alternative to traditional event handling.
Serendipitous then, that Nicholas Zakas decided to write it up so that I have something fresh to point to when I reference the technique.
*I’m also fascinated by where the web is and where the web has been, so I’m not really picky on those fronts.
But, if you’ve got any interest in SEO, then this discussion of the