The jQuery UI custom select widget is designed as a method for applying a custom design to a native HTML select element. Currently the only applicable method for doing this to replace the select element entirely, duplicate it’s functionality in a new element and replicate any changes to the new element back to the select element.

Scott while at Filament group developed such a method in 2009 creating a selectmenu, this has received on going support from Felix Nagel.

During 2011 a project was developed at LBi London that required a large number of custom selects. Applying the current custom select had significant performance issues as every select had their options implemented at DOM ready. We sort an alternative pattern for generating custom selects and looked to the flyweight pattern. Ray Brooks implemented this pattern as a jQuery plugin.

The custom select widget is an implementation of the flyweight pattern referencing both Ray’s flyweight custom select and the current selectmenu widget.

On Sunday 30th October 2011 at 07:34 am i became the father to a baby boy. His name is Thomas Paterson and both mother and baby are doing great, although sleep patterns currently follow an ambiguous schedule only Thomas seems to be aware of.

It is only after my paternity leave that i find time to write this but now that life resumes it’s gentle ebb and flow i too return to development.

jQuery.each is designed to iterate over arrays and array like objects. .each is designed to iterate over jQuery objects and execute a function for each.

It seems to be a commonly held belief that a for or while loop should be used instead of the two jQuery alternatives. This belief is based on performance, as jQuery has to invoke additional code to complete the same task.

I tried a number of sources but the best way to find the truth is through experimentation. To create an experiment i use jsper.com as it allows you to run performance tests on snippets of your code, it is particularly useful as the same test can be run from many different browsers.

Having a quick look at jsper.com i found some existing tests, one of interest was Addy Osmani’s revision which had comparative results for for, while and jQuery.each loops. The .each test though seemed to be off by an order of magnitude. What’s missing here is that .each will look for the array of objects in the DOM, performing the same task as var a = $(‘*’).get() which is declared outside of the iteration for all the other test.

This represents an unfair advantage for the other methods, so i created a new revision of the test where the DOM operation was done as part of the test. From this .each is still slower than native methods but only by a small margin.

Using these results it would seem that the advantage of performance is insufficient to force usage of the for or while loop over the jQuery equivalents. Although there may be a saving in performance the jQuery abstraction allows for shorter, more succinct code, using a standard format that is easier to understand.

Common abstractions are useful in software development, if using jQuery i would recommend using jQuery.each and .each rather than a native approach; which should be kept in reserve for applications that require maximum performance.

Release 1.1.1 is now available on GitHub. This release includes a number of performance enhancements and fixes but retains the existing settings from the first release. Additionally i’ve created a number of public methods for the plugin, this will allow access to some of the internal features of the plugin.

Public methods

play:

Trigger a play/pause event on the chosen video background. Will play if the video is already paused. Will pause if the video is already playing.

mute:

Trigger a mute/unmute event on the chosen video background. Will unmute if the video is already muted. Will mute if the video is unmuted.

destroy:

Will destroy the chosen video background. Unbinds events bound when the video background is initialised and removes HTML attached to the DOM by the plugin. If a controlPosition parameter is set this will also have to be set to safely remove all HTML elements from the DOM.

resize:

When invoked this will resize the video background to the height of the document or window. The video background height affects the height of the document which affects the video background’s ability to negatively resize.

The demo page has been updated with the new code which when minified is 8Kb. You can find a shell file to minify the code in the build folder.

The source and issue tracking is available on GitHub.

Developing reusable code is a necessity of software development, it allows for a more efficient development cycle and continuous improvement of an existing development.

The alternative to code reuse is code salvage. Code salvage is an inefficient method of stripping the code down for it’s useful parts and discarding the rest. In creating modular code we hope to support code reuse by making all of the code module useful.

To create modular code we need to look at the key characteristics of a module. For that i am going to reference Bertrand Meyer’s ^{[1] [2]} five criteria for modular development from his book Object-Oriented Software Construction.^{[3] [4]}

• Modular Decomposability. A software construction method satisfies Modular Decomposability if it helps in the task of decomposing a software problem into a small number of less complex subproblems, connected by a simple structure, and independent enough to allow further work to proceed separately on each item.
• Modular Composability. A method satisfies Modular Composability if it favours the products of software elements which may then be freely combined with each other to produce new systems, possibly in an environment quite different from the one in which they were initially developed.
• Modular Understandability. A method favours Modular Understandability if it helps produce software which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others.
• Modular Continuity. A method satisfies Modular Continuity if, in the software architectures that it yields, a small change in the problem specification will trigger a change of just one module, or a small number of modules.
• Modular Protection. A method satisfied Modular Protection if it yields architectures in which the effect of an abnormal condition occurring at run time in a module will remain confined to that module, or at worst will only propagate to a few neighbouring modules.

