You searched for: 'native'

Monday, March 31st, 2008

Saving Ourselves From the Unweb

Category: Dojo

Alex Russell gave the inaugural presentation at the Visual Ajax User Group held in the bay area recently. He presented on saving ourselves from the unweb and Chris Keene, CEO of WaveMaker Software, wrote up the talk for us all to read.

Alex laid out choices for evolving the Web:

We are reaching a fork in the road, however, where the web’s traditional strengths may be dramatically eroded by a “hollowing out” of the HTML semantics. There are basically two responses to this challenge of evolving the web. They are:

  1. Evolve HTML = Better Semantics, Smarter Clients. Evolve the existing web by pushing browser vendors to add semantic HTML capabilities that support next generation web apps. This allows for the web to remain a collaborative community that preserves the advantages which the web has traditionally enjoyed even sa it transitions to handle new tasks.
  2. Hollow out HTML = the “Un-web”. Abandon HTML and replace it with a powerful but proprietary alternative like Adobe Flex or Microsoft Silverlight. Let’s call this the Un-web, as it carves out walled gardens which will curtail the web’s traditional openness.

The web needs to evolve to support building the Rich Internet Applications that people want to use. At the same time, web tools need to evolve to be able to handle the increasing complexity of building these apps.

He then showed how Dojo 1.1 can play in a way that layers semantics on top of the usual HTML. He showed the Dojo Grid as an example:

  1. <span DOJOTYPE=""
  2. JSID=" csvStore"  URL=" names.csv" >
  3. </span>
  5. <table DOJOTYPE=" dojox.grid.Grid"
  6. STORE=" csvStore"  QUERY=" { Title: '*' }"  CLIENTSORT=" true"
  7. STYLE=" width: 800px; height: 300px;" >
  8.  <thead>
  9.   <tr>
  10.    <th WIDTH=" 300px"  FIELD=" lastName" > Last</th>
  11.    <th FIELD=" firstName" > First</th>
  12.   </tr>
  13.  </thead>
  14. </table>

Finally, the call out:

The key to the web’s future is real competition between the browser vendors that will force them to evolve the browser quickly. These features include:

  • Auto update capabilities
  • 3-d rendering
  • Support for new semantics in HTML
  • In short, give us native ability within the browser to do what we otherwise have to do in Javascript libraries

What we know is that we have never gotten good browser enhancements and tools from the market leader. So now you know what you need to do to save the web – download and use the underdog web browser and give it all the love you can ;-)

Posted by Dion Almaer at 5:16 am

4.1 rating from 17 votes

Friday, March 28th, 2008

Using the YouTube API via Ext

Category: Ajax, Sencha

With the YouTube API recently released, there’s bound to be lots of cool controls coming out soon. Thorsten Suckow-Homberg spent a weekend hacking up a Ext-based user extension that leverages YouTube’s chromeless API to build The Ext.ux.YoutubePlayer.

The Ext.ux.YoutubePlayer allows developers to embed youtube videos into Ext applications, using native Ext components for controlling the video playback. It’ll show the buffer status and let’s you jump to any part in the video using a slider component.

Cool features include:

  • Showing the buffer status
  • Playback slider that let’s you jump to any position in the video playback
  • Mute/unmute the video
  • Overall volume control

I whipped up a demo for all to see.

Posted by Rey Bango at 8:00 am

4.6 rating from 78 votes

Wednesday, March 26th, 2008

Will IE8 & HTML5 Make RSH Irrelevant?

Category: Ajax

As the title asks, will IE8 & HTML5 make Really Simple History (and other Ajax history managers) irrelevant? Not so much says Brian Dillard, project lead for the Really Simple History project. While additions to HTML 5 & IE8 will definitely make managing page history easier, Brian anticipates that libraries such as RSH will evolve into tools for handling session data, especially as offline storage tools mature:

Other browsers will still require polling and other browser-specific hacks. Even after all browsers support the hashchange event and all non-supporting browsers fade into obscurity, Ajax history management will still play a role. For one thing, we’ll still need a mechanism for our Ajax apps to associate state information with a given hash value (assuming, of course, that the hash token itself doesn’t contain all the state information you need).

Right now, RSH accomplishes this with a hidden textarea. In the future, though, offline storage mechanisms will probably play the textarea’s role. Once we get to the point where offline storage and the hashchange event are universal standards, Ajax history management will morph from a collection of hacks to a collection of convenience methods for native browser capabilities. Let’s hope that time is sooner rather than later.

