You searched for: 'native'

Monday, June 28th, 2010

IE9: Big leap forward, and how we can help the Microsoft momentum

Category: Browsers, IE

Microsoft continues to impress with its developer preview releases for IE9. They went from a laggard in both performance and Web standards, to regrouping and doing some fantastic work in both regards.

The honourable PPK has detailed the leap forward with CSS (in between watching his Dutch team do well in the World Cup. Not that I am friggin jealous ;)

The sea of green on the CSS compat tables is fantastic news for the Web:

More on IE9 and CSS from PPK:

IE9 promises to be an excellent browser. Its CSS support is now at par with that of the other browsers — although each browser still has its specific areas where it performs less. But we cannot in good faith say that IE is behind the others any more.

There are only a very few declarations in my test that IE9 does not support. CSS columns, gradients, text-shadow, resize, and text-stroke are the only ones, and the latter two are WebKit-only.

Even better news: Microsoft’s filters seem to have just disappeared from IE9. It supports normal opacity; no more filters required. Also, the gradient filter is gone, leaving IE (temporarily?) not supporting it.

Another golden oldie that got dropped is cursor: hand, the MS proprietary alternative to cursor: pointer. That’s not really important in practice (IE6 already supported both syntaxes), but it’s a powerful symbol of the changes that the IE team has wrought.

With so much excellence around I was almost glad when I found one single bug: IE9 doesn’t handle white-space: pre-line right. This bug will be fixed, though. It’s typically a minor point that crops up in a beta and is removed from the final product.

And, it isn’t just CSS that is turning green. Kangax does a fantastic job at looking at JScript and the DOM. Not only does he show the good, but also the areas that still need improvement such as:

Unfortunately, the entire host objects infrastructure still looks very similar to the one from IE8. Host objects don’t inherit from Object.prototype, don’t report proper typeof, and don’t even have basic properties like “length” or “prototype”, which all function objects must have.

Kangax is doing a lot of good here. The more tests and call outs on what IE needs to do to be standards compliant the better. With the new rate of progress from the IE team, it isn’t like the old days where you thought you were talking to deaf ears. Microsoft is listening, and even better than that, they are doing. Now is the time to give them as much info as we can.

What would you like to see?

Posted by Dion Almaer at 4:35 pm
26 Comments

++++-
4 rating from 2 votes

Thursday, June 24th, 2010

ExtensionFM: A case study on a sexy app, turn extension

Category: Showcase

Editor’s note: Dan Kantor is the CEO behind the awesome ExtensionFM project. It really pushes the boundaries on what the Web can do, so I asked Dan to give us a mini case study on the project. What follows is his words on the matter. Thanks for taking the time Dan!

Dion recently posted about the march to a more client-centric web. The post hit home with me as the founder of a web-based application that is as much ‘app-like’ as it is ‘web-like’. The promise of the web, and HTML5 in particular, is that we will finally reach the write-once, run-anywhere dream we have all been in search of that neither Java nor Flash could fully deliver. Dion poses this question (and answer) towards the end of the post – ‘As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No.’. I don’t think many developers would argue with Dion’s answer. The real question is – ‘Are we there yet?’

My company is developing a client-centric web-based music player that cuts no corners in its attempt to look, feel and run like a native application. We threw progressive enhancement out the door, pushed the pedal to the HTML5 metal and created something that most people would be hard-pressed to believe is not a native application if they didn’t already see it running inside the browser. However, there is a catch. Our application only runs inside Chrome. This was of course by design. We built it as a Chrome extension. We didn’t choose to do this because we wanted to restrict it to Chrome. We did this because a large part of the functionality of our application needs the extra APIs and permissions an extension gives you. A nice side-effect of that is we know 100% of our users are using an HTML5 capable browser. Chrome extensions are 100% HTML(5), CSS(3) and Javascript. Extensions provide extra Javascript APIs that give you access to functionality that you otherwise would not have running as a website such as removing security restrictions on cross-domain xhr and requiring permission to display desktop notifications. Of the thousands of lines of code in our extension, only 5% of it is Chrome specific. In theory, this should make porting to other browsers and OS’s easy. Let’s see what it looks like in practice.

A few months ago, we decided to see what our application would look like on the iPad. After just four hours, we had a working prototype of our music player that looked and felt native but more importantly looked and felt exactly like our Chrome extension. This was possible because Chrome and Safari share the same rendering engine – Webkit. Mobile Safari has already implemented many of the HTML5 features we needed such as HTML5 Audio, Web Database and Local Storage and many of the CSS3 features we needed such as Background Gradients, Rounded Corners and Box-Shadows. We were able to re-use most of our Javascript code and since we used a lot of CSS in place of images, we were able to resize elements with ease. But a prototype is just a prototype. Could our web-application actually be a viable shipping product on the iPad?

At this point, the answer is no. Mobile Safari has two quirks that seriously hamper its ability to act as a web platform. The first is it’s lack of fixed positioning. If there was one feature that defined native applications vs. web applications it would be that native applications almost always frame content with a top and bottom layer of buttons or displays. Think about iPhone apps. Almost every one of them (minus games) has a navigation layer on top and a series of buttons on the bottom. To pull this off as a web-application, you need fixed positioning. Unfortunately, Mobile Safari (as well as Android’s browser) do not provide this feature. There are many hacks to emulate it though. Apple has even developed a Javascript/CSS framework to get around this themselves. For our iPad web-app, we used a library called TouchScroll that uses Javascript and CSS animations to emulate scrolling. Overall, the lack of fixed positioning is not a game-ender, as hacks are available, but it certainly adds a layer of complexity to building a client-centric web-app that will make many developers’ lives more difficult. The next quirk may just be a game-ender. Mobile Safari on the iPhone and iPad has an annoying ability to refresh windows once you open up a few. So say you have a few windows open including our music player. The music player is not the active window however. When you click back on it to make it active, it refreshes. I’m not sure why this happens although my guess is it has something to do with memory management. Either way, most apps (especially music or video ones) cannot be taken seriously if the application is constantly refreshing. Sure, in theory applications could maintain their state between refreshes. But in practice, this never works quite as well as we’d like it to. Of course, music stopping and starting constantly will be a game-ender. I am hoping that the iPhone 4 with its 512MB RAM does not have this issue. Android does not seem to suffer from this but Android does not support HTML5 Audio or Video so it certainly has drawbacks of its own.

