, the jQuery Mobile Team announced the official release of jQuery Mobile 1.0.
Having worked with jQuery Mobile since Alpha 1, in the time since, the framework has certainly evolved into a mature, premier platform on which Mobile Web Applications can be built.
On a personal note, as I am currently in the process of working towards the release of a multi form-factor Mobile Web Application built on jQuery Mobile, the 1.0 release couldn’t have come at a better time.
In addition to the new Attribute Selectors, the CSS3 Selectors Module defines a new Combinator called the General sibling combinator, which is described below, succeeding a review of each CSS3 Combinator.
Combinators
Combinators provide a means for describing relationships between elements in order to “combine” them to form specific rules based on a simple syntax. There are four Combinators in CSS3, below is description and example of each:
Descendant combinator
The most familiar of all Combinators, the Descendant combinator allows for selecting any element f which is a descendant (child, grandchild, great-grandchild and so on) of an element e. The combinator syntax for a Descendant combinator is a single “white-space” character.
/* Matches all <h1> elements which are descendants of an <article> element */
article h1{ /* declarations */ }
Child combinators allow for selecting any element f which is a direct child of an element e. The combinator syntax for a Child combinator is a single “greater-than” (>) sign.
/* Matches each <section> element that is a direct child of an <article> element */
article > section { /* declarations */ }
The Adjacent sibling combinator is a Sibling combinator which allows for selecting an element f which is adjacent to an element e; that is, element f immediately follows element e in the document tree. The combinator syntax for an Adjacent sibling combinator is a single “plus” (+) sign.
/* Matches all <em> elements which are the next sibling of a <strong> element */
strong + em { /* declarations */ }
New in CSS3, the General sibling combinator is similar to the Adjacent sibling combinator in that it matches an element f which follows an element e in the document tree; however, whereas in the Adjacent sibling combinator element f must immediately follow element e, the General sibling combinator allows for selecting an element f which is preceded by an element e, but not necessarily immediately preceded by an element e. The combinator syntax for a General sibling combinator is a single “tilde” (~) sign.
/* Matches all <time> elements which are preceded by a <del> element */
del ~ time { /* declarations */ }
The power of CSS Selectors can not be understated; for, without them, there would be no simple means by which developers could target specific elements for styling in a manner abstracted from, or external to, the actual markup to which the styles will bind.
CSS2 introduced four Attribute Selectors; referred to as Attribute Presence and Value Selectors, which allow for course grained matching of specific elements based on their attributes and / or attribute values. These include the following:
e[attr]
Where e is an element and [attr] is an attribute of element e. For example, p[title] would match all p tags with a title, regardless of the value of the title.
/* Matches all <p> tags with a title and changes their background color to red with white text */
p[title]{
background-color: red;
color: white; }
e[attr=val]
Where e is an element and [attr=val] represent an attribute of element e which contains the exact value of val. For example, p[title="Example 1"] would match all p tags with a title which equals “Example 1″ exactly.
/* Matches all <p> tags with a title equal to "Example 1" and changes their background color to green and text color to white */
p[title="Example 1"]{
background-color: green;
color: white; }
e[attr~=val]
Where e is an element and [attr~=val] is an attribute of element e which has a value containing a whitespace-separated list of words, one of which equals val exactly. For example, p[title~="Example-1a"] would match all p tags with a title containing the word “Example-1a” in a list of whitespace delimited words.
/* Matches all <p> tags with a title containing the exact word to "Example-1a" and changes their background color to black and text color to red */
p[title~="Example-1a"]{
background-color: black;
color: red; }
e[attr|=val]
Where e is an element and [attr|=val] is an attribute of element e that has a value of val exactly, or begins with val immediately followed by a hyphen “-”. For example, p[title!="Example"] would match all p tags with a title containing the word “Example-”, followed by any other value, such as “Example-1″, “Example-A”, etc..
/* Matches all <p> tags with a title containing the word to "Example-" and changes their background color to blue and text color to white */
p[title|="Example"]{
background-color: blue;
color: white; }
In addition to the above Attribute Presence and Value Selectors, CSS3 expands on this by defining three additional Attribute Selectors; referred to as Substring Matching Attribute Selectors. These additions allow for fine grained matching of specific elements based on their attribute values.
In simplest terms, the new Attribute Selectors in CSS3 can be used to match an element with a given attribute whose value begins, ends or contains a certain value. The following is a basic description and example of each new Attribute Selector:
e[attr^=val]
Where e is an element and [attr^=val] is an attribute of element e which contains a value that begins with val.
/* Matches all linked resources sent over https */
a[href^="https"]{
color: red; }
e[attr$=val]
Where e is an element and [attr$=val] represent an attribute of element e which contains a value that ends with val.
/* Matches all anchor tags to .html documents */
a[href$=".html"]{
color: green; }
e[attr*=val]
Where e is an element and [attr*=val] is an attribute of element e which has a value that contains val.
/* Matches all anchor tags which contain a query string */
a[href*="?"]{
color: blue; }
To summarize, there are a total of seven Attribute Selectors in CSS3, three of which are new. Whether used for general matches, such as global Attributes; e.g. *[hreflang|=en] or more specific matches, such as chaining; e.g, a[href^="https"][target="_blank"], Attribute Selectors provide a powerful mechanism for selecting both general and specific content within a page.
With both the CSS3 Selectors and CSS3 Namespaces Modules, respectively, having been released as official W3C recommendations (Selectors, Namespaces), I felt compelled to re-review each specification.
Interestingly, while reviewing the CSS3 Selectors Module (my personal favorite), I noticed that the selection pseudo-element selector which was originally drafted for CSS3 had been dropped from the proposal. In fact, it was dropped a rather long time ago.
In case you are not familiar with the selection pseudo-element, essentially it allows for defining the text color and background-color of selected text within a document.
For example, all <code> elements on my site have a red background with white text when selected – such as this text here (select it) – based on the following two simple rules:
And so, while having been dropped, support is already rather good (FF3.6, SA3.1+, OP9.5+, CH2+, IE9) and as far as I am aware Browser vendors will continue to support ::selection.
For the past year I have been using jQuery Mobile for developing web based mobile applications leveraging HTML5, CSS3 and JavaScript. Like all UI implementations, meaningful test coverage is essential to ensuring requirements have been met and refactoring can be achieved with confidence. Building applications for the Mobile Web is no different in this respect. And so, a high quality Unit Testing framework is as essential to the success of Mobile Web Applications as it is to their Desktop counterparts.
The power of QUnit lies in it’s simple and a rather unique approach to Test Driven Development in JavaScript. The QUnit API introduces a few slightly different test implementation concepts when compared to the more traditional xUnit style of TDD. In doing so, QUnit succeeds in simplifying some of the tedium of writing tests by leveraging the language features of JavaScript as opposed to strictly adhering to the more traditional xUnit conventions, the design of which is based on an fundamentally different language idiom – that is, Java.
For example, consider the follow which tests for a custom data namespace attribute in jQuery Mobile:
test("Test expected namespace override", function(){ var expected = "someNamespace-"; var actual = $.mobile.ns;
equal(actual, expected, "expecting namespace to have been set."); });
The above test may appear quite straightforward, yet it serves as a good example by illustrating how each test in QUnit is implemented by the QUnit test fixture. The first argument is simply a String which describes the test case. This is quite convenient in that the intent of a particular test case can be expressed more naturally in textual form as opposed to using a long, descriptive test method name. The Second argument contains the actual test implementation itself, which is defined as an anonymous function and passed as an argument to QUnit.test.
As you may have also noticed from the above example, there are some, perhaps subtle, differences between the QUnit style of testing and the traditional xUnit style. Specifically, whereas in xUnit assertions expected values are specified first and preceded by actuals, in QUnit actuals are specified first followed by expected values. This may feel a bit odd at first however, after a few tests it’s easy to get used to. Additionally, where an assertion message is specified before any arguments in xUnit, in QUnit assertion messages are specified after all arguments. With regard to test descriptions, this is a difference I prefer as, a test message is always optional so passing this value last make sense. While somewhat subtle differences, these are worth noting.
A Complete Example
As code can typically convey much more information than any lengthy article could ever hope to achieve, I have provided a simple, yet complete, example which demonstrates a basic qUnit test implementation. (run) (source).
“If everyone is moving forward together, then success takes care of itself.” – Henry Ford
The HTML5 Family has been receiving considerable coverage lately; and, rightfully so, as, many next generation browsers – specifically those in the Mobile space based on WebKit: Android, iPhone, iPad, Blackberry etc. are now beginning to implement it’s specification, or parts thereof. On the Desktop more HTML5 support is also being seen in the latest versions of Chrome, Firefox, Safari, IE9 and Opera.
The HTML5 Family of technologies will without question play a vital role in the future of the web; and currently, in the mobile Web space, that future is now.
A Brief Overview of the HTML5 Family
For anyone who is unfamiliar with what has been termed “The HTML5 Family“, allow me to provide succinct overview of the technologies which I feel encompass what has already become a rather overloaded term. In general, on a very high level, I would summarize the HTML5 Family simply as follows:
HTML5
CSS3
JavaScript
While the above could be considered the umbrella Technologies upon which The HTML5 Family is based, there are certainly more associated technologies which themselves further augment what could be considered the HTML5 Family, some of which are (based on current specification status at the time of this writing ):
Microdata
Geolocation API
Device APIs
Web Storage (localStorage, sessionStorage) APIs
Web SQL Database API
Web Workers API
Web Sockets API
HTML5
First, HTML5. HTML5 is the next major revision of HTML which aims to advance the open Web through web standards and semantically rich content. HTML5 defines an emphasis on semantic structure and meaning.
In general, HTML5 provides a content model which can be broadly defined into the following categories: Metadata content, Flow content, Sectioning content, Heading content, Phrasing content, Embedded content and Interactive content as well as form-associated elements etc.. HTML5 defines new tags such as canvas, audio, video, keygen, header, footer, nav, article, aside, datalist and more.
Explaining what JavaScript is may seem like a moot point as it is the language of the browser and therefore, the language of the web. However, it is important to outline some key underlying specifics of the language. In particular, JavaScript is a dynamic, prototypal, object-oriented scripting language. Its prototypal nature is quite different from the classical concepts of traditional object oriented languages. In order to get the most out of the language one needs to understand and embrace prototypalism and dynamism. Many of JavaScript’s true potential can be mistakenly overshadowed by it’s assumed design flaws; however, this needn’t be the case. As long as one understands the fundamental concepts of the language, it’s true potential can be realized to enrich development and allow for a level of expressiveness unmatched in type-safe languages.
Microdata
HTML5 Microdata provides a mechanism which allows machine-readable data to be embedded in HTML documents in the form of annotations, with an unambiguous parsing model. Microdata is compatible with numerous data formats such as JSON. Micro-data is intended to provide a standard to replace other similar concepts such as RDFa, from which browsers and other applications can discover relevant content based on the context of an applications markup. Such examples include markup for contact information, calendar events and more. This markup is understood by HTML5 compatible browsers which can then automatically offer to add the relevant content to the appropriate application. At an implementation level, microdata simply consists of a group of name-value pairs; with the groups being called items, and each name-value pair is a property.
Geolocation API
The HTML5 Geolocation API is rather straightforward; it simply provides a means by which the location of a device can be determined via a native API (as opposed to say, determining the clients IP address). The Geolocation spec is currently in last call status in the W3C.
Device APIs
Device APIs are client-side APIs which allow for direct interaction with native device services such as a device Camera, Calendar, Contacts etc.
Web Storage API
The Web Storage API allows for the persistence of local (permanent) and session based (browser session) data on the client. The API for Web Storage is extremely simple as it is based upon simple Key / Value pairs; with which Keys are simply Strings. Each site contains its own separate storage area.
Web SQL Database
While not a part of the actual HTML5 specification, the Web SQL Database presents some extremely interesting possibilities within Web Applications. The Web SQL Database provides a set of APIs which allow for the manipulation of client-side databases using SQL. The Web SQL Database is based upon SQLite (3.1.19) thus supporting the features as specified therein.
Web Workers API
Web Workers provide a mechanism by which web content can execute scripts in background threads. Web Workers allow for a much needed multi-threaded implementation for web based applications executing in a browser. While somewhat similar, Web Workers are different from threads in that they are primarily intended for executing long running, expensive computations and algorithms so as to facilitate non-blocking UI background processes. One specific aspect of Web Workers which has considerable positive implications for the web moving forward is that they run in native threads as opposed to Green Threads; as is the case in VM architectures. This is quite significant as it essentially means Web Workers can scale vertically. Considering the inevitable proliferation of multi-core desktop and mobile devices, this is certainly something that will prove advantageous.
Web Sockets API
Web Sockets provide native, full-duplex communications channels which operate over a single socket that enables HTML5 compliant browsers to use the WebSocket protocol (exposed via a JavaScript API) for two-way communication with a remote host.
If you are interested in learning more about each of these technologies I recommend the following resources:
Moving forward, I plan to go into further detail for each of these associated HTML5 Family technologies, providing working examples and detailed information as to how each can be utilized to create some very unique and interesting possibilities on the Web.