His thought seem to be on target and I think that apart from handling state information, RSH will eventually fill the holes that hashchange leaves behind.

Posted by Rey Bango at 7:00 am

4.1 rating from 21 votes

Tuesday, March 25th, 2008

Do you want your browser to Jabber away?

Category: Browsers

Yesterday Rey posted about an ExtJS based Jabber client.

I had just earlier posted about whether you would want Jabber to be built into the browser, and will repost below:

Old Men Talking

Aaron Boodman was probably right in thinking that me wanting OpenID in the browser makes more sense as a browser feature, or separate plugin. This is a consumer level feature more than a developer focused one.

As I ruminate in the world of wishful thinking, I started to wonder about Jabber, and how it would be interesting to have XMPP as a native browser protocol.

We do have Jabber plugins, and there are JavaScript libraries that implement Jabber, but shouldn’t this be in the browser?

Jabber seems to be popping up all over the place. It started off as the IM protocol, and now has become a generic, scalable, messaging system. If XMPP was native and reliably in browsers, imagine how it could help the chat in Gmail? It could also transform the chat relationship with the Web. Social browsing as Me.dium does it could become more integrated. For example, I could have a trivial way to enable group chat on Ajaxian. I would love to be on the site and have others who are on there tell me how things are going, give me tips, and have comments feed into the same system. I shouldn’t have said “enable” as I wouldn’t have anything to do with it.

At an API level, we could also access XMPP from JavaScript.

Hmm, actually, is there a way in which this could tie into single sign-on and OpenID? Could XMPP be the way to login?

Posted by Dion Almaer at 7:11 am

3.7 rating from 17 votes

Monday, March 24th, 2008

Key events and Safari 3.1

Category: Browsers, WebKit

There has been a change in Safari 3.1 for how keypress events are handled. John Resig interviewed Yehuda Katz to get the skinny and understand why this was done.

The key comment is:

Use keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected.

John: At first glance through WebKit’s changes it appears as if they’ve significantly crippled the keypress event, is this the case?

Yehuda: People should not have been using the keypress event to get the character that was pressed. That’s because the keydown event only provides information about the actual key that was pressed (the A key, the right arrow, etc.), but does not tell the user what character will get added to (for instance) an input box.

Since arrow keys do not get added as text, keydown provides all the information that is needed. There were a couple of quirks with using keydown in certain cases previously which are resolved by their changes that prevent keypress from getting called if keydown’s default handling is blocked.

What this means is that if people were using keypress before (and relying on Safari’s native results for arrow keys, such as 63232), their code will break. However, this was a bad idea all along; people should use keydown to detect and block non-character keys. My mantra has always been: keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected.

Mihai Parparita is fixing Google Reader.

Also, Dean Edwards noted that Safari 3.1 failed Acid2 (not 3!) in a regression, but it appears a patch has landed.

Posted by Dion Almaer at 10:17 am
1 Comment

3.2 rating from 19 votes

Thursday, March 20th, 2008

Why getBoundingClientRect is important

Category: JavaScript, jQuery, Standards

We posted about PPK’s thoughts on CSSOM which included him dissing getBoundingClientRect() and getClientRects():

I feel this part of the specification is not yet ready. At the very least, the relation of TextRectangle boxes to actual elements should be defined in the case there’s more than one TextRectangle box, because I don’t understand what to expect (and I suspect browser vendors don’t, either, because Firefox and Opera never report more than one box, anyway).

John Resig, on the other hand, thinks that getBoundingClientRect is awesome (high praise, for a method).

What makes this method so especially handy is that the alternative means of computing an element’s offset position is so horribly slow and buggy that it borders on the comical.

The general purpose of this method, or of similar implementations, is to allow the user to get the visual top/left position of an element (such that if they absolutely position an element from the document it would be on top of the desired element – making things like tooltips possible, to name a single application). This means that you have to take into account a huge number of quirks.

To illustrate the point he points us to the jQuery implementation of .offset(), which is ugly indeed.

He also shows how much faster it is by creating a test page and a movie demonstrating the difference.

Posted by Dion Almaer at 7:30 am

3.2 rating from 13 votes

Monday, March 17th, 2008

ProtoSafe Eases Compatibility for Prototype

Category: Prototype