A couple of weeks ago, Safari 5 was introduced with support for extensions. We spent a few hours reading the documentation to see what it would take to port our extension from Chrome to Safari. Unlike Firefox, where extensions are a bit more than just HTML/CSS/JS and support for HTML5 features are lagging, Safari extensions are theoretically similar to Chrome. Other than different Javascript APIs, the functionality offered is almost exactly the same. We determined that it would not be too difficult to port. Of course, business decisions are not always just about technology, so we are waiting a bit before we do just that. It will however, be very interesting to see if Apple brings extension support to Mobile Safari on iOS.

Coming back to Dion’s original post, it seems like we are closer to write-once, run-anywhere using client-centric web-based applications than we have ever been. With a few modifications, we can basically re-use 80% of our code to deploy on the desktop and mobile. Unfortunately, not all browsers are there yet though. The issues I listed above seem like minor ones that can be fixed easily however. It would not surprise me if in the second half of 2010, Mobile Safari fixes the refreshing issue and Android adds support for HTML5 Audio/Video. As more frameworks are released that deal with the fixed positioning problem, I expect more developers to look seriously at the web as their platform of choice for deploying mobile applications. As for the desktop, Firefox 4 and IE9 should finally add the HTML5 and CSS3 feature support that Chrome and Safari have had for a while now. Of course, not all users will have the latest and greatest browser. Progressive enhancement will be the only way to support those users. But by pushing the envelope of what’s possible, we will hopefully push those users towards upgrading to a modern browser.

For a 60 second run through of ExtensionFM, check out the video below:

Posted by Dion Almaer at 6:07 am
12 Comments

+++--
3.7 rating from 13 votes

Wednesday, June 23rd, 2010

IE9 supports Canvas…. hardware accelerated!

Category: Browsers, Canvas, IE

Huge news. My canvas crusade is done. IE9 is supporting canvas, and it is hardware accelerated, in the third preview release:

With the third platform preview, we introduce support for the HTML5 Canvas element. As you know our approach for standards support is informed both by developer feedback and real word usage patterns today, along with where we see the web heading. Many web developers have asked us to support this part of HTML5 and we definitely took this feedback into account as we prioritized our work.

Like all of the graphics in IE9, canvas is hardware accelerated through Windows and the GPU. Hardware accelerated canvas support in IE9 illustrates the power of native HTML5 in a browser. We’ve rebuilt the browser to use the power of your whole PC to browse the web. These extensive changes to IE9 mean websites can now take advantage of all the hardware innovation in the PC industry.

Preview 3 completes the media landscape for modern websites with hardware accelerated video, audio, and canvas. Developers now have a comprehensive platform to build hardware accelerated HTML5 applications. This is the first browser that uses hardware acceleration for everything on the web page, on by default, available today for developers to start using for their modern site development.

The third platform preview continues to support more of DOM and CSS3 standards that developers want. Examples here include DOM Traversal, full DOM L2 and L3 events, getComputedStyle from DOM Style, CSS3 Values and Units, and CSS3 multiple backgrounds.

Also included in the third platform preview is support for using the Web Open Font Format (WOFF) through CSS3 font face.

Oh, and Acid3 is coming along too….. as well as a lot of performance improvements.

Congrats to the IE team.

Posted by Dion Almaer at 4:54 pm
25 Comments

+++--
3.3 rating from 3 votes

Sunday, June 20th, 2010

Do LESS with Less.js

Category: CSS, JavaScript

Dmitry Fadeyev has a great writeup of less.js, the implementation of the LESS styling language in JavaScript itself.

Traditionally you would write a less file such as:

  1. @brand-color: #3879BD;
  2.  
  3. .rounded(@radius: 3px) {
  4.     -webkit-border-radius: @radius;
  5.     -moz-border-radius: @radius;
  6.     border-radius: @radius;
  7. }
  8.  
  9. #header {
  10.     .rounded(5px);
  11.     a {
  12.         color: @brand-color;
  13.         &:hover {
  14.             color: #000;
  15.         }
  16.     }
  17. }

and then you would precompile it to some CSS. Not anymore, now you can natively link to the less:

  1. <link rel="stylesheet/less" href="/stylesheets/main.less" type="text/css" />
  2. <script src="http://lesscss.googlecode.com/files/less-1.0.18.min.js"></script>

Now less.js will unpack the file and do its thing… making sure that the final CSS will be fully cacheable. Less.js has been written as a CommonJS module so you can run it on the server via node, or in the browser on the fly.

Dmitry answers the perf question (runtime HAS to be slower!), and talks of some cool features:

Wouldn’t live processing lag? Not really. Two reasons for this. One: Less.js has been written from the ground up for great performance, so even browsers with poor JavaScript implementation should still run it very well (Less.js is about 40 times faster than the Ruby implementation—so suffice to say it’s a lot faster.). Two: On modern browsers that support HTML5, Less.js will cache the generated CSS on local storage, making subsequent page loads as fast as pure CSS.

There are other cool features built into Less.js. For example, there’s a “watch” feature available in development mode. This feature will refresh the CSS on your page whenever your .less file is saved with new changes. The best thing is, it won’t refresh the whole page, just the right bits of CSS, live.

Less is certainly more. Even though it is tough to make the performance trade off in production, for development, and for the ability to use less for applications that don’t have a server (e.g. I am excited to use this in webOS and mobile Web apps in general! ;) is palpitating. Sencha Touch uses the step cousin, SASS.

Posted by Dion Almaer at 7:02 am
17 Comments

+++--
3.8 rating from 4 votes

Thursday, June 17th, 2010

The march to a more client-centric Web; Will the mobile Web, HTML5, and Chrome Web Apps be the tipping point?

Category: Editorial

Progressive enhancement.

Disconnected offline applications.

