You are viewing the Articles published in

CSS3 Combinators

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

November 13, 2011 Browsers / CSS3 / HTML5 / JavaScript
Comments Off on CSS3 Combinators

CSS3 Attribute Selectors

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.

November 10, 2011 Browsers / CSS3 / HTML5 / JavaScript
Comments Off on CSS3 Attribute Selectors

CSS3 selection pseudo-element (dropped)

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.

November 2, 2011 CSS3 / HTML5
1 Comment

HTML5 Structural Elements

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:

October 19, 2011 HTML5 / UX Design
2 Comments

Circumventing Conditional Comparisons

Often during the course of my day I come across code which evaluates the same conditional comparisons in multiple contexts. Understandably, this is rather typical of most software systems, and while it may only introduce a negligible amount of technical dept (in the form of redundancy) for smaller systems, that dept can grow considerably in more complex, large scale applications. From a design perspective, this issue is applicable to nearly every language.

For example, consider a simple Compass class which defines just one public property, “direction” and, four constants representing each cardinal direction: North, East, South and West, respectively. In JavaScript, this could be defined simply as follows:

Technically, there is nothing problematic with the above class signature; the defined constants certainly provide a much better design than conditional comparisons against literal strings throughout implementation code. That being said, this design does lead to redundancy as every instance of Compass which needs to evaluate the state of direction requires conditional comparisons.

For example, to test for Compass.North, typically, client code must be implemented as follows:

Likewise, simular comparisons would need to be implemented for each cardinal direction. And, while this may seem trivial for a class as simple as the Compass example, it does become a maintenance issue for more complex implementations.

With this in mind, we can simplify client code by defining each state as a specific method of Compass. In doing so, we afford our code the benefit of exercising (unit testing) Compass exclusively. This alone improves maintainability while also simplifying client code which depends on Compass. As such, Compass could be refactored to:

Based on the above implementation of Compass, the previous conditional comparison can be refactored as follows:

Comparator API

To simplify implementing conditional comparisons, I have provided a simple Comparator API that defines a single static method: Comparator.each, which allows for augmenting existing objects with comparison methods. Comparator.each can be invoked with three arguments as follows:

type

The Class to which the comparison methods are to be added.
property
The property against which the comparisons are to be made. If the property has not been defined it, too, will be added.
values
An Array of constants where each value will be used to create a new comparison method (prefixed with “is”). If the constants specified are Strings, typically an Array containing each constant should suffice. For example, passing [Foo.BAR] where BAR equals “Bar” would result in an isBar() method being created. To specify custom comparison method names, an Object of name/value pairs can be used where each name defines the name of the method added and the value is the constant evaluated by the method. This is useful for constants which are not strings. For example, {isIOS421: DeviceVersion.IOS_4_2_1} where IOS_4_2_1 equals 4.2.1 would result in an isIOS421() method being created.

Taking the Compass example, the previous comparison methods could be augmented without the need to explicitly define them via Comparator.each:

The above results in the comparison methods isNorth, isEast, isSouth and isWest being added to the Compass type.

Comparator: source | min | test (run)

October 14, 2011 APIs / Code Review / Design Patterns / JavaScript / Object Oriented Design / Refactoring / Software Engineering / TDD / BDD
Comments Off on Circumventing Conditional Comparisons

Interconnectivity in JavaScript with Peerbind

The ability to facilitate interconnectivity between multiple clients has always presented some rather interesting possibilities for both simple and complex Web Applications alike. More often than not, such interconnected applications would require complex server-side configurations (often proprietary in nature) in addition to numerous infrastructure considerations.

Peerbind, a new JavaScript API, remedies many of these complications by providing a very simple client-side API built on jQuery.

Peerbind is quite unique in that it provides an event binding API (on top of jQuery) that is shared amongst all connected clients of the same interest. Essentially this allows for binding something as common as a “click” event (or any event for that matter, including custom events) such that each active instance of the same application across the web will be notified of the event. As one might imagine, this allows for some rather compelling possibilities.

To demonstrate just how quickly and easily interconnectivity can be plugged into a web application using Peerbind (and the Peerbind public server), below is a simple example which displays a new item each time a new “peer” views the example page since loaded (hint: try opening a few instances, either in tabs or separate browsers).

Example (run)

Simple enough!

Of course, for most applications there are obvious security concerns which would need to be addressed as well as issues of scale and availability to take into consideration. That being said, if you haven’t checked out Peerbind yet and would like to quickly and easily add interconnectivity to your application or leverage it’s simplicity to prototype such features, it is certainly worth taking for a test drive.

October 6, 2011 Browsers / HTML5 / JavaScript
Comments Off on Interconnectivity in JavaScript with Peerbind
← Older Articles
Newer Articles →