The scale of modularity for each of the criteria may vary per module but by using these criteria to guide development of modules we should be able to create discrete, understandable and robust modules that can be used as building blocks for projects.

We can assess the affect of leveraging these principles by understanding two artefacts of code development, coupling and cohesion.

• Coupling. The reliance of the module on other modules and the module’s environment.
• Cohesion. A cohesive module makes sense as a discrete entity, it has a clearly defined role, purpose and it’s internal function is easy to understand.

Modular code should have low coupling and high cohesion. The lower the coupling, the less reliance the module has on external factors to function, this increases the chance that the module can be reused. Higher cohesion also increases the likelihood that a module can be reused, as it’s boundary is better defined making it easier to extract.

Summary

By using object oriented programming to create modular code we are trying to create code that we can reuse across projects. JavaScript libraries and the plugins they support are great examples of modular reusable code and in using these libraries we can focus on increasingly complex problems rather than reiterate the fundamentals like cross browser classname selection.

Nanos gigantium humeris insidentes ^[5] – By creating, sharing and using modular code we may all stand on the shoulders of giants.

References

1. http://se.ethz.ch/~meyer/. Retrieved 17/07/2011.
2. http://en.wikipedia.org/wiki/Bertrand_Meyer. Retrieved 17/07/2011.
3. http://www.amazon.co.uk/Object-Oriented-Software-Construction-Prentice-Hall-Resource/dp/0136291554/. Retrieved 17/07/2011.
4. http://en.wikipedia.org/wiki/Object-Oriented_Software_Construction. Retrieved 17/07/2011.
5. http://en.wikipedia.org/wiki/Standing_on_the_shoulders_of_giants. Retrieved 17/07/2011.

The site itself was built on EpiServer; which means .Net development and some of .Net’s more interesting aspects (web forms etc). What we produced is a HTML5 based site that is progressively enhanced using CSS and JavaScript. We couldn’t use all the elements HTML5 supports because we couldn’t be reliant on JavaScript for presentation in IE7 and 8. JavaScript development utilised jQuery and jQuery UI libraries.

This is only the first phase of ongoing development, with performance improvements including minification and new features for the site but an important first step in supporting one of the great yachting competitions.

There is a demo page available. I’ve used the existing site theme for the demo page which should adequately show the plugin is capable of being applied anywhere but lacks the impact a dedicated page design would provide.

The plugin should work in any browser that supports HTML5 video and although I’ve provided some styling in the demo page and in the source on GitHub, your actual page is likely to be bespoke so the CSS is only provided as an example.

The source and issue tracking is available on GitHub.

Update – 30th August 2011

A new version of the plugin has been created including fixes and ideas from the comments here and issues on GitHub. Find out more at the blog post jQuery HTML5 video background 1.1.1

As JavaScript development has matured Object Oriented programming has become the main programming paradigm, it is a paradigm shared with Java, C++ and many other languages. JavaScript is an object based language, lacking some of the traditional features of an Object Oriented language, it is a highly expressive language with alternative methods for classes, information hiding and inheritance^[1].

Developing Object Oriented JavaScript has a number of benefits for code quality and reuse. This article will focus on Object Oriented Programming’s four fundamental concepts, abstraction, encapsulation, inheritance and polymorphism^[7].

Abstraction

Only the possible states and behaviours of the abstracted object are accessible, the internal implementation of the object remains hidden. By abstracting the internal implementation of the object, we make the object’s purpose easier to understand^[4].

function Video(element, options) {
	this.Volume = function(number) {
		var loudness = element.volume;
		loudness = loudness + number;
		...
			element.volume = loudness;
		...
	}
}

When the Volume method is invoked there are a number of possible states for the volume. We don’t need to know what these states are, only that by invoking the Volume method we are attempting to change the volume by a given value.

Encapsulation

The object is structured to be self-contained, everything the object needs is available internally. The internal state of the object is not directly accessible externally except through the abstraction layer^[5].

function Video(element, options) {
	this.Volume = function(number) {
		var loudness = element.volume;
		loudness = loudness + number;
		...
			element.volume = loudness;
		...
	}
}

When Volume is given a value, what we need to alter the volume of the video element is available internally. We cannot alter loudness except through the Volume abstraction.