There is a tension brewing in how we deliver applications on the Web. This isn’t a new tension. It has been around ever since we started to do more than just throw HTML down the pipe for the hypertext document runtime to render.

With the Ajax revolution we talked a lot about “Web applications”. Gmail. Google Maps. Those are written in a very different manner. The architecture isn’t one of: client asks for a URL…. server does all of the work: business logic, and view logic, since it sends back the entire view as HTML. A popular Ajax pattern was that of still keeping the client kinda dumb, and having the server return interface elements and behaviour in the form of HTML/CSS/JS that the client would eval/innerHTML/etc. This continues to be used a lot as it is flexible (especially if the bulk of the team is on the server side) and sometimes easier to do (chop up the functionality on the backend into more discrete tasks). This is a progressive enhancement style of richer Web applications.

When I was working with Gears I saw first hand how reluctant developers were to move from the progressive enhancement style into a more aggressive client server-esque style of Web application development. The Gears APIs themselves are trivial. Nicely implemented. Simple APIs. We get to use them these days in the form of App Cache, SQL database API, Web Workers, GeoLocation, etc. Taking your application and sprinkling a GeoLocation API is very simple and fits into progressive enhancement easily. Even doing what the WordPress guys did early on, and using App Cache as an aggressive fast cache is easy.

The harder sell to developers was: If you want to have your Web application work offline, you need to re-architect it to enable that. Instead of having your PHPs firing down interfaces, you need the client to coordinate the work and just speak REST to services that give you the data, and then have a layer of abstraction that can get the data locally etc. Then you can look at handling sync and the like. This is real work. This is moving code from point A to point B. It is a big deal. Many developers didn’t see the value proposition. Do they REALLY care about the offline use case? Getting some performance improvements by taking out latency is nice (hit cache first etc) but is that worth the rework?

For many people, it just wasn’t worth it.

As I look at what is changing in the world, I see a few things that may add up collectively to a tipping point:

“HTML5” hype

HTML5 has a lot of great functionality. There will be pressure for developers and sites to raise the bar. Expectations of what a Web application “can do” is drastically going to change, and as soon as that change happens you don’t want to be left behind. MapQuest was fantastic. Until Google Maps came out. Then, on that day forth, it felt archaic. All of that with XHR++….. what will happen with all of the HTML5 functionality available? A lot of code we will be rewritten and changed for “HTML5ication”, which is an opportunity for a change in how things are done.

“Apps” and the Web as a unified device platform

I haven’t been quiet with my concern at the rise of the proprietary app platforms. The Web needs to fight back, and it has the opportunity to actually solve developer problems (rather than just rant about how the world should be more open damn it!).

As a developer, do you want to port experiences between incredibly varied platforms such as Web, iPhone, Android, WinPho 7, RIM, Kindle SDK, [insert many others!]? No. The Web has the opportunity to share a lot of that code and development. It has to compete with the native platforms on features, performance, and the like…. but I would argue that it is doing a great job and getting better FAST.

Within the apps ecosystem there are some very interesting things happening:

Chrome Web Store: The Chrome Web Store is happening. I know of other Web store efforts in various stages of life too. A lot of developers want to get into the app distribution bandwagon, and will be looking at the notion of a “web app” in a new light because of this. This will give a lot of momentum, along with the fact that HTML5 is the first real spec envisioned for “app” functionality versus documents, to the web app movement.

Mobile Web: As developers want to get applications to as many devices as possible, they are finding that the Mobile Web is an attractive development platform. But, how do you do it? If you think about Web distribution, then you have the progressive enhancement world again (device and layout tweaks via CSS, JS, etc) all the way up to a mobile framework. We see the two worlds with jQTouch on one side and Sencha Touch on the other.

Take a look at how an app looks in Sencha Touch:

templates in HTML

  1. <textarea id="legislatorbrief" class="x-hidden-display">
  2.     <div class="legislator-brief">
  3.         <div class="legislator-tnail" style="background-image: url(http://www.govtrack.us/data/photos/{govtrack_id}-50px.jpeg)"></div>
  4.         <h3>{title} {firstname} {middlename} {lastname} ({party})</h3>
  5.         <p>{state} {district:this.ordinal}</p>
  6.     </div>
  7. </textarea>

OO app framework with layout and components

javascript

  1. Geo.App = Ext.extend(Ext.Panel, {
  2.     cls: 'app',
  3.     fullscreen: true,
  4.     layout: 'card',
  5.     activeItem: 0,
  6.    
  7.     initComponent: function() {      
  8.         this.startScreen = new Geo.views.StartScreen({
  9.             flex: 1
  10.         });
  11.         this.splash = new Ext.Container({
  12.             cls: 'splash',
  13.             layout: {
  14.                 type: 'vbox',
  15.                 align: 'stretch',
  16.                 pack: 'end'
  17.             },
  18.             listeners: {
  19.                 deactivate: this.onSplashDeactivate,
  20.                 scope: this
  21.             },
  22.             items: [this.startScreen]
  23.         });
  24.         this.detail = new Geo.views.LegislatorDetails();
  25.        
  26.         this.items = [this.splash, this.detail];
  27.         Geo.App.superclass.initComponent.call(this);
  28.        
  29.         this.startScreen.on('legislatorselect', this.onLegislatorSelect, this);
  30.     },
  31.    
  32.     afterRender: function() {
  33.         Geo.App.superclass.afterRender.apply(this, arguments);
  34.         Ext.getBody().on(Ext.isChrome ? 'click' : 'tap', this.onLinkTap, this, {delegate: 'a.goOutside'});
  35.     },
  36.    
  37.     onLinkTap: function(e, t) {      
  38.         e.stopEvent();
  39.         Geo.Util.openUrl(t.href);
  40.     },
  41.    
  42.    
  43.     onSplashDeactivate: function() {
  44.         this.startScreen.list.clearSelections();
  45.     },
  46.    
  47.     onLegislatorSelect: function(govtrack_id) {
  48.         this.setCard(this.detail, Geo.defaultAnim);
  49.         this.detail.update(govtrack_id);
  50.     }
  51. });

