Author Archive: Kin Blas

jQuery Mobile 1.0 Released

jQuery Mobile 1.0 Final
One year ago, we set out to find a framework that would help our customers to extend the reach of their content to as many screens as possible. The framework we were looking for had to be easy to “tool around”, easy for our customers to understand and use, and most importantly follow web best-practices.

At the time, it seemed like most of the existing frameworks were either too focused on the desktop or emulating a single device platform, too large for use in mobile environments, or required a certain level of coding knowledge to actually use. Just when it was looking like nothing would match our requirements, a single blog post, announcing the start of a new project called “jQuery Mobile”, gave us a bit of hope. After talking a bit with John Resig (jQuery) and Todd Parker (Filament Group) about this new project, we were excited not only because of their intent to target most mobile platforms, but because they were determined to build an easy to use framework based on the principals of progressive enhancement and accessibility. This framework was exactly what we were looking for, so we decided to help contribute to the effort to make it a reality.

Today, the team is excited to announce the release of jQuery Mobile 1.0.

It’s been a great experience for us here at Adobe and we’d like to thank the many folks that have contributed their time and effort, filing issues, testing, debugging, fixing and giving feedback to the project. It was truly a community effort. We’d especially like to thank Todd Parker, Scott Jehl, Mat Marquis, John Resig, and Ghislain Seguin for allowing John Bender, Tyler Benziger, Jorge Taylor, and myself, to participate and learn, while at the same time having fun building something that will hopefully help others.

jQuery Mobile RC 3 Available

jQuery Mobile 1.0 Release Candidate 3 is now available for download and testing. We had originally planned on going directly to final, but we’ve been fixing lots of bugs and making performance tweaks and wanted to make sure 1.0 final was solid. Unless we find a serious regression, RC3 will become 1.0 final later this week, so consider this a preview.

Some of the key changes for RC3 include:

  • Page enhancement performance improved
  • New config switch for turning off automatic link handling
  • Support for specifying an overlay theme for both dialogs and custom select menus
  • More documentation
  • Lots of bug fixes

One important detail to note is that jQuery Mobile 1.0 is being tested and released against jQuery 1.6.4. We will officially switch over to jQuery 1.7 in the jQuery Mobile 1.1 release.

Full details can be found here:

For information on how to download or insert jQuery Mobile into your pages, go here:

A demo of jQuery Mobile 1.0 RC3 can also be found here:

The team is currently focused on testing and updating documentation. If you have any issues or enhancement requests, please file them in the jQuery Mobile issue tracker on GitHub so they can be considered/addressed for the 1.0 final or later release:

Theme Roller for jQuery Mobile (beta)

Theme Roller for jQuery Mobile Logo

The team is excited to announce the availability of the new Theme Roller for jQuery Mobile tool, developed by Adobe’s very own Tyler Benziger, in conjunction with the fine, and very talented, folks from the Filament Group.

Theme Roller for jQuery Mobile Screen Shot

If you’ve used the Theme Roller for jQuery UI, the tool should feel very familiar to you, but there are a few enhancements worth mentioning. Aside from building a theme and downloading it for yourself, you can generate a URL for your theme and share it with others. Simply pass the URL along to your friends/co-workers, and once they load it, they can edit or download the theme you created. Another great feature is the ability to import your theme CSS directly into the tool for updating/editing at a later date. This comes in quite handy when you need to make a slight tweak or add more swatches as you make changes to your existing jQuery Mobile application.

Kuler Integration Screenshot

The last feature we’re especially excited about is the integration with Adobe’s Kuler App Service, which gives you access to the library of color sets created by designers within the Adobe Community. You can search for color sets by color, view the most popular or most recent, or even get random suggestions to help spark your creativity.

The Theme Roller for jQuery Mobile source is open and available on Git Hub:

Give Theme Roller a spin and be sure to give us feedback. You can file enhancement requests and issues in the project issue tracker:

For more details on this release, be sure to check out the official jQuery Mobile blog post:

