Activate your free membership today | Log-in

Monday, June 21st, 2010

From zero-install to instant-install

Category: Editorial

Aaron has a nice editorial piece on going from zero-install to instant-install in which he discusses the notion of web apps:

Bringing back a lightweight notion of installation offers an interesting way out of Web constraints. If an author uses APIs like window.open() and desktop notifications in an annoying way, his app will be uninstalled. The UA can make it easy for the user to discover the uninstall button, so there’s a strong incentive for authors to not be assholes. Since there are a manageable number of apps installed at any one time (by definition, since they were manually installed), UAs can offer permanent storage to apps. If the apps abuse the privilege, the user can easily scan a list, see which one is doing it and uninstall it.

He discusses the revolution of the “zero install” Web. We pass people URLs. We link to things. We don’t think of this as “running apps”. He then brings up the issues of this freedom. Since my mum doesn’t think of this as running apps, we shouldn’t grant access to these URLs, and we end up with a strong sandbox, which limits functionality.

With “installable web apps” we get some of the best of both worlds, but it doesn’t quite feel like we have matched a perfect equilibrium yet. As a power user, I am excited about taking a strong sandboxed model and opening it up with APIs that all go through the sandbox. This means that I can monitor everything that is going on. Add to this social monitoring (so if something bad happens it quickly moves through the social network to be fixed and blocked) and I look forward to a blended world of permissions. We have long had the ability to break through the sandbox in browsers. Unfortunately, these methods are browser specific, and result in annoying prompts that drive you nuts. As we scale out the permissions, this becomes more annoying. To get around this, some platforms are asking the user to accept permission at install time. You have the advantage that: a) the user has to agree before anything is even downloaded; b) one click, at the time of install, and you are off to the races.

However, there are huge problems: When prompted at this time, there is a strong likelihood that the user is trying to do something and will thus say YES YES YES no matter what. Some may question an 8-ball app that asks for deep permissions, but even then…. we run into the same prompty neglect that we get on the desktop. Have you ever downloaded a Mac app, ran it, and then when the “this app came from the Internet” dialog showed up…. said “you know what. Naaaah”? And what about nuance? Weather apps ask for access to the GPS. What if you want to use the app (and search for an area) but don’t want to give location information? Some systems won’t let you download the app (this is where the Web Geolocation API is great!)

Installable == special powers. Uninstalled == less powers. I still have hope that after these first steps we get the right metaphors that offer simplicity for users, but nice fine grained control and awareness.

Posted by Dion Almaer at 5:44 am 2 Comments

Studying perceived performance of Firefox and Chrome

Category: Browsers, Usability

“A man’s got to do what a man’s got to do.” said the cowboy John Wayne. Mozilla’s new intern with the same name knows that Mozilla needs to do… and it needs to do performance. It isn’t just about JavaScript performance though, the battle for the hearts and minds is perceived performance. This is a tough game for Mozilla as the average user giving Chrome a shot is doing so on a fresh browser with no history, bookmarks, or add-ons. If you download a fresh Firefox nightly you may be surprised at how fast it is!

John has been doing some analysis comparing the perceived performance compared to Chrome:

and came up with some recommended actions for the team:

  • With just a few changes in the Firefox start-up process, we could greatly enhance the feeling of Firefox’s speed. The changes listed below are recommendations to help better the overall Firefox experience.
  • Draw the OS spinner icon as little as possible, but one solid break isn’t bad and might be better than one really long spinner.
  • Draw the browser chrome while the window is being animated (drawn) to size. So that most of the drawing happens simultaneously rather than sequentially.
  • Make a new ‘website loading’ icon with less visual weight that animates faster but is slightly larger (would allow a user to ‘see’ the faster animation).
  • ‘Lazy’ load tabs that are being restored (already being talked about).
  • Load upgrades and add-on updates upon browser close, not browser start.
  • Delay loading the website’s title until the website is ready for interaction.

Posted by Dion Almaer at 5:21 am 6 Comments

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:

CSS:
@brand-color: #3879BD;

.rounded(@radius: 3px) {
    -webkit-border-radius: @radius;
    -moz-border-radius: @radius;
    border-radius: @radius;
}

#header {
    .rounded(5px);
    a {
        color: @brand-color;
        &:hover {
            color: #000;
        }
    }
}
 

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

HTML:
<link rel="stylesheet/less" href="/stylesheets/main.less" type="text/css" />
<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 15 Comments

Friday, June 18th, 2010

Scaling UI controls appropriately on the mobile Web