This looks similar to how we build apps on webOS with Mojo and other frameworks like Jo. Rich full featured mobile frameworks.

Once you have built your Web application, technology such as PhoneGap and Appcelerator Titanium can package it for the various app distribution platforms.

So, when I put this all together, I see the opportunity for the growth of Web applications through both progressive enhancement, but also via rich client frameworks. The tension will be there between the two, and I am sure that there will be more solutions that blend the best of both worlds.

What do you think? What are you seeing as you build richer Web applications for a variety of devices and form factors?

Posted by Dion Almaer at 3:25 pm
12 Comments

+----
1 rating from 1 votes

Monday, June 7th, 2010

Google I/O Sessions for Web Devs

Category: Google

The Google I/O sessions are now live. I/O was a big event this year, and the press liked to focus on the splashy double headed keynotes (day 1: go web!, day 2: go Android :/).

The bulk of the real content from Google engineers was very solid indeed, and there are gems for Web developers out there.

I wanted to highlight a slew of these:

GWT + HTML5 can do what?!

Remember the GWT Quake goodness from April 1st? The crew behind it are back giving a talk about the tech behind it. There are many gems in here, such as the image library by Ray Cromwell that has software and hardware back ends (WebGL). Watching the photoshop-esque filters running via WebGL makes you drool.

There were other GWT sessions:

HTML5 and Chrome

Google used the “HTML5” word a loooot that week. Here is a blending of talks, part open Web, part Chrome itself.

Ian Fette kicks off a session on HTML5 support:

Oh, and have some fun with Ignite:

Posted by Dion Almaer at 11:17 am
3 Comments

++++-
4 rating from 1 votes

Thursday, May 27th, 2010

A second look at the “webbyness” of an “installable” Web App

Category: Editorial

Many in the Web community have been guarded about the notion of “apps” and what a Web app is. Google itself, via Gears and now HTML5 support, were pushing the notion of giving the browser the abilities to do app-like things…. rather than pushing for a native app runtime.

The Chrome Web Store and its .crx installable zip archive bring up the question yet again of what a web app is. http://gmail.com is a Web app isn’t it? What is the difference between that and gmail.crx?

The notion of an app can be a little scary when we think about the current incarnations. Having centralized closed marketplaces are un-webby. However, that says nothing for the technology, but rather the policy and implementation.

Atul has written a very nice piece that dives deep into the core issues:

I am not sure exactly what webby means, but if I had to guess, it would involve the kinds of qualities that Mitchell Baker and Mark Surman believe make the web better: more transparent, participatory, decentralized, and hackable.

He goes into detail on the benefits of untethered applications, beyond “working offline”. We can get to a better place where some apps, and pieces of apps, can work very well untethered. Of course, many applications out there quickly talk to the Internet, but a disconnected cacheable world makes a lot of sense (CouchDB apps :). It feels silly to go to a simple one player game at http://somegame.com/ and not be able to play because of the Internet connection. AppCache and friends go along way, but there is more.

Another key piece is permissions. As I watch folks talk about the W3C Widget Spec and the Chrome Web App manifest, permissions seems to be the crux of the matter. We need people to focus on this piece. If we can collectively crack that nut, my gut tells there will be an explosion of amazing things… and the world will make more sense.

Atul also talks about the Web of Trust:

Another area in which Installable Web Apps could decentralize the internet has to do with the field of trust. It’s currently very difficult to actually prove that a piece of Web content or functionality I created came from me, and wasn’t altered at some point by someone else. The only viable way to do this is via Secure HTTP, which requires asking an authority for permission to issue you a certificate. That this frequently involves paying them money and that the system is susceptible to corruption are besides the point. As Mark Surman mentions in a draft of Drumbeat’s mission statement:

“Ultimately, our goal is a strong, safe open internet: an internet built and backed by a massive global community committed to the idea that everyone should all be able to freely create, innovate and express ideas online without asking permission from others.”

It should be possible to prove to other people that something came from you without having to ask permission from someone else, and in this respect, even though this mechanism is part of the Web, I would argue that it is profoundly un-webby. Google’s proposal for Installable Web Applications associates an application’s identity with a public key that doesn’t require a blessing from any kind of authority; all versions of the application are self-signed by the key, which makes it far easier to establish trust between a user and an application. The trust model is also more granular and secure, because it creates a trust relationship between the user and the particular application they’re using, rather than the server they’re connecting to—which often isn’t even under a web developer’s full control. It’s because of this that we’re using a similar mechanism in Jetpack; extending it to the entire Web would be very webby, not coincidentally because it establishes a foundation for what could eventually become a web of trust.

I am really enjoying the conversations and thoughts that have come out of the strong competition from proprietary app platforms.

It feels like the scale of our movement has changed from infighting (Gecko vs. WebKit vs. Trident) to collective war (Web vs. proprietary app platforms). The Google folks who believe in the Web (Chrome++) are more aligned to what we are doing at Palm, and what Mozilla is doing…. than the Android platform. Ditto for Safari/iPhone.

The world keeps getting more interesting. The browsers have strong competition internally, and now the platform has competition.

Posted by Dion Almaer at 1:35 pm
4 Comments

++++-
4 rating from 2 votes

Friday, May 21st, 2010

SoundManager2 now with HTML5 Audio

Category: Sound

Scott Schiller, the best moustache-d frontend engineer around, has updated his awesome SoundManager library. The latest SoundManager 2 version now comes with free HTML5 Audio support which makes it a HTML5 Audio()-capable JavaScript Sound API, backwards-compatible via Flash fallback for MP3/MP4 formats. Existing SM2 API seamlessly uses HTML5 where supported, currently experimental; and of course… works on iPad.