jQuery Mobile RC 2 Available

jQuery Mobile 1.0 Release Candidate 2 is now available for download and testing. The team is excited to announce that as of RC2, we have now covered all target platforms outlined within our graded browser matrix. This means that we currently have support for the majority of all modern desktop, smartphone, tablet, and e-reader platforms. Also, since we use a progressive enhancement approach, we are able to support feature phones and older browsers.

Some of the key changes for RC2 include:

  • Expanded support for HTML5 date, time and color input types
  • New helper class for hiding elements in an accessible way
  • Custom selects: now work in controlgroups
  • Fixed toolbar improvements
  • New: Theme vs. structure stylesheets

Full details can be found here:

For information on how to download or insert jQuery Mobile into your pages, go here:

A demo of jQuery Mobile 1.0 RC2 can also be found here:

The team is currently focused on fixing bugs and improving performance. If you have any issues or enhancement requests, please file them in the jQuery Mobile issue tracker on GitHub so they can be considered/addressed for the 1.0 final release:

Adobe Edge Preview 3 Available

Adobe Edge Preview 3 is now available on Adobe Labs:

Edge is Adobe’s new Motion and Interaction Design tool that allows designers to bring animated content to websites, using web standards like HTML5, JavaScript, and CSS3. Below, I’ll briefly cover a few of the new additions in Preview 3 and hopefully give you some background and tips that help to get you going.

Preview 3 adds support for interactivity in the form of actions and timeline triggers which execute a custom JavaScript function, defined by you, whenever a specific event occurs on an element, or a time offset within a timeline has elapsed. Actions and triggers provide powerful hooks for manipulating the timeline, elements on the page, or for calling out to your application specific code to accomplish some task. To kick-start the use of actions and triggers, a small library of code snippets has been provided in both the actions and trigger panels in Edge, which allow you to insert the code for common tasks with just a click of a button. The snippets are a great way to get a feel for the types of things you can do with an action or trigger. It’s also a good way to start learning the basics of the Edge Runtime API which the team has started to document here:

Since the Edge Runtime itself uses jQuery 1.6.2, the code for your custom action/trigger functions can make full use of the jQuery core API.