Category: JavaScript, Mobile, Usability

Using the mobile Web with modern devices that give you the "full Web" and allow you to zoom in and out on the page (if zooming hasn't been turned off of course).

Sam Stephenson (of Prototype and 37Signals fame) has taken on the problem of the sizing of controls. If you zoom out, normally, controls are smaller in the same proportion as the rest of the content. In reality, you want nice large controls that are tap friendly. This is where his device scale technique comes in:

He also talks about how he takes hover elements and makes them tappable to get the same item shown or hidden.

Posted by Dion Almaer at 6:04 am 3 Comments

Inline content assist for text fields and areas

Category: Component, JavaScript, Library

Sergey Chikuyonok has created a really nice, easy to use, and good looking content assist library for input text fields and text areas:

It calculates precise position of characters in <textarea> or <input> tag and places completion proposals popup under it. You can explicitly call popup window to assist/replace word (depends on caret position) with Ctrl+Space (buggy in Firefox and Opera) or Alt+Space (buggy in Opera). The project is based on Eclipse IDE's content assist architecture, it has some common class names and methods. The default implementation works with fixed words vocabulary, but developers can easily modify or extend some classes to match their needs.

The API is easy to use. For example:

JAVASCRIPT:
var words = 'after,any,also,around,another,ask,again,air,away,animal,answer,america,awesome,amazing'.split(',');
new BasicContentAssist(document.getElementById('input'), words, {visible_items: 5});
 

Posted by Dion Almaer at 5:12 am 4 Comments

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

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

OO app framework with layout and components

JAVASCRIPT:
Geo.App = Ext.extend(Ext.Panel, {
    cls: 'app',
    fullscreen: true,
    layout: 'card',
    activeItem: 0,
   
    initComponent: function() {       
        this.startScreen = new Geo.views.StartScreen({
            flex: 1
        });
        this.splash = new Ext.Container({
            cls: 'splash',
            layout: {
                type: 'vbox',
                align: 'stretch',
                pack: 'end'
            },
            listeners: {
                deactivate: this.onSplashDeactivate,
                scope: this
            },
            items: [this.startScreen]
        });
        this.detail = new Geo.views.LegislatorDetails();
       
        this.items = [this.splash, this.detail];
        Geo.App.superclass.initComponent.call(this);
       
        this.startScreen.on('legislatorselect', this.onLegislatorSelect, this);
    },
   
    afterRender: function() {
        Geo.App.superclass.afterRender.apply(this, arguments);
        Ext.getBody().on(Ext.isChrome ? 'click' : 'tap', this.onLinkTap, this, {delegate: 'a.goOutside'});
    },
   
    onLinkTap: function(e, t) {       
        e.stopEvent();
        Geo.Util.openUrl(t.href);
    },
   
   
    onSplashDeactivate: function() {
        this.startScreen.list.clearSelections();
    },
   
    onLegislatorSelect: function(govtrack_id) {
        this.setCard(this.detail, Geo.defaultAnim);
        this.detail.update(govtrack_id);
    }
});
 

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 10 Comments

Sencha Touch: The end of native; A new touch framework for the Web

Category: JavaScript, Library, Mobile, Sencha

As I walked around Moscone last week, I saw some prophets speaking of a future that isn't all Native. A future where the Web is the platform. Others saw it too:

I pondered who would be behind the act and smiled as I had a good idea. The group behind this all is the newly named Sencha (formerly Ext JS). On the back of news of the new company and Sencha Labs, we get a glimpse of their new product: Sencha Touch:

Sencha Touch allows your web apps to look and feel like native apps. Beautiful user interface components and rich data management, all powered by the latest HTML5 and CSS3 web standards and ready for Android and Apple iOS devices. Keep them web-based or wrap them for distribution on mobile app stores.

There are some good demos of apps such as GeoCongress, which shows off:

  • HTML5 Geolocation
  • Sench Touch icon set
  • JSONP Proxy
  • YQL Data Proxy
  • Momentum scrolling
  • Scroll touch event
  • Pop-up Overlays
  • Mobile form elements
  • CSS3 Gradients
  • CSS3 Transitions
  • Multi-Card Layout
  • Tab Panel Component
  • Scrollable list view
  • Swappable headers

Once you see what the framework can do with examples, what better way to get a deeper look than walking though as much of it as possible? Michael Mullany, VP Products, sat down and gave us just that. Sencha Touch comes with a "kitchen sink" demo that shows off much of its abilities. Here we see Michael showing off said demo:

After seeing this at work, we asked Michael some questions about the new product:

How are Ext JS, jQTouch, and Sencha Touch related?

We talked about some of this in the Sencha name change post. Jonathan Stark is taking over jQTouch maintainership, Dave Kaneda will remain involved but he's been spending most of his energy on Sencha Touch. Sencha Touch has some Ext JS DNA (OO javascript, a lot of the data package is common), but the UI components are completely different.

Having David part of Sencha Touch has been incredibly important. That's one of the reasons why the UI components are staggeringly beautiful, and there's been so much attention to ease of styling.

With respect to jQTouch vs. Sencha Touch. jQTouch is a good solution for people who need some progressive enhancement of web content, but it's not a full application framework.

What is the licensing plan for Sencha Touch?

The initial beta is under a GPLv3 + FLOSS license. We’d like to give open source folks the benefit before we introduce a commercial trial license. And we’d like to take the opportunity to emphasize something that many people miss: that we have Free and Open Source exceptions as part of our GPLv3 license. So if you want to, you can include Sencha Touch in your Apache and OSI approved licensed projects without triggering the GPL’ing of your project.

Can I make native looking controls for the particular platform at runtime?

In the beta, you can build multiple themes easily (for example, our Android theme is 20 lines of customized SASS), and serve them up to different clients based on user agent. We do want to provide a client-side switcher by release time. SASS is really an extraordinary technology. This would be far, far harder without it.

Are there any differences between it running on various platforms?

There are some minor differences, for example CSS 3D Transitions don't work on Android, for example (no cube transitions). And Apple GPU accelerates more stuff. You can look at our demo apps across iPhone and Android. They really do work cross-platform.

How do I do layout with Sencha Touch?

We think most people will use fairly simple layouts with the built-in components since the screen sizes are small. Tabs, carousels, lists. If they want to get more complex, they can use the more complex layouts or just extend the built-in classes.

Can I create native apps from these? How do I access native services on the device?

Right now, you're going to take Sencha and wrap it with phone-gap. But about two third of non-game apps don't do any special device access, and camera access is on its way.

How does Sencha Touch feel to program (e.g. just like Ext?)

It's still object oriented javascript but it's really very simple. People can just look at the source to the demo apps (which are reasonably rich apps) and make their own decision.

Can I progressively enhance a mobile Web app and sprinkle in some of this goodness?

I think the success of iPhone native mobile apps shows that for mobile factors, it's better if you think about layout and navigation first, then pour content into your containers & paths. In many ways, I think it's the reverse of the desktop web. Desktop web apps can be random access in their user pathing, mobile apps have to be hierarchical or otherwise constrained -- because you don't have a lot of space and you can't waste it on navigation controls.

Posted by Dion Almaer at 8:00 am 14 Comments

Modernizr: Point and see how modern you are

Category: Library

Modernizr detects feature support across JS APIs and CSS. Now, there is a simple
page that shows you what Modernizr thinks of your browser:

Posted by Dion Almaer at 6:32 am 5 Comments

Wednesday, June 16th, 2010

JSKB: JavaScript Knowledge Base. Shrinking your code via BrowserScope and Caja

Category: Performance

We have a screwed up tensions on the Web. The size of your source code really matters for performance. The larger your .js.... the longer it takes it to get down the pipe. This has a perverse incentive to write terse uncommented code. Add to this the problem of having to work cross browser, and having to do so all at runtime, and you end up shipping a ton of code to browsers that will never touch it.

This is where Mike Samuel of Caja, and Lindsey Simon of Browserscope come in. They have a plan to help reverse code bloat with JavaScript:

Lots of compilers (incl. (JSMin, Dojo, YUI, Closure, Caja) remove unnecessary code from JavaScript to make the code you ship smaller. They seem like a natural place to address this problems. Optimization is just taking into account the context that code is going to run in to improve it; giving compilers information about browsers will help them avoid shipping code to support marginal browsers to modern browsers.

The JavaScript Knowledge Base (JSKB) on browserscope.org seeks to systematically capture this information in a way that compilers can use.
It collects facts about browsers using JavaScript snippet. The JavaScript code (!!window.JSON && typeof window.JSON.stringify === 'function') is true if JSON is defined. JSKB knows that this is true for Firefox 3.5 but not Netscape 2.0.

Caja Web Tools includes a code optimizer that uses these facts. If it sees code like if (typeof JSON.stringify !== 'function') { /* lots of code */ } it knows that the body will never be executed on Firefox 3.5, and can optimize it out. The key here is that the developer writes feature tests, not version tests, and as browsers roll out new features, JSKB captures that information, letting compilers produce smaller code for that browser.

The Caja team just released Caja Web Tools, which already uses JSKB to optimize code. We hope that other JavaScript compilers will adopt these techniques. If you're working on a JavaScript optimizer, take a look at our JSON APIs to get an idea of what the JSKB contains.

You can see graphically how this works and learn more about how browser detection info is packaged:

JAVASCRIPT:
{
  "!!this.window !== 'undefined' && this === window": true,
  "typeof addEventListener": "function",
  "typeof attachEvent": "undefined"
  "typeof document.body.outerHTML": "undefined",
}
 

Definitely feels like there is a lot of room to do more with a compilation step that only sends down the right JS for the given browser.

Posted by Dion Almaer at 8:16 am 10 Comments

POC ePub Book Reader Booktorious

Category: JavaScript

I checked out this new POC app called Booktorious by August Lilleaas. It's actually pretty neat in that it's a 100% client side web application that reads EPUB books. So I jumped over to epubBooks and downloaded Through the Looking-Glass just to see how far down the rabbit hole I could go with this (sorry couldn't resist). The book rendered perfectly and performance was decent considering the whole thing was being loaded at one time.

All of the code is homegrown JS, CSS & HTML leveraging August's set of frameworks Sarge, Mediocre, and CopperPlate.

August has uploaded the code for Booktorious to Github so feel free to play around with it.

Posted by Rey Bango at 7:00 am Comment here

Guess the color. Hex geekery.

Category: Fun, Games

How hex geeky do you feel today? Take a sec to guess the hex!

Posted by Dion Almaer at 3:23 am 1 Comment

Tuesday, June 15th, 2010

Raphaël paints some logos and gives them to you for free

Category: Design

Raphaël. Painter. Turtle. One the back of the fact that Raphaël will continue to do great things in the JS space due to Sencha Labs funding we have another little gift.

104 MIT licensed icons:

Go check out the page and zoom in to see the vector goodness.

Posted by Dion Almaer at 3:16 pm 3 Comments

Sencha = ExtJS + jQTouch + Raphaël + Connect

Category: Sencha

Whenever you name your company after your first product you run into the issue that people think that is who you are. The company behind ExtJS has grown up a lot recently, and partly to show that, now come to you as Sencha, a new identity.

They have also clearly separated their GPL/commercial offerings from their MIT projects.

Sencha Products

  • Ext JS for web developers — for quickly building rich, sustainable web applications for desktop browsers;
  • Ext GWT for Java developers — enables Java developers to build rich user experiences leveraging the Google Web Toolkit compiler;
  • Ext Designer — for easily assembling user interfaces using drag-and-drop functionality.

Sencha Labs

  • jQTouch: a progressive enhancement style, mobile library providing lightweight animation and UI plugin for JQuery;
  • Raphaël: a rich SVG library for developing vector graphics applications on the web;
  • Connect: an application framework that combines Rack and Node.js to provide a lean, event-driven application server.

Hiring Dmitry Baranovskiy to work full time on Raphaël is awesome, and Jonathan Stark is now running jQTouch. David Kaneda, creator of jQTouch, is also at the company and I think we will hear about what he has been working on soon.

It really feels like the new crew behind Sencha are looking to be a driving force for the HTML5 revolution, breaking out beyond their strong Ext* roots. It is going to be exciting what they announce next..... a prophet once told me .....

Posted by Dion Almaer at 8:26 am 8 Comments

Suburban World; The fantastic HTML5 Aves gaming engine is back

Category: Games

Do you remember being really impressed by the initial Aves game engine that uses Canvas and HTML5 technology to deliver a compelling social gaming platform on Web technology? Well, now the Dextrose crew are back in action having released their second prototype of their upcoming browser-game middleware at E3 2010 in Los Angeles:

The new prototype is shown live to interested licensees and magazine editors on the exhibition floor. Additionally, a video with six minutes of in-game footage has been released on YouTube. Compared to the medieval-styled prototype from some weeks ago, Dextrose introduces even more innovation and performance boosts not yet seen in the browsergames industry.

  • unbelievable performance in the browser: Aves Engine renders hundreds of players in realtime in one viewport
  • introduces innovative Action Surface-Technology which allows the integration of any Web 2.0 or custom widget into your game
  • high-scalable viewports to any screen resolution size with nearly no performance impact
  • very large optimizations towards the mobile market. Technical stunning games now possible on WebKit-based Smartphones and iPad
  • a refurbished and extended realtime world editor
  • sprite animation classes

I had a chance to play with the prototype, and man was it nice. The iPad is fairly underpowered when it comes to intensive tasks like this, and it works very well indeed. The team had to spend a lot of time optimizing the engine for that form factor, and they are now in good steed for other mobile devices.

Moving around the world with iPad and laptops alike showed how well the UI keeps up with goings-on. This is because good old Mr. NodeJS is behind the scenes scaling up nicely for the crew. The multiplayer engine is smart enough to gracefully failback from WebSockets to long polling to standard boring polling that the iPad requires. All seamless to the programmer. The developer just gets to riff on top of the simple to hack on game engine.

Since the engine is built on the Web, the team could create Web surfaces with ease. This enables you to create mashups of content to embed directly into the game. Walk up to a laptop monitor in the game and see that it has a real browser window embedded and play with it. The world is truly your oyster with this engine.

If you are interested in building up a large player world, and want to get across a myriad of devices thanks to the Web platform, look this up to give it a roll.

Great work guys!

Posted by Dion Almaer at 7:28 am 4 Comments

Y.preload: load before execution

Category: Performance

Caridy Patino has posted on a new YUI3 module for preloading of content, implementing Stoyan's ideas.

You can now strap on some preloading goodness to your YUI application:

JAVASCRIPT:
YUI({
    //Last Gallery Build of this module
    gallery: 'gallery-2010.05.05-19-39'
}).use('gallery-preload', function(Y) {
  Y.preload ([
    'http://tools.w3clubs.com/pagr2/1.sleep.expires.png',
    'http://tools.w3clubs.com/pagr2/1.sleep.expires.js',
    'http://tools.w3clubs.com/pagr2/1.sleep.expires.css'
  ]);
});
 

As well as just loading away, you can also wait for the user to focus on something on the page before reloading:

JAVASCRIPT:
Y.on("focus", function() {
    Y.preload ([
      'http://tools.w3clubs.com/pagr2/2.sleep.expires.png',
      'http://tools.w3clubs.com/pagr2/2.sleep.expires.js',
      'http://tools.w3clubs.com/pagr2/2.sleep.expires.css'
    ]);
}, ".myform input.query");
 

Or, to take it even further, only preload if the user is probably idle:

JAVASCRIPT:
Y.preloadOnIdle ([
    'http://tools.w3clubs.com/pagr2/3.sleep.expires.png',
    'http://tools.w3clubs.com/pagr2/3.sleep.expires.js',
    'http://tools.w3clubs.com/pagr2/3.sleep.expires.css'
  ], 100); // ms
 

Nicely packaged.

Posted by Dion Almaer at 6:13 am Comment here

Monday, June 14th, 2010

animateWithCSS: Aza’s jQuery Plugin

Category: Animation, CSS

JAVASCRIPT:
// Makes all paragraph elements grow a border and then atrophy away.
$("p").animateWithCSS(
  {border: "5px solid #555"}, // CSS properties to animate
  1000,                       // Duration in ms
  "cubic-bezier",        // The timing function
  function() {              // Callback
    $("p").animateWithCSS({border: "0px"}, 350);
  }
);
 

Above is an example of Aza Raskin's jQuery plugin that sits on top fo CSS transforms.

The code renders this:

What is maybe even more interesting, is the critique into CSS transitions:

Better timing functions. While using a cubic bezier curve is clever—it packs a lot of variation into just four numbers—it isn’t enough. While I was able to create a basic bounce animation, not only does the spec explicitly disallow it, but I can’t control even the basic parameters of the bounce (like how fast it returns). As John Resig mentioned in a blog post, it would be nice to supply a custom Javascript timing function (although this might break the ability to do hardware acceleration). A more CSS-like solution might be to allow authors to provide an arbitrary number of control points for a series of linked quadratic or cubic bezier curves (and to not restrict the y-axis points to the 0 to 1 range). That would enable fine-grained control of timing without requiring Javascript.

Ability to layer two animations on top of each other. If I’ve started an animation moving an element to the left, and half-way through want to start animating its opacity at a different rate, things get complicated very quickly. And by complicated, I mean impossible.

Ability to register an on step handler. We can currently register a “transitionend” event handler. I’d like to be able to do the same for “transitionstep”. This would make CSS Transitions potentially much more versatile—and allow frameworks to keep innovating on top of the transitions base instead of reverting to pure Javascript animation.

Posted by Dion Almaer at 5:36 pm 11 Comments

Next Page »