Highlights

  • Experimental HTML5 Audio() support, with Flash fallback for MP3/MP4 as required. (HTML5 disabled by default except for iPad + Palm Pre, but easily configurable.)
  • 100% Flash-free, HTML5-only playback of MP3, MP4 (AAC) and WAV files possible on Apple iPad and Palm Pre (and Safari 4.1.5 on OS X 10.5; buggy behaviour observed with 4.1.5 on OS X 10.6, see https://bugs.webkit.org/show_bug.cgi?id=32159#c9 )
  • API is unchanged, transparent whether using HTML5 or Flash; SM2 handles switching of technology behind the scenes, depending on browser support.

Here is how it works:

soundManager.useHTML5Audio

Determines whether HTML5 Audio() support is used to play sound, if available, with Flash as the fallback for playing MP3/MP4 (AAC) formats. Browser support for HTML5 Audio varies, and format support (eg. MP3, MP4/AAC, OGG, WAV) can vary by browser/platform.

The SM2 API is effectively transparent, consistent whether using Flash or HTML5 Audio() for sound playback behind the scenes. The HTML5 Audio API is roughly equivalent to the Flash 8 feature set, minus ID3 tag support and a few other items. (Flash 9 features like waveform data etc. are not available.)

SoundManager 2 + useHTML5Audio: Init Process

At DOM ready (if useHTML5Audio = true), a test for Audio() is done followed by a series of canPlayType() tests to see if MP3, MP4, WAV and OGG formats are supported. If none of the “required” formats (MP3 + MP4, by default) are supported natively, then Flash is also added as a requirement for SM2 to start.

soundManager.audioFormats currently defines the list of formats to check (MP3, MP4 and so on), their possible canPlayType() strings (long story short, it’s complicated) and whether or not they are “required” – that is, whether Flash should be loaded if they don’t work under HTML5. (Again, only MP3 + MP4 are supported by Flash.) If you had a page solely using OGG, you could make MP3/MP4 non-required, but many browsers would not play them inline.

SM2 will indicate its state (HTML 5 support or not, using Flash or not) in console.log()-style debug output messages when debugMode = true.

Want to check out the code? Fork away!

Posted by Dion Almaer at 9:22 am
11 Comments

+++--
3.8 rating from 4 votes

Thursday, May 20th, 2010

What can we do with a Web Store, and even an Open Web Store?

Category: Google, Mozilla

We have been thinking about the app store models for awhile, and how they port to the Web. With the Chrome Web Store we can take a look at a concrete example and think about how it could potentially grow?

Mozilla just came out with a post that aims to start a discussion about what an Open Web Store would mean?:

  • exclusively host web applications based upon HTML5, CSS, Javascript and other widely-implemented open standards in modern web browsers — to avoid interoperability, portability and lock-in issues
  • ensure that discovery, distribution and fulfillment works across all modern browsers, wherever they run (including on mobile devices)
  • set forth editorial, security and quality review guidelines and processes that are transparent and provide for a level playing field
    respect individual privacy by not profiling and tracking individual user behavior beyond what’s strictly necessary for distribution and fulfillment
  • be open and accessible to all app producers and app consumers

I personally have been taking apart some of the pieces that make the holistic “app store” experience, and think there is room to do more with the various pieces. I would love your thoughts on what I wrote (pasted contents below):

App Stores. Catalogs. Markets. Gardens. They have been an incredibly hot topic ever since the success of the iPhone App Store. Everyone has wanted to own and control an app store ever since, for many different reasons. Not all of them are good. Not all of them can extract from the App Store experience.

With that, today Google unveiled a Chrome Web Store. Many folks have talked about how the Web, and the Open Web, could benefit from an app store. At a high level, the Web should give developers great options to distribute and monetize (if they so wish) their products, projects, and abilities.

There was a phase where people assumed that Internet meant “everything would be driven to be ‘free'”, and the model to make money is ads. Ads can potentially be a great avenue depending on your product, but people have always been willing to part with money to get value (or perceived value) back… and it shouldn’t be too shocking to have see that play out again via app stores. Deliver great experiences and they may come. There is a lot to be said about “expectations” though, and I feel for some of the business models that are in trouble (media etc).

So, it would be nice if a developer could build something useful, stick a price tag on it, and sell it… using great distribution channels. One model for this is to package the application in a way that works in the distribution channels (e.g. PhoneGap, Titanium, or for us on webOS…. natively) but surely we can do better?

When you look at what an app store is, it consists of many pieces indeed.

For example,

appstorestack

Application Platform

This is the set of APIs and technology that you can use to build your applications. We feel strongly that having many fragmented devices with their own set of APIs, and thus their own platform, is a path to madness. To fix that, we need a unifying platform. We could unify on a proprietary platform (e.g. Flash, Cocoa, Silverlight/.NET, or what have you) or we could learn from history and honour the very lucky place that are in as an industry, and choose Open standards… and in concrete, the Web.

The Chrome Web Store very much honours this. Their apps are just Web apps. This is fantastic and a big step forward. The fact that you could take the same codebase and ship it in a store that runs in Chrome and other browsers (and web OS’s :) is great news.

But this is only one level of the stack.

Application Packaging

How do you package up your application to place in a store? Chrome has a prelim crack at this with their crx format that we have seen via Chrome Extensions. There are also others:

W3C widgets, Android, webOS, Nokia WRT, and more. Libraries like PhoneGap already have to deal with this world. We need scripts and tools to navigate this world. In the short term lets create and use those tools, but how about all getting together and making a format that we can all live with and extend in the right ways?

Distribution

How do you distribute your apps? Right now you either: a) put up a website and folks find you (via search {and thus SEO}, the social web, and links), b) put an application into a store itself.

The Web won on distribution. AOL couldn’t hold back the tide. Everything was Out There. Do we really want one or two companies in charge of what gets Out There? There is certainly value to curation, and finding applications via places you trust, but I personally want to see us solve the problem is a distributed open way. No entity should own the pipe. There should be no “right way” to censor or review applications. Different systems can choose values. Ideally they are transparent, and consumers can then choose where they want to look for the app content.

Discoverability

If we had a standard format for “installable web apps” a lot of good can happen. If we had a standard format, we could annotate the Web with it. Browsers could consume it (e.g. App Discover and the talk on just this.) and search engines could index it.

If I am on a Web site that has an application available, the browser should let me know. If I do a Google search, a one box should tell me about the matching apps for the platforms that I care about.