Here are some things to keep in mind when writing your custom event/trigger functions:

  • Your actions and triggers are written to a JavaScript file with the same name as your HTML file, but with an “_edgeActions.js” appended to it. So for example, if you saved your composition to “foo.html”, you will find your actions and triggers in a file called “foo_edgeActions.js”.
  • Within the Actions and Trigger panel, you only type in code for the body of your custom function. You will never have to type the function keyword, or the function signature and curly braces. The Edge Runtime will call your code as if it were defined in a function with one argument named ‘e’, which is the event object for the event your action was bound to. So for example, if you added a “click” action to an element that displays an alert() with the coordinates of the click, you would type something like the following into the Actions panel:
    	// Display an alert to show the coordinates
    	// of the event.
    	alert(e.type + “ event was triggered on #” + + " at " + e.pageX + ", " + e.pageY);

    When you actually click on the element, the Edge Runtime will call your code as if it were declared in a function like this:

    	function ( e )
    		// Display an alert to show the coordinates
    		// of the event.
    		alert(e.type + “ event was triggered on #” + + " at " + e.pageX + ", " + e.pageY);
  • The “this” reference within your custom function will always be the symbol instance that contains the element or timeline your action/trigger was bound to. For preview 3, this symbol instance is always the stage. This makes manipulating the timeline easy since you can simply call or this.stop() directly on the stage object from within your custom function. For instance, one common question folks have is how to create an animation that loops continuously? In Preview 3 you would simply create a trigger at the very end of your timeline, and add the following code to your custom function:
    	// When this trigger is hit, restart the timeline by
    	// calling play with a time offset of zero.
 0 );
  • When creating closures within your custom function, make sure you save an instance of the “this” reference in a local variable if it is used within the closure.
    	// Save the symbol into a local variable
    	// so that we can refer to it from our
    	// our closure passed to setTimeout().
    	var stage = this;
    	setTimeout(function() {
    	}, 60000);
  • The output for Preview 3 has been modified in such a way that allows for multiple Edge compositions to be combined into a single HTML document. Since compositions are created independently, and sometimes by different people, there is always the chance that the names used for objects within these compositions could collide. To get around this the Edge Runtime dynamically maps object names into unique ids. When using some of the code snippets, mentioned above, you may notice the use of a symbol method called lookupSelector(). This method converts the object name into a unique CSS id selector that can be passed to jQuery so that it can actually find the object/element in the DOM.
    	$( this.lookupSelector( "Text1" ) ).hide();

If you want to manipulate the timeline or one of the elements within the stage from a context outside of an action or trigger function, you will need to know this little tidbit. The stage for every composition is tagged with a unique class name. If you look at the HTML document for your Edge composition, you will see a div within the body that looks something like this:

	<div id="stage" class="EDGE-1952485">

You can use this class name to get a reference to the stage object so you can manipulate the timeline for that stage, or to find a particular object within the stage:

	//in yourCode.js

	var stage = Edge.getComposition("EDGE-1952485").getStage();
	$( stage.lookupSelector("Text1") ).hide();

When creating your own Actions within Edge, you’ll notice options for binding to the usual mouse and touch events. You might also notice that there are a set of events that have the same name as the mouse events, but are prefixed with the lettter ‘v’:

  • vmouseover
  • vmousedown
  • vmouseup
  • vmouseout
  • vclick

The idea behind these “virtual” mouse events is to allow you to bind your action function to a single event that, under the hood, can be triggered by either a native mouse event, or the equivalent touch event on a touch device. The event object that is actually passed into your callback function is normalized to look just like a normal mouse event, so you can write your function to consume this virtual event like you normally do with mouse events on the desktop. Support for these virtual events is actually provided through the use of the standalone jQuery Mobile virtual mouse plugin which hides a lot of the complexity involved when dealing with both mouse and touch events, especially on devices that support both.

That’s about it for now. Download Edge Preview 3 and try-out the new interactivity features within your compositions. Please send any feedback, questions and requests, and samples of the compositions you’ve built, to the team via the Edge forum:

jQuery Mobile 1.0 RC 1 Available

jQuery Mobile 1.0 Release Candidate 1 is now available for download and testing. This release contains numerous bug fixes and some much needed updates to the framework documentation.

The team is also very excited to announce the development of a new Theme Roller Mobile tool, spearheaded by our very own Tyler Benziger, which makes it incredibly easy to create jQuery Mobile themes in just minutes, without having to edit a single line of CSS. Also in the works is a Download Builder tool which allows you to generate custom versions of the jQuery Mobile framework JavaScript and CSS files. Simply choose the components you wish to use, and the Download Builder will take care of building the custom full/minified JavaScript and CSS files necessary to support those components.

Full details can be found here:

You can see a video preview of the new Theme Roller Mobile tool here:

For information on how to download or insert jQuery Mobile into your pages, go here:

A demo of jQuery Mobile 1.0 RC1 can also be found here:

The team is currently focused on fixing bugs and improving performance. If you have any issues or enhancement requests, please file them in the jQuery Mobile issue tracker on GitHub so they can be considered/addressed for the 1.0 final release:

jQuery Mobile Beta 3 Available

jQuery Mobile Beta 3 is now available. Updates Among the numerous bug fixes made, some new enhancements were added including, support for pushstate, on platforms that support it, event hooks for allowing developers to inject or modify pages dynamically, and support for the iOS 5 -webkit-overflow-scrolling:touch property. Full details can be found here:

Be sure to check out the video demo of the -webkit-overflow-scrolling support here:

You can also play with the live demo used in the video here:

For information on how to download or insert jQuery Mobile into your pages, go here:

Finally, we are now driving towards the 1.0 release. Focus will be placed on fixing bugs and improving performance. If you have any issues or enhancement requests, please file them in the jQuery Mobile issue tracker on GitHub so they can be considered/addressed for the 1.0 release:

jQuery Mobile Beta 2 Available

jQuery Mobile Beta 2 was released last night. It includes some user requested enhancements such as the ability to enhance dynamically added content, DOM cache management, page pre-fetching, and the ability to delay framework initialization.

The complete list of enhancements/changes for Beta 2 can be found here:

Download information here:

One important change to note with this release is the updated Mobile Grade Browser Support matrix, which includes several new platforms in the A-Grade support level:

If you have any issues or enhancement requests, please file them in the jQuery Mobile issue tracker on GitHub so they can be considered/addressed for the pending 1.0 release:

Adobe Edge Preview 1 and jQuery

Adobe recently released Preview 1 of Adobe® Edge, a new web motion and interaction design tool, on labs:

Edge allows a designer to create animated content for websites, using web standards like HTML5, JavaScript, and CSS3. To get an idea of the types of animations you can create, be sure to check out the “Getting Started” video and samples:

jQuery is one of the key components in Edge’s implementation. It is used both internally, within the application itself, and within the final animation output it produces, to evaluate selectors and manipulate/traverse the DOM.

The animation output produced by Edge does not make use of jQuery’s $.animate() function. Edge uses its own declarative representation and implementation of timelines and tweens. This representation is designed to be highly flexible yet toolable and human-readable.

Edge Preview 1 uses jQuery 1.4.2. Succeeding Previews will use newer versions of jQuery, and the next release is expected to use version 1.6.2.

Please keep in mind that this is a preview, not a beta, or finished product so there is still quite a bit of work to be done on the product itself. Also, the Edge team is aware of the many ways to animate content with open web technologies (JS, CSS3, Canvas, SVG, etc). For this preview, the focus was on basics, specifically, animation of elements within the HTML document DOM. We’ve heard loud and clear from the community about their desire to animate content within canvas and SVG elements. I assure you that the team has already thought about support for content inside these elements, and so there are already implementation requests for these features in the Edge product backlog.

Give Edge a whirl and send any feedback, questions and requests to the team via the Edge forum:

The Current State of (Touch) Events

One of the main goals of the jQuery Mobile project is to allow developers to extend the reach of their application content to a wide variety of browsers on different devices. If you take a look at some of the web-enabled devices that are currently out on the market, you will see that there are many different means being employed to allow users to navigate and click/activate elements within a web page.

Older or low-end devices, with no touch screen support, usually have hardware buttons, scroll-wheels, nubs/joysticks, or track-balls. Devices that use buttons and scroll-wheels usually scroll the page, highlighting actionable (clickable) items along the way. When the user activates the highlighted element on screen, a click event is usually dispatched to trigger any actions associated with that element. Devices that use nubs/joysticks or track-balls typically display a cursor on screen, and usually dispatch mouse and click events just like the desktop. The main point to note here is that the browsers on these devices are using the standard desktop mouse events to trigger actions on a web page.

Newer or high-end devices, now rely on touch screens as the main means for scrolling and manipulating items within the display. Although there are many options for browsing the web on these devices, a growing number of  them are deploying WebKit based browsers as the default.

One of the common misconceptions I hear quite frequently is the assumption that because all these browsers are all based on WebKit that they all share the same features and work identically. The reallity is that WebKit is just a rendering engine with a set of APIs that allow developers to write browsers on top of it to communicate and drive the rendering of the page. It doesn’t know how to load a file, it doesn’t know what hardware/platform it is running on, what graphics library is being used to render objects to the screen, or even how to deal with OS level events.  All of these things are what browsers, built on top of WebKit, need to provide, and this is what is going to make things interesting and challenging for the next few years. All of these WebKit based browsers are either written entirely by the device vendor, or supplied with the OS, but modified by vendors to work better with their hardware and/or add/remove browser and Web Kit features.

All of these factors create a mobile environment where there are lots of WebKit based browsers, but the features they support, performance, and user experience all vary quite a bit.

When Safari for mobile hit the scene, via iOS, it introduced a set of new touch events:

  • touchstart
  • touchmove
  • touchend
  • touchcancel

These are the DOM-level events that Safari mobile dispatches in real-time as the user places one or more fingers (touches) on the screen and drags them around. The big problem is that most of the pages on the web assume the use of mouse and click events. To keep most web pages functional, mobile Safari dispatches synthesized mouse events after the user lifts his finger so the web page receives a series of mouse events in the following order:

  • mouseover
  • mousemove
  • mousedown
  • mouseup
  • click

At this point you may be asking “why didn’t the Safari folks just use mouse events instead of creating a whole new set of events?” I think the answer has to do with the fact that the iOS devices support multi-touch. On traditional computing platforms there was always a notion of a single mouse with a main (left) button and maybe center and right buttons. Although you could click and hold down these buttons at different times to generate multiple overlapping mousedown and mouseup events, they were still tied to a single source for the move/positioning information.  Also, folks have become accustomed to the fact that these buttons do specific actions. For example right mouse buttons are typically associated with bringing up a context menu, etc. With the new multi-touch events, not only can you have more than 3 touches, each touch generates its own set of touchstart, touchmove, and touchend events, and in some cases touchmoves could be coalesced into single events if more than one touch shares the same target. It suffices to say that the newer touch events are fundamentally different in behavior and perhaps the Safari folks did not want to break or modify the well established mouse usage and behavioral model.

There are a few interesting things to note about touch events on iOS:

  • Only one event for each mouse event type is dispatched.
  • Mouse events are dispatched approximately 300+ milliseconds after the user lifts his finger.
  • Mouse events are not dispatched if the touch results in the screen scrolling. Scroll events are also not dispatched until after the user lifts their finger.
  • Mouse events are not dispatched if the user initially touches the screen with more than one finger.
  • Touch events are not dispatched to textfields and textareas. Only mouse events are dispatched.

Ok, so getting back to the larger picture, vendors with touch-based devices and WebKit-based browsers have decided to adopt Safari’s touch events. The problem is now each vendor has to implement the event code to drive the touch events. It was explained to me by a device vendor that every hardware device and OS has its own unique implementation and API for dispatching events and that this leads to some interesting differences in browser behavior and event implementations. After playing with several iOS, Android and BlackBerry devices, I have seen first hand that this is indeed true. Some examples off the top of my head include:

  • BlackBerry dispatches interleaved touch and mouse events real-time while Android and iOS dispatch single mouse events after the user lifts their finger.
  • Some devices dispatch scroll events in a somewhat real-time manor, while others only dispatch a single event after the user lifts their finger.
  • Android devices require preventDefault on touchstart to prevent screen scrolling, while other devices require a preventDefault on touchmove, but this causes form elements to break because you can no longer click on them.
  • iOS dispatches a touchend event when the screen scrolls, but some platforms just stop dispatching touch events while the screen scrolls.

Some of these differences are bugs, or temporary problems due to current implementation, but the fact remains that the devices with these problems may exist and be used for a long time since vendors decide if and when these devices can be updated with fixes. Hopefully things will get better as standards emerge.

Another complicating factor is that some devices have both a touch-screen and a nub/joystick/track-ball. For jQuery Mobile, we need to support both touch and mouse events within all our components. We can’t just rely on mouse events because they don’t provide the real-time feedback/response that is necessary to make things feel snappy when the user is touching the screen. But supporting both is a big headache because it complicates event handling. For example, we need to set up a component to listen for both touch and mouse events, but then we need to disable mouse event handlers if touch events are used so that handlers/actions are only triggered once. We then need to re-enable the mouse handlers when the touch events are all done, but sometimes “done” is hard to figure out due to the fact that sometimes touch events just stop coming because the screen just scrolled.

Over the next few weeks we’ll be blogging about some of the ways we are dealing with these challenges while trying to reduce the event code complexity for jQuery Mobile components and implementing features like faux momentum scrolling. Stay tuned!