With so many new components being developed in a variety of different of JavaScript libraries, it’s a natural expectation that sooner or later, you’re going to want to mix and match these components within your application. Sometimes though, it’s not that easy due to architectural conflicts between different libraries. John David Dalton set out to minimize this pain via his new project called ProtoSafe.

I started ProtoSafe in response to a couple of posts on the Prototype Core Mailing list written by developers frustrated with Prototype’s 3rd party compatibility issues. I did some digging and found a post my Mislav Marohnic (here) explaining an easy way to keep Prototype out of the global namespace by simply wrapping everything in a self-executing anonymous function.

I asked John to explain the best use case for Protosafe and how it helps:

Prototype extends native data type prototypes which makes it very convenient for the developer but when interacting with 3rd party code not written for Prototype, these prototype extensions can cause compatibility issues. The most common is the Array for-in loop issue where by doing a for in loop over an array you get its indexed values plus the method names of all the added helper methods.

The benefit that ProtoSafe provides is that it allows Prototype to be used alongside 3rd party code without causing these compatibility issues.
Also it can be run against multiple frameworks which is good in the widget environment.

The demo page shows MooTools,Prototype,Dojo,YUI,jQuery all running on the same page.

Some highlights of ProtoSafe are:

  • It allows Prototype to work with 3rd-party scripts (no Array for-in
    loop pollution).
  • It works with Prototype 1.4-
  • Custom Packer3 that supports Prototype 1.6+/Scripty 1.8.1+
  • Only 3kb gzipped, less when compiled into the standalone js.

Posted by Rey Bango at 10:41 am

4.5 rating from 68 votes

Friday, March 7th, 2008

iPhone SDK for Web Developers

Category: iPhone

Man, I was wrong in my post on what about us? and the iPhone SDK. All I knew about was the VP of Phone Software saying “we have stuff coming”, but there is a lot more that that, it is just not mentioned in many places.

If you head over to the iPhone DevCenter (registration required) you will find a video titled “iPhone SDK for Web Developers” that goes into detail.

When you watch it you will see a ton of great stuff:

  • Gestures: ongesturestart, ongesturechange, on gestureend
  • Other actions: pinching, rotating, swiping
  • Full screen mode (no more chrome)
  • A lot of the cool stuff from WebKit nightlies (HTML 5 goodness)

Fantastic news. For a minute I worried that Apple would try to lure in us Web folk to learn Objective-C and Cocoa to grow that platform, but it looks like they are giving the mobile Web love as well as the native APIs. You just have to fork up $99.

Posted by Dion Almaer at 5:40 pm

4.2 rating from 38 votes

Thursday, March 6th, 2008

IE 8 on Acid

Category: Browsers, IE, JavaScript

The IE team posted that they were passing Acid2 a few months ago, yet people are seeing a broken face when they tested with IE 8 beta.

Phil Nachreiner of IE explained the situation:

Although we said that IE8 Beta 1 passes the ACID2 test, some of you may be seeing results like the image above; we thought we should explain what’s going on. IE8 passes the official ACID2 test hosted on (Note, this seems to be a popular destination at the moment. You may have trouble reaching the site.)There are also a number of copies of this test around the net. One popular copy that I’ve seen of late is

IE8 fails the copies of ACID2 due to the cross domain security checks IE performs for ActiveX controls.  Since IE does not natively handle HTML content in the OBJECT tag, but rather uses IE’s rendering engine as an ActiveX to display this HTML content, the same cross domain security checks also apply.

Given that, let’s take a look at how the copy from above relies on OBJECT fallback to render the eyes. Here’s the snippet of the test for the eyes:

  1. <object data="data:application/x-unknown,ERROR">
  2.     </object><object data="" type="text/html">
  3.                 </object><object data=”data:*the eyes DATAURI* …>
  4.     </object>

IE stops the OBJECT fallback process at the highlighted line above. The team and I involved in this work decided that this is the right thing to do because IE would have to allow navigation to this cross domain content in order to determine if the failed resource is a 404 HTTP error code or any of the other failed resource indicators that are part of the standard. To maintain compatibility and be secure by default we didn’t want to invoke fallback either, as original web authors might not have intended this behavior. We started with the most secure solution and are now looking into whether we can safely loosen this restriction in a future beta.
With all that said let’s also take a look at the official ACID2 page hosted by