Anyone could create a merchandising experience and have access to apps to search for. We can go beyond that too of course. We can have web hooks that ping services with information about applications that have been created. A meta service would crop up that looks for the data and then pings the various Web app stores, just like we saw with trackbacks and the like.

There is still a ton of room to innovate in discoverability. Smarter searching that ties deeper than matching on the content will kick in.

Merchandising

Having access to the application data is important. The Palm ecosystem shares full feeds of the data from the catalog and this allows anyone to merchandize the content. They can be creative and present the right content to the user. There is a lot of innovation to be done here. Ideally, someone could create a great new social algorithm and have it run against all of the web apps out there. Right now, the stack is monolithic and we only have basic merchandising needs in most of the ecosystems. What about affiliate systems and the like which could enable innovation here?

Fulfillment

How do you pay for a good. How does the developer get paid for the good. This is an obviously crucial layer. Apple has done very well because people already had iTunes accounts coming into the world of the iPhone. In a distributed model, users could choose to fulfill via Amazon, or Paypal, or Checkout, or SimpleBank (one day right al3x? :)

And more….

We haven’t even gotten into identity, single sign-on, reputation systems, and how reviews can be shared on the same applications in different stores. There is so much to be done here.

Looking forward, where does this next step take us? Is there a path where web applications themselves are back to just being websites that can live in various stores, and a pay gate can be setup in an easy way?

I can’t wait to see how this plays out. We could all go off and build ivory towered app stores, or we could come together and work out a better way. Are you in?

Posted by Dion Almaer at 2:49 pm
Comment here

+++--
3 rating from 5 votes

Wednesday, May 19th, 2010

Golingo: a great Titanium mobile Web game, open sourced for you

Category: Appcelerator, Examples, Games

Jacob Waller created an addictive word came in Golingo. What sets it apart?

  • Not a single line of Objective-C written, courtesy of Titanium Mobile
  • Only one (!) image ingame – the rest is CSS3 magic
  • Fluid gameplay thanks to CSS Transitions and Animations
  • All logic using pure, beautiful JavaScript
  • Multitouch draggables using iPhone Touch API
  • Logic encapsulated using Low Pro – meaning split screen mode was easy pie
  • jQuery 1.4.2 for development speed (and sanity of developer)
  • CouchDB as highscore storage, with storage logic in JavaScript
  • Predictable randomness means replayable games, all courtesy of excellent seedrandom

Jacob dives into deeper into the full tool chain that he used in his post about open sourcing the code behind the game. That’s right, he wants you to fork it and do something amazing with the game. Pretty awesome if you ask me.

His tool chain:

He then goes on to talk about the initial construction of the game:

Most of the actual game was made in a few weeks time, but from scratch to published app it took almost six weeks of part time work. A lot of this time was spent banging my head into various walls. Again, Titanium is great, but it’s a young framework with all the kinks that follows. There has been quite a few bugs, and the documentation hasn’t always been up to date – but this is much better nowadays. What more – since most other developers are as clueless as yourself, It’s been hard finding good resources and getting help. I did however get a trial for Appcelerator’s Premium Subscription, with 48-hours guaranteed response, and I must say it’s really good stuff. The developers themselves answers all your stupid questions and relieves most of the wall banging. If you can afford it, go for it!

By releasing the code for Golingo, we hope to relieve some of the headaches surrounding developing packaged HTML5 apps. I do not say that it’s not full of faults, because it is, but at least it is a working example full of faults. Please don’t hesitate to dig through the code to see what is going on. We believe we’ve solved some common problems that you too will run in to when using Titanium, for example transparently calling native functions from a webview (and vice versa) using callbacks and trickery. Here’s a quick recap of that:

  • Connecting Titanium Contexts
  • Low Pro like a low pro: $(‘<div/>’).attachAndReturn(Letter, this, letter, specialLetter);
  • Sexifying: including templating with mustasche

Thanks for the great info and resource Jacob!

Posted by Dion Almaer at 12:01 am
Comment here

+++--
3.9 rating from 8 votes

Tuesday, May 18th, 2010

Scribd: Font face trickery and more

Category: Articles, Font

Scribd is my “favourite company of the month”. First they show off their move from Flash to HTML5 and now they are generously taking time to share with us details on their implementation in a three part series.

The first part delves into the bowels of @font-face, starting with the simple:

  1. @font-face {
  2.   font-family: 'Scrivano';
  3.   src: url('scrivano.eot');
  4.   src: url("scrivano.svg") format('svg');
  5.   src: local('\u263a'), url('scrivano.otf')
  6.   format('truetype');
  7. }

and moving to how they support angled text such as this:

How do you encode the diagonal text in this document in a HTML page?

Short of using element transformations (-moz-transform, DXImageTransform etc.) which we found to be rather impractical, we encode the above HTML with a custom font created by transforming the original font. Here’s how our generated font looks in FontForge:

From the above font screenshot you also notice that we reduce fonts to only the characters that are actually used in the document; that helps save space and network bandwidth. Usually, fonts in the pdfs are already reduced, so this is not always necessary.

Naturally, for fonts with diagonal characters every character needs to be offset to a different vertical position (we encode fonts as left-to-right). In fact, this is how other HTML converters basically work: they place every single character on the page using a div with position:absolute:

  1. <!-- crude pdf to html conversion -->
  2. <div style="position:absolute;top:237px;left:250px;">H</div>
  3. <div style="position:absolute;top:237px;left:264px;">e</div>
  4. <div style="position:absolute;top:237px;left:271px;">l</div>
  5. <!-- etc. -->

At Scribd, we invested a lot of time in optimizing this, to the degree that we can now convert almost all documents to “nice” HTML markup. We detect character spacing, line-heights, paragraphs, justification and a lot of other attributes of the input document that can be encoded natively in the HTML. So a PDF document uploaded to Scribd may, in it’s HTML version, look like this (style attributes omitted for legibility):

HTML version:

  1. <p>
  2.   <span>domain block is in a different image than the range block), as</span>
  3.   <span>opposed to mappings which stay in the image (domain block</span>
  4.   <span>and range block are in the same image) - also see Fig. 5.</span>
  5.   <span>It's also possible to, instead of counting the number of</span>
  6. </p>

