You are currently browsing the Eric Feminella posts tagged: html5

CSS3 Combinators

Sunday, November 13th, 2011

In my previous article on CSS3 Selectors, I discussed the two Attribute Selector classifications; Attribute Presence and Value Selectors, and, Attribute Substring Matching Selectors.

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.

8.1. Descendant combinator
Child combinators
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.

8.2. Child combinator
Adjacent sibling combinator
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.

8.3.1. Adjacent sibling combinator
General sibling combinator
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.

8.3.2. General sibling combinator

The following demonstrates a very basic example of each of the above Combinators:
View Example

CSS3 Attribute Selectors

Thursday, November 10th, 2011

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.

In addition to some of the more common Simple Selectors, such as Type Selectors, Class Selectors and Id Selectors, we have have Attribute Selectors, which, as the name implies, allow us to match elements based on their attributes.

Attribute Presence and Value Selectors

CSS2 introduced four Attribute Selectors; referred to as Attribute Presence and Value Selectors, which allow for coarse 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.
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.
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.
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..

View Example

Substring Matching Attribute Selectors

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.
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.
e[attr*=val]
Where e is an element and [attr*=val] is an attribute of element e which has a value that contains val.

View Example

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.

HTML5 Structural Elements

Wednesday, October 19th, 2011

The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation.
Tim Berners-Lee

The HTML5 Specification introduces many new semantic elements intended to provide meaning to the structure of a document. These elements are quite important as they allow for marking up a document in meaningful ways which, prior to HTML5, would have otherwise required a rather ambiguous markup consisting primarily of divs, ids, and classes to provide some semblance of semantic structure.

Being purely markup based, it is understandable why these new semantic elements may not excite as much interest as many of the more attention grabbing HTML5 specifications, such as audio, video, Web Workers, WebSockets, Web Storage etc. However, it is important, perhaps even necessary, to emphasize the significance these new elements present in terms of helping to solidify the realization of what the web is intended to be: an open medium for disseminating homogeneous and heterogeneous information.

With this in mind, combined with an informed understanding of the context in which each new semantic element can be applied, overtime the Web will, quite naturally so, evolve in many new, exciting, and perhaps previously unthought-of ways.

Broadly, the new Structural elements introduced in HTML5 can be succinctly summarized as follows:

The <header> Element
The <header> element is rather self explanatory in that it allows for defining content which is to be denoted as a header of a page, or a header within a section of a page. Headers typically provide introductory and / or navigational content via hgroup and nav elements. What is important to keep in mind is that multiple <header> elements can be defined per page.

W3C Specification (section 4.4.8)
The <nav> Element
The <nav> element represents an important section of navigational links to specific pages or specific sections within the current page. As such, not all navigational links need be defined within a <nav>.

W3C Specification (section 4.4.3)
The <article> Element
The <article> element provides a means by which content can be represented independently from the document or application with which it is associated. General examples could include, as one may have guessed, an article from a newspaper, a blog post, a comment on a blog post, a self contained UI widget, and so forth.

W3C Specification (section 4.4.4)
The <section> Element
The <section> element defines generic sections of a document, article or entire application. The section element is intended to provide semantics for a document and is not intended to be used as a container for styling purposes, in which case a <div> element should be used.

W3C Specification (section 4.4.2)
The <aside> Element
The <aside> element represents content which is relevant to, or supportive of it’s surrounding content, but is not required to convey the information set forth by the surrounding content. General examples could include a pull quote, a blog roll, a sidebar etc.

W3C Specification (section 4.4.5)
The <footer> Element
As with the <header> element, the <footer> element is rather self explanatory in that it allows for defining content which is to be denoted as a footer of a page, or a footer within a section element for it’s nearest ancestor. A page can contain multiple <footer> elements, each unique to a particular section.

W3C Specification (section 4.4.9)

Putting it all Together

The following example is comprised of each semantic element described above to form a complete, valid HTML5 document:

Test Driven Javascript with QUnit

Monday, September 19th, 2011

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.

Why QUnit?

While there are quite a few good JavaScript Unit Testing Frameworks available, Jasmine in particular, I have found QUnit to best suit my particular needs for implementing Test Driven Development in JavaScript based on it’s clean design and practical implementation.

A Simple, Powerful API

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:

Figure 1 (run) (source)

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).

Tracking HTML5 Support in Chrome

Sunday, September 18th, 2011

Google has now made it easy to track the current implementation status of HTML5 in Chrome via The Chromium Projects’ new Web Platform Status page.

Many of the sections have links to their html5rocks site, which provide further details and more in-depth tutorials of implemented specifications.

The current sections include:

This is certainly something to keep an eye on as, Chrome is setting the standard in terms of HTML5 support by desktop browser vendors.

HTML5 Elements: The <base> Tag

Thursday, September 1st, 2011

The HTML5 Specification introduces many new semantic elements, as well as specifications for existing elements; one of which is the <base> Tag, which allows for specifying a root URL from which all linkable elements in a document (hyperlinks, images etc.) are based, as well as a default target for all linkable elements.

Overview

  • The <base> Tag provides two attributes; href (Hyper-text Reference) and target, respectively, which have the same semantic meaning as that of a hyperlink.
  • Only a single <base> Tag is to be defined per page and, must be defined before any elements which except a URL are defined (other than the html element).

Note: While the <base> Tag is not new to HTML5, the changes to the a Tag implies a difference (albeit, marginal) as, a Tags are always hyperlinks, or placeholders for hyperlinks.

Example

Like all HTML markup, usage of the <base> Tag is easy and straightforward: Simply add a single <base> Tag in the <head> element of the document and define either a base URL and / or default target attribute.

Defining a default base URL and target:

The above links will all default to a blank target (new page), with each link’s base URL defaulting to “http://somedomain/app”. Individual links can override the base URL as well as the default target.

Support

The <base> Tag is currently supported by all major browsers.