We see:

  1. <object data="data:application/x-unknown,ERROR">
  2.     </object><object data="" type="text/html">
  3.          </object><object data="data:*the eyes DATAURI *>
  4.     </object>

Note that we see the same domain as the test, so everything works fine.

What about Acid3?

For IE7 and ACID3 I got: 14/100

The rendering was seriously messed up (boxes and off-color elements everywhere).

For IE8B1 and ACID3 I got 17/100.

The rendering was much better. The blocks showed up and appeared to be pretty correct size but were all black and gray (no color).

This just came out, so hopefully the team will have time to look at it before a beta in the future.

John Resig has a nice catalog of JavaScript related fixes in IE 8. I like how it is our release:

Our day has finally come. CSS coders got some love with Internet Explorer 7 – us JavaScript folk got absolutely nothing. In fact, at last count, all we got were a couple new bugs to deal with (file:// requests not working via XMLHttpRequest and <object>.getElementsByTagName(“*”) always returning no elements).

Internet Explorer 8 is our release.

Posted by Dion Almaer at 6:38 am

3.9 rating from 22 votes

Tuesday, March 4th, 2008

Google Gears for Mobile Released

Category: Gears, Google, Mobile

I have seen the huge batches of cell phones that companies keep around to test their applications on. Companies like UI Evolution have come along to try to help out the madness of getting something that works across more than a couple of them.

Not only do you have the problems of handsets, but you also have the network lock-downs and the hoops you have to go through to get an application onto a large set of devices.

Since the iPhone, I have strongly believed that history is going to repeat itself, and the Web is going to win on the mobile.

Enough rambling, Google has just released Google Gears for Mobile:

Today we’re announcing the launch of Google Gears for mobile, a mobile browser extension for creating rich web applications for mobile devices. The first version is now available for Internet Explorer Mobile on Windows Mobile 5 and 6. It’s a fully functional port of Google Gears v0.2 that can be used to develop offline capability into your mobile web applications. You can also create slick and responsive applications by hiding latency issues through controlled caching of data and storage of information between sessions. We’re also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers.

There are already a handful of Windows Mobile web apps that use Google Gears for mobile, such as the social payment service Buxfer and online applications provider Zoho.  Read more about these applications and how they use Google Gears for mobile on the Google mobile blog.

I got to fly back home to London to talk to members of the mobile team. Below is an interview with a couple of the engineers, and there is also a high level look at the news:

I am really excited about what this means for the future of mobile development. I want to be able to develop applications using Ajax on the phone, and see tools like Gears give me access to native APIs on those devices. I really hope that the iPhone SDK also offers more on the JavaScript API side too (as well as Cocoa). How nice would it be to take your iPhone app and finally get some onPinch goodness, and camera.takePhoto.

UPDATE: Wow, it is a mobile day, Nokia talks about plans for Silverlight

Posted by Dion Almaer at 9:37 am
1 Comment

3.9 rating from 14 votes

Monday, March 3rd, 2008

Dojo on AIR shows detail on AIR itself

Category: Adobe, Dojo

At first when you hear “FooAjaxLibrary now supports AIR” you think “er, OK, AIR has WebKit so it supports them all doesn’t it?”. SitePen added support for AIR in Dojo and gave us detailed information about the changes.

The value of this document is that it gives hints to us Ajax folk as we develop applications running on AIR. The main message is that the security sandbox that AIR gives you has subtle side effects that you need to be aware of.

For example, note the function(){} wrapper in the AIR-specific code:


  1. if (dojo.isAIR) {
  2.         this._xdTimer = setInterval(function(){dojo._xdWatchInFlight();}, 100);
  3. } else {
  4.         this._xdTimer = setInterval(dojo._scopeName + "._xdWatchInFlight();", 100);
  5. }

There are other small issues such as not having eval() available post-load that you can see in the changeset. If you run into something as you develop your Ajax application in AIR, you have another resource to check (as well as the Adobe resources of course).

As well as making changes to get Dojo working in AIR, SitePen also added support for some of the AIR APIs themselves, including:


The AirFileStorageProvider store the data in flat files in the app-storage directory. For example, a key of “MyKey”, value of “Hello World!”, and namespace of “MyNamespace” would create the file app-storage:/__DOJO_STORAGE/MyNamespace/MyKey which contains the text “Hello World!”. This storage provider allows for large amounts of data to be stored. Not only can strings be stored, but also objects thanks to AIR’s serialize/de-serialize functionality. On the downside, data is not encrypted on disk. It would be trivial however to encrypt the information using dojox.crypto before storing the data.


The AirDBStorageProvider leverages AIR’s embedded database. When the provider is initialized, a database file is created in the app-storage directory and the Dojo storage table is created. The table holds the namespace, key, and value. This provider is similar to the AirFileStorageProvider in which it can store large amounts, but it cannot store serialized objects because there is no way to de-serialize them due to eval() being unavailable post-onload. The database file is not encrypted, but you could encrypted the data using dojo.crypto prior to storing the data. One advantage of the AirDBStorageProvider is there is only one file written to disk whereas the AirFileStorageProvider writes a file for each key/value.


The AirEncryptedLocalStorageProvider uses AIR’s encrypted local data store functions. Data, such as passwords, will be encrypted when being stored and decrypted when being retrieved. Similar to the AirEncryptedLocalStorageProvider, objects cannot be stored because they cannot be
de-serialized with an eval(). One limitation of the AIR’s encrypted local data store is it does not provide a way to enumerate keys. To solve this, the AirEncryptedLocalStorageProvider creates a registry using AIR’s encrypted local data store to track the namespaces and keys.

Dojo adds it’s name to the list of Ajax frameworks that are ready for AIR work. Since Dojo has a large coverage of features (especially via the dojox.* components) it can be well suited for larger desktop apps.

Posted by Dion Almaer at 8:10 am
Comment here

4.1 rating from 21 votes

Friday, February 29th, 2008

Snoto Photo: Snook, Flickr and AIR

Category: Adobe, Ajax, Announcements, MooTools

After recently installing Snitter, I have to say I’ve become a bit of a fanboy of Jonathan Snook. The guy just produces some good stuff. So when I saw that he announced a new AIR application, I had to get it installed and checked out.

While Snoto (ya know, Snook, Snitter, Snoto) isn’t as polished as Snitter, it’s not meant to be. Jonathan has released this as a foundation for those that want to understand how to build AIR applications.

The goal of this is not to create a Flickr client that “does it all”. It was put together as a reference application for anybody interested in learning more about Adobe AIR. Snoto has been released under a Creative Commons license, so it’s available for you to take and extend how you wish. The link to the source code is included at the bottom of the Snoto page.

This is a great help to many developers as interest in Adobe AIR has skyrocketed since the release of AIR v1.0. MooTools developers should be especially pleased with the fact that Snoto was built using the MooTools JavaScript library, specifically because of the ease with which AIR applications can be developed without jumping through hoops. While other JS libs are now updated to work with AIR’s security model, MooTools was the first to be compatible even during the beta process.

Again, the biggest benefit is to those that want to learn about working with the AIR API:

From the AIR API, I haven’t gone hogwild but rather kept it simple. You can see use of nativeWindow, context menu and EncryptedLocalStore.

Having access to Webkit made styling the interface very straightforward. Like Snitter, it’s a combination of background images, PNG images, and some CSS3/border-radius to round things out.

The Snoto page has been setup with an AIR install badge which should make it easy to check it out.

Posted by Rey Bango at 12:33 pm

4.2 rating from 31 votes

Wednesday, February 27th, 2008

The Presentation Tier @ TSSJS

Justin Gehtland is the track host of The Presentation Tier track at TheServerSide Java Symposium.

In this podcast interview, Justin discusses all that has to happen on the server side in order to render Ajax and its related technologies on the client side, what the shift toward RESTful-style apps means for developers, why there’s an increased focus on security as it pertains to what ends up in the browser — and how all of this, and much more, will be covered in-depth at TSSJS.

Justin discusses the goal of the Presentation Tier track – To get developers thinking about the presentation tier as a distinct layer of their application, not just the output. Sessions featured in the track help you: understand the server-side technologies at your disposal for creating rich interactive applications, the potential impact presentation technologies can have on the design of your server-side applications, your presentation framework options, and how to quickly and securely integrate rich components into your Web apps.

Presentation- focused sessions include:

Advanced Ajax with Seam and Spring Web Flow
Ajax Framework Comparison
Designing Compelling Web Applications for Mobile Devices
Grails for Struts Developers: A Groovy Alternative
Groovy, Grails, and Google Maps: Mashups 101
HTTP for Web Developers
Modern JavaScript: Code Standards and Patterns
OpenLaszlo: From RIA to Ajax and Mobile
Web Security Success with Spring Security 2
Expert Panel: Wherefore the Surface Tier?

See the complete conference agenda.

TSSJS will be at The Venetian in Las Vegas, March 26-28. Review the conference agenda, and reserve your seat.

Posted by Carolyn at 2:04 pm
Comment here

3.3 rating from 12 votes

Adobe extending Flash platform: Run C, C++, Java and more

Category: Adobe, Flash

Paul Krill picked up on Kevin Lynch saying “It’s basically a way to take other languages and make them run on top of Flash Player” as he answered a question from the audience at Engage the other night.

Expanding on the project, Ted Patrick, Adobe technical evangelist, said the technology would allow for cross-compiling existing code from C, C++, Java, Python, and Ruby to ActionScript. This would enable components written in those languages to be integrated into a larger project, Patrick said. “That code becomes perfectly portable into our application platform,” he said.

For example, an alternative PDF renderer providing a lighter version of PDF could be cross-compiled, and the Flash Player could read it and display PDFs.

“Right now, everything has to be written in ActionScript or our lower level byte code languages,” said Patrick.

In Flash Player, everything has to compile down to SWF byte code, Patrick said. The byte code language inside SWF is called ActionScript byte code.

Of course, this has been talked about quite some time ago. As Tamarin grows up and becomes a solid VM, we are likely to see the polyglot come to being in full force.

Posted by Dion Almaer at 6:20 am

3.9 rating from 19 votes

Monday, February 25th, 2008

Mobile Applications, RIP

Category: Mobile

Michael Mace, a former Palm VP, says the business of native mobile apps is dying. He includes a quote from Palm veteran Elia Freedman summarizing why some of us have found mobile application development to be a deeply frustrating experience.

From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several — two versions of Windows Mobile, Tablet PC, and so on. [Elia didn’t mention it, but the fragmentation of Java makes this situation even worse.]

I call it three million platforms with a hundred users each (link).

The second technical issue is certification. The walls are being formed around devices in ways they never were before. Now I have to certify with both the OS and with each carrier, and it costs me thousands of dollars. So my costs are through the roof. On top of that, the adoption rate of mobile applications has gone down. So I have to pay more to sell less.

Then there’s marketing. Here too there are two issues. The first is vertical marketing. Few mobile devices align with verticals, which makes it hard for a vertical application developer like us to partner with any particular device. For example, Palm even at its height had no more than 20% of real estate agents. To cover our development costs on 20% of target customer base, I had to charge more than the customers could pay. So I was forced to make my application work on more platforms, which pushed me back into the million platforms problem.

The other marketing problem is the disappearance of horizontal distribution. You used to have some resellers and free software sites on the web that promoted mobile shareware and commercial products at low or no charge. You could also work through the hardware vendors to get to customers. We were masters of this; at one point we were bundled on 85% of mobile computing devices. We had retail distribution too.

Where’s he going with this? You can guess where he’s going.

Meanwhile, there is now an alternative platform for mobile developers. It’s horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.

I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.

Think about it: If you’re creating a website, you don’t have to get permission from a carrier. You don’t have to get anything certified by anyone. You don’t have to beg for placement on the deck, and you don’t have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won’t even be aware that you exist. It’ll just be you and the user, communicating directly.

Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple’s iPhone browser, coupled with Nokia’s licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this — mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.

As Michael points out, it’s not all gloom and doom for mobile apps, especially with the official iPhone SDK due out real soon now. For basic business apps, though, maybe we’ve already reached the tipping point.

Posted by Michael Mahemoff at 2:24 pm

3.8 rating from 21 votes

CSS Sprite Generator: Open Sourced and Adapted

Category: CSS, Performance

Ryan Breen has been tinkering with the CSS Sprite Generator that Ed Eliot and Stuart Colville recently open sourced.

How did he tweak it?

One of the first articles I wrote about CSS sprites covered the built-in support in GWT, and I focused on their clever trick of including an MD5 checksum of the sprite map contents into the filename. This allows you to set effectively infinite cache headers since the name will change if the underlying image is modified.

Since the CSS sprite generator is now open source, I decided to add the checksum approach as an optional feature (on by default). You can try it here, or grab the tar or patch.

Ryan Breen Sprite Generator

Posted by Dion Almaer at 8:22 am

4.1 rating from 14 votes