Together with tags for graphic elements on pages, we can now represent every PDF document in HTML while preserving fonts, layout and style, with text selectability, searchability, and making full use of the optimized rendering engines built into browsers.

I am looking forward to part 2 and 3!

Posted by Dion Almaer at 11:10 am
8 Comments

++---
2.3 rating from 4 votes

Thursday, May 13th, 2010

Your Cappuccino Apps Just Became Desktop Apps

Category: Announcements, Cappuccino

The 280 North crew just released NativeHost, an open source component that takes your Cappuccino applications and makes them desktop apps, without you having to write a line of code:

Again, we feel that the ultimate distribution platform is the web, and that the desktop is almost a transitional necessity today. So with that in mind, we certainly didn’t want to create a tool that required adding a bunch of new API that won’t work online. However, we also wanted an experience that truly felt good on the desktop. NativeHost is able to accomplish this because it is so tightly integrated with Cappuccino. It provides a seamless experience to both the application developer and end user. The goal is to have any existing Cappuccino app just work on the desktop without requiring any new code.

This is manifested in an increasing number of integration points:

  • The Cappuccino “main menu” automatically populates the native Mac OS X menu bar. On other platforms it will do what is expected by users on that platform. For example, in a Windows version of NativeHost the menu would be attached the top of individual windows.
  • Cappuccino windows (CPWindow) automatically become “native” windows. In the browser Cappuccino windows are typically drawn inside the main browser window. In native host they become real operating system level windows that can be minimized, etc.
  • Secure access to the native file system without new API: use existing methods like XMLHttpRequest.
  • Cappuccino’s document architecture is integrated with the operating system.
    Operating system open/save panels are used.
  • Just like any native application your application can register itself to open specific file types. When the operating system requests that your application open a document that information is passed on to Cappuccino for your application to handle.

You can read more about the why and the how on their blog post. Desktop is one thing, but this makes you think about the next post from them that says that your app works in mobile worlds (very different constraints and all…. but still).

All good technology has a showcase, and this doesn’t fail. GitHub Issues is a new NativeHost app that shows you how a great app can live online and on the desktop. It is open sourced, and you get buzzword goodness in node, heroku, mustache, and more.

Posted by Dion Almaer at 4:47 pm
3 Comments

+++--
3 rating from 2 votes

l10n.js: JS localization library

Category: JavaScript

Eli Grey has been doing some great work that we will be featuring here on Ajaxian. First up we have his recent l10n.js, which is a JavaScript library that enables localization through the native JavaScript method intended for it, gracefully degrading if the library is not present. As it
gracefully degrades, you can make Ajax applications, JavaScript libraries, etc. that can be localized but not require l10n.js to function. There is already a placeholder method for all API calls as specified in the ECMAScript specification and is present in all JavaScript engines, so when l10n.js isn’t present, your application works fine. l10n.js can integrate various partial translations with main translations easily.

For example, you can define a base English (en) localization of your application, and then for slight variations such as American English (en-US), British English (en-GB), and Hixie English (en-US-x-Hixie / en-GB-x-Hixie), you can do partial localizations where appropriate.

You can point out localizations in a link tag such as:

  1. <link rel="localizations" href="path/to/localizations.json" type="application/x-l10n+json"/>.
  2.  
  3. <link rel="localization" hreflang="en-US" href="american-english.json" type="application/x-l10n+json"/>

and the localizations themselves can look like below (taken from the demo app):

javascript

  1. {
  2.     "en": {
  3.         "%title": "English - l10n.js demo",
  4.         "%info": "You are viewing an English localization of this page."
  5.     },
  6.     "en-US": {
  7.         "%title": "American English - l10n.js demo",
  8.         "%info": "You are viewing an American English localization of this page."
  9.     },
  10.     "en-GB": {
  11.         "%title": "British English - l10n.js demo",
  12.         "%info": "You are viewing a British English localisation of this page."
  13.     },
  14.     "pt": {
  15.         "%title": "Português - demo do l10n.js",
  16.         "%info": "Vocé esta a ver uma localização Portuguesa desta página."
  17.     },
  18.     "es": {
  19.         "%title": "Español - l10n.js demo",
  20.         "%info": "Mira ustéd una versión español de esta pagina."
  21.     },
  22.     "fr": {
  23.         "%title": "Français - Démo de l10n.js",
  24.         "%info": "Vous lisez une localisation en français de cette page."
  25.     }
  26. }

Now you can get access to the localized Strings via string.toLocaleString() which folks often alias so you can do l("%title.search").

What about variable replacement?

Eli suggests using short variable strings instead of default strings:

It saves bandwidth by decreasing the size of localization files, and it enables you to write nice, short code as such in the following.

javascript

  1. document.title = l("%title.search")
  2. //Example results: "Seach - Acme, Inc."
  3.  
  4. confirm(l("%confirm.deleteAccount"))
  5. //Example results: "Are you sure you want to delete your account?"
  6.  
  7. link.href = "http://www.google" + l("%locale.tld")
  8. // Example results: "http://www.google.co.uk"

Often, string concatenation is used instead of replacement in JavaScript. With l10n.js, to make localization easier, you may have to use replacements instead. You might want to use a JavaScript library that implements something similar to C++’s sprintf(). A nice JavaScript implementation I’d recommend is php.js’s sprintf().

This reminds me of the localization tools in webOS. You often see $L() code in a webOS application, as well as rich formatting options:

javascript

  1. return Mojo.Format.formatChoice(
  2.     numComments,
  3.     $L("0##{num} Comments|1##{num} Comment|1>##{num} Comments"),
  4.     {num: numComments}
  5. );
  6.  
  7. var data={num:10};
  8. var localizedText = $L("You have #{num} messages").interpolate(data);

Would be nice to bake in this kind of support in a more standard way.

Posted by Dion Almaer at 5:33 am
12 Comments

+++--
3 rating from 9 votes

Monday, May 3rd, 2010