Inheritance

Through inheritance, one object can inherit the characteristics of another object, this allows an existing object to be extended and similar objects to share properties and behaviours^[6].

function Video(element, options) {
	this.Play = function() {
		...
	}
}
function Audio(element, options) {
	...
}
Audio.prototype = new Video();
var audio = new Audio();
audio.Play();

Using prototype, Audio inherits the properties of Video allowing the audio instance to use Video’s Play method.

Polymorphism

Different objects can respond to the same name in different ways, with the response specific to the object^[7].

function Video(element, options) {
	this.Play = function() {
		...
	}
}
function Audio(element, options) {
	this.Play = function() {
		...
	}
}
Audio.prototype = new Video();
var audio = new Audio();
audio.Play();

Audio inherits a Play method from Video but we may want to alter the Play functionality for Audio. We can overload the Play method with a new Audio Play method.

Summary

Abstraction, encapsulation, inheritance and polymorphism are the building blocks of Object Oriented Programming. Abstraction and encapsulation share a similar conceptual space while inheritance and polymorphism are also linked, by understanding how these concepts work we can better structure our solutions to large programming problems.

Understanding these terms alone though does not necessarily lead to better code quality or reuse. In the next article i’ll look at Bertrand Meyer’s five criteria for modularity from his book Object Oriented Software Construction and how these criteria can guide development practice in creating modular, reusable code.

References

1. http://javascript.crockford.com/javascript.html. Retrieved 29/05/2011.
2. http://en.wikipedia.org/wiki/List_of_multi-paradigm_programming_languages. Retrieved 29/05/2011.
3. http://javascript.crockford.com/popular.html. Retrieved 29/05/2011.
4. http://en.wikipedia.org/wiki/Abstraction_(computer_science). Retrieved 31/05/2011.
5. http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming). Retrieved 31/05/2011.
6. http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming). Retrieved 31/05/2011.
7. http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming). Retrieved 31/05/2011.

The increasing maturity of the browser market means the CSS has simplified to using min-height only. There are alternative solutions for min-height support using JavaScript, alternatively should the CSS fail it should not cause a significant issue to site usability.

The Objective:

Position the footer element so that it is at the bottom or below the viewport irrespective of the content.

The Solution:

The footer element will be positioned in the padded area of the previous sibling element using negative margin.

To achieve this the parent elements (html, body, #page) must be set to 100% height. The previous sibling element (#page-group) must be set to a min-height of 100% and then given a padding equal to the size of the footer element (#footer) plus any additional padding needed for the design.

This will push the vertical space of those elements beyond the viewport to the amount of padding applied. Use a negative margin to bring the footer element back within the viewport, unless the total content is greater than the viewport to start with.

The CSS:

html,
body,
#page {
  height: 100%;
}
#page-group {
  min-height: 100%;
}
#content {
  padding: 0 0 50px;
}
#footer {
  margin: -50px 0 0;
}

The HTML:

<!DOCTYPE html>
<html lang="en-GB" dir="ltr">
  <head>

  </head>
  <body>
    <div id="page">
      <div id="page-group">
        <header id="header" role="banner">

        </header>
        <div id="content">
          <div id="main" role="main">

          </div>
          <aside id="aside" role="complementary">

          </aside>
        </div>
      </div>
      <footer id="footer" role="contentinfo">

      </footer>
    </div>
  </body>
</html>

I didn’t give a specific example at the time because the one i offer now is rather contentious and i didn’t want it to draw away from the understanding of cargo cult development.

CSS resets, as investigated by Eric Meyer and others, is a style sheet used by a developer to set a cross browser baseline style. It removes any styling that may be applied by the browser rendering the elements in to a controlled initial state. The principle is that the developer is now in full control of styling for all elements on the site.

The principle is good, the developer should be in complete control of their styles. The application is flawed, while a developer may attempt to develop for all possible circumstances, the developer is not omniscient. New content and therefore new element combinations will be developed as the site matures, these element combinations will be unplanned by the developer.

By forcing all elements to effectively be unstyled, in a situation unplanned by the developer, the new element combinations will be raised as a developer failure because the reset style sheet declares the developer as omniscient when quite obviously they are not.

By taking CSS reset style sheets verbatim and applying them to our sites without fully considering what the reset is doing and it’s effect, we have engaged in cargo cult development.

Instead we should try to understand the principles reset style sheets espouse and integrate that into our own development methods. That way we can still pretend to be omniscient to our clients.