jQuery UI: Sortable 3D CSS

The jQuery UI sortable widget allows the user to pick an item up, and drop it in another location. It's kinda like the draggable widget and in fact, uses the draggable widget to implement the draggable behaviour. A key difference, however, is that sortable will shuffle the other items around as the item is dragged, and after it's dropped. It re-sorts the items. The only style changes applied to the item that's being moved is it's position. We can use some fancy 3D CSS to make the item stand out even more when it's being dragged.

Transition Support For Radio Buttons

The buttonset widget — a cousin of the button widget — is handy for working with groups of form controls. Not because any new functionality, because it isn't. It's more to do with themes and and they're applied to the elements. For example, the button widget doesn't add any capabilities not already present in native HTML buttons. It's all about consistent look and feel. The buttonset widget will take a group of radio buttons and make them appear as a single unified control. We can toggle the state of any given radio, and the appropriate states from the theme framework are applied. Why not add support for smooth transitions between these states?

Themes Have Changed

Themes offer a look and feel that can enhance the appearance of a web application. Web application frameworks usually provide a framework for building themes along with a few pre-built themes. Themes in web applications have two components to them; the HTML markup for the structure of the page and CSS styles that actually change the look and feel. Wait a second, if the CSS styles are responsible for changing the look and feel, what does the HTML markup have to do with the theme? Conceptually, it has nothing to do with the theme if it is strictly defined as the look and feel. This isn't the case with traditional themes most of the time. With some themes, not only are the look and feel different, but the entire layout is vastly different.

Lets assume that a theme is strictly look and feel. That is, we can change the look and feel of the entire application simply by changing the CSS stylesheet. These stylesheets don't typically contain layout definitions, just colors, fonts, etc. So has this idea been adopted by many frameworks if any?

jQueryUI is a really good example of themes in practice. The CSS framework offered by jQueryUI is strictly a look and feel framework. There aren't any layout restrictions imposed by the CSS definitions. The jQueryUI CSS framework exists for the purpose of adding theme capabilities to the widgets in the jQueryUI library. The framework is flexible enough to be useful with HTML elements that fall outside of the widget set.

CSS classes inside the jQueryUI famework dictate the look and feel of the user interface. There really aren't any restrictions on what elements these classes can be applied to. If you have a container HTML element with several jQueryUI widget descendants, the widgets will have a distinct look and feel while the container element does not. It turns out that the container element can in fact share the same theme as the widgets by giving it an appropriate class from the CSS framework.

By eliminating structural layout requirements from the theme, you add a new level of flexibility. Javascript widgets actually look like they belong in the application. Also, by basing themes entirely on CSS styles, we make creating new themes much easier as well because the classes are standardized and there are no layout surprises. jQueryUI has proven to be very powerful theme-driven user interface framework and it looks as though it will continue to improve into the future as the widget set is expanded.

jQueryUI Hovering

The jQueryUI user interface library offers developers building interactive web applications not only a set of widgets to use, but also, a set of effects. An effect, in this context, can be thought of as a transition from one state to another by a user interface component. As an example, imagine you have a button element that is in a hidden state. Showing that button would be considered an effect, albeit, a very basic one. A jQueryUI effect adds some appeal to these transitions. In essence, jQueryUI effects can be thought of as user interface component state transitions that enhance the overall user experience.

Another nice feature in the jQueryUI repertoire is the CSS framework used for changing the look and feel of the widget set. This framework allows developers to choose an existing theme or to build their own. CSS classes within the framework are flexible enough that they aren't restricted to the jQueryUI widgets. Your user interface isn't going to be composed entirely of widgets. You can use these CSS classes to help give the non-widget elements of your application more of a theme.

An example use of applying the jQueryUI CSS framework to a non-widget element would be using the ui-state-hover class. Lets say we have a list of li elements. The idea is to add the ui-state-hover CSS class to each li element when the user hovers over it. This is fairly straightforward to do with the jQuery addClass() and removeClass() methods. You call these methods inside a hover in and a hover out callback respectively. Example callback functions are shown below.

function hoverin(element){
 jQuery(element).addClass("ui-state-hover");
}

function hoverout(element){
 jQuery(element).removeClass("ui-state-hover");
}

jQueryUI allows us to add an interaction to the addClass() and removeClass() methods. Typically, we would only want to add an effect to the addClass() for hover in events. Otherwise, the user interface tends to look too busy. Here is the same example modified to introduce an effect when adding the class. The the visual changes made to the element as a result of adding the class will take place over a duration of 150 milliseconds rather than instantaneously.

function hoverin(element){
  jQuery(element).addClass("ui-state-hover", 150);
}

function hoverout(element){
  jQuery(element).removeClass("ui-state-hover");
}

There is, however, one problem with this approach. There is a chance that the ui-state-hover class will not be removed from the element by hoverout(). This is because the user can, and most definitely will at some point, hover out of the element during the 150 millisecond effect duration. Keep in mind, the element doesn't actually have the ui-state-hover class until the 150 millisecond effect duration is up. When hoverout() is called during the effect, no class is removed because it hasn't been added yet. Below is a work-around for this issue that involves using a secondary state class.

function hoverin(element){
   jQuery(element).addClass("app-state-hover");
   jQuery(element).addClass("ui-state-hover", 150, function(){
       if(!jQuery(element).hasClass("app-state-hover")){
           jQuery(element).removeClass("ui-state-hover");
       }
       jQuery(query).removeClass("app-state-hover");
   });
}

function hoverout(element){
   jQuery(element).removeClass("ui-state-hover app-state-hover");
}

Here we introduce a new class called app-hover-state. This class will be used to track the hover state of the element since we are now using an effect. The hoverin() function will now add this class to the element before starting the visual effect. The hoverout() function will now remove both the ui-state-hover and the app-state-hover classes. This is important because even if the effect hasn't yet finished when the user hovers out of the element, the app-state-hover class will be removed from the element. The visual effect in hoverin() now has a callback function that is executed when the duration of the effect has completed. This callback will remove the ui-state-hover class if the app-state-hover class has been removed. In this case, if app-state-hover has been removed can only mean one thing; a hoverout() call was made during the duration of the effect and the ui-state-hover class should also be removed.

jQuery CSS

The user interfaces of web applications these days are filled to the brim with rich user interactions that were confined only to desktop applications no long ago. This high level of user interactivity is made possible by javascript toolkits such as jQuery. The features seen in nice web application user interfaces are possible using javascript without a toolkit, but this is a bad programming practice. In this case all the developer is doing is simply re-inventing the wheel.

These javascript toolkits allow for easy manipulation of the DOM tree. This means that elements of the page can be added, removed, or manipulated in controlled ways based on the user input. Without this ability, the user generally needs to wait for a response from the server which really takes away from the responsiveness of the GUI.

Aside from adding and removing page elements in response to user actions, page elements can change form in response to user actions. jQuery has the ability to add in-line styles to page elements. This is a useful feature for altering the appearance of page elements. Again, this is bad programming practice. If using the in-line CSS style attribute in the HTML markup is bad practice, this is synonymous. It is generally a good idea to keep the styles of various elements in the CSS definitions rather than add them using the jQuery functionality. Rather than add a style attribute, add a CSS class with jQuery. This is a much cleaner approach and makes the life of both the CSS designer and the javascript developer easier.

jQuery Context

How many times have you wished there was an easier way to find DOM elements in a given HTML document? The jQuery javascript toolkit offers a powerful set of CSS selectors that enable developers to do just that; easily query DOM elements. The heart of the jQuery toolkit relies on these selectors. If you are using jQuery in your javascript applications to manipulate the DOM tree, you probably haven't noticed any performance issues while issuing queries. This is because jQuery is highly optimized.

However, the performance can still be improved. The jQuery() function is most often used to query the entire DOM tree. That is, if you issue a query for a DOM id, the selector is applied to every element in the document. More often than not, there is an opportunity to specify a context. For instance, when issuing a query, the developer may know that the given id exists somewhere within another element. Luckily, this element can be specified as a query context when issuing the query.

The benefit to using the context parameter is that the search for the specified DOM elements is narrowed. Possibly by a significant margin. There is another benefit to using the context parameter. Maintainability. Developers can easily deduce why a given query isn't yielding expected results for instance. Finally, the context can be used pragmatically to affect behavior. Below is an example of how to apply the context parameter to DOM queries using the core jQuery() function.

//Example; jQuery context.

var my_div=jQuery("#my_div");
var my_elements=jQuery(".my_elements", my_div);