Page Speed SDK released; HAR to Page Speed tool created

Category: Performance

Releasing the Page Speed SDK (all open source) is one step closer to having a common performance metric across all web development tools and environments. Imagine being able to get the same performance analysis results from Firebug, Web Inspector, HttpWatch, Fiddler, Keynote, and Gomez. This will help us develop a common vocabulary and bring more consistency and quality to the field of web performance optimization.

This is a quote from Steve on the new HAR to Page Speed work that he has built on top of other work:

The importance of an industry standard HTTP archive format is huge. Adoption of HAR allows companies and data gathering institutions (such as the Internet Archive) to record the web page experience and pull it up later for further review. It provides a way to exchange information across tools. And it provides an open standard for sharing web loading information between individuals – developer to developer as well as customer to customer support.

In their last few releases the Page Speed team has mentioned porting their performance analysis logic from JavaScript to C++. The resulting library is called “native library” – not too jazzy. But last week they released the Page Speed SDK. The documentation is slim, but I noticed a command-line tool called har_to_pagespeed.

I downloaded the SDK. It built fine on my Dreamhost shared server. Then I wrapped it with a file upload PHP page and created HAR to Page Speed.

Once you upload a HAR file you get page speed info and more:

For a full example, check out a CNN.com archive.

Posted by Dion Almaer at 6:55 am
Comment here

++++-
4 rating from 2 votes

Thursday, April 29th, 2010

MooTools 1.3b1: A “Slick” release

Category: JavaScript, MooTools

The first beta of MooTools 1.3 has become available. The biggest feature is their new CSS selector engine. They aren’t using Sizzle like some of the other boys, but instead have become Slick:

Slick is our new, shiny, super fast, exhaustively tested, pure-javascript selector engine. There will probably be a dedicated Slick post in the following days (or months, given our relaxed release cycles), but here’s a few Slick-facts for those who haven’t checked it out already:

  • Slick is a MooTools-family project by MooTools developers Thomas Aylott, Fabio Costa and yours truly. It can be forked from github, free of charge!
  • Slick is an incredibly advanced evolution of our previous selector engine.
  • Slick is written using only pure-javascript, none of the MooTools apis are required. It can be used in any project or framework, and it does not require MooTools to function (though the MooTools DOM components do require Slick).
  • Slick is speedy, blows away the 1.2 selector engine by 50%, at least. We will give you detailed data in the post dedicated to Slick.
  • Slick supports every selector you can think of. Seriously, every one of them. I promise you.
  • Slick is customizable, you can make your own pseudo-selectors, your own attribute-selectors, and many more your-own kinds of things.
  • Slick supports reversed combinators. You might not know what they are, but they are pretty darn cool.
  • Slick has a detached parser. You can parse a css-style-selector string and get back a property-filled object.
  • Slick perfectly supports XML documents.
  • Slick is slick!

This bleeds into some new APIs too.

For example, what you may have done like this:

javascript

  1. new Element("input", {"id": "someID", "class": "someClass1 someClass2", "disabled": true});

you can now do using selectors:

javascript

  1. new Element("input#someID.someClass1.someClass2[disabled=true]");

There are other features too:

Globals

MooTools 1.3 moves away from the $name functions. Most of the useless ones, such as $chk (god knows why I thought it was a good idea to have $chk), were completely nixed. Some of them moved to the proper object’s namespace ($merge » Object.merge, $pick » Array.prototype.pick). Some others were renamed without the stupid $ in front ($type » typeOf, $defined » nil). In the end, there are a lot less global variables now. You can refer to the 1.3 documentation to have a proper list of what’s changed. Keep in mind that the old version of the methods will still work, by default. There will be a way in the future to “compile” MooTools without the compatibility stuff, but the feature is not ready yet.

From types with love

Every native type has now a from method that will try to convert every object passed to that type. Array.from, for instance, replaces both $A and $splat. Function.from will return a function that returns the passed in value, if it wasn’t a function itself. String.from… well you know that at this point, don’t you? We also changed how we internally handle Native types, but that should be none of your concerns, since they were handled with private apis anyways.

Generating your own MooTools, from your own computer

It is now possible, easy, and even perhaps recommended to generate MooTools (and its plugins) yourself. Last few months I’ve been working, on and off, on a pretty advanced projects-builder. It’s called Packager, it supports multiple project dependancies and has a very similar syntax of what’s used in the Forge right now. It’s written in php and you can use it from your php webpages to dynamically include JavaScripts for development, or you can build a single .js for production from the command line.

Posted by Dion Almaer at 5:20 am
6 Comments

++---
2.3 rating from 4 votes

Tuesday, April 27th, 2010

TouchScroll: Implementing scroll physics in JS and CSS

Category: Mobile

touchscroll

David Aurelio of the awesome Uxebu has been working on TouchScroll, a library that implements scrolling in a way that mimics the native scrolling of a device such as an iPhone, Android, or Pre.

Other libraries such as jQtouch and the Mojo library itself (used in Ares) do this work too in their own worlds. Why did they do this?

While Safari Mobile features native scrolling, there are two reasons to re-implement scrolling with JavaScript: The original scrolling behavior is rather slow – we were looking for a solution that feels more fluid. And the viewport behavior of Mobile Safari and other mobile browsers using WebKit doesn’t allow for fixed positioned elements.

TouchScroll uses a combination of JavaScript and CSS?3. All animations are done with CSS transitions – no JavaScript timeouts. That means, the deceleration animation can be configured with a bezier curve.

The elasticity effect when crossing the scroller bounds is achieved by dividing the bezier curve into two sub-curves using my (yet to be finished) CSS Bezier library for JavaScript.

For fun, make sure to resize the window on the demo to a much smaller and then larger size…. and change the font size too :) Nice work. This is the kind of thing that really enables cross device support as devices slowly catch up with one another.

You can learn a lot about how to test for various scroll/mobile capabilities from David’s clean code too.

Update: David has released TouchScroll on GitHub and blogged about it here.

Posted by Dion Almaer at 6:10 am
2 Comments

++++-
4.2 rating from 6 votes