css3 tagged Articles …

Natural Box Model Sizing

As Web Developers, the benefits to be afforded by simply taking the time to aquire a fundamental understanding of CSS layouts can not be overstated; for it is these very skills that provide the basis from which designs can be achieved with ease; making the task of designing the Web an enjoyable, and rewarding experience. Conversely, without an understanding of core concepts, one is certain to spend a significant amount of time – often in frustration – attempting to achieve a desired layout.

CSS Layout Fundamentals

In the context of CSS layouts, such fundamental concepts to be considered (in no particular order) include: document flow, positioning, display types, off-sets, floats, overflows, clears, and the like; and, as the title of this article suggests, the Box Model.

The Box Model

I emphasize the importance of the Box Model here in particular, as the default sizing of elements with respect to the Box Model is quite the opposite of what one might expect.

For example, consider the following:

As many would assume, any element with the .box class would render with a 1px border and 20px of padding, at exactly 200x200px. However, by default, this is not how elements are sized, but rather, the actual size of a rendered element is calculated to include both borders and padding in addition to width and height, the calculation for which essentially being:

This results in nearly all elements (form elements notwithstanding) being measured quite differently then one might have expected. Thus, in the example of the .box class mentioned above, rather than elements being rendered at the expected 200x200px, as defined by their respective width and height properties, they would instead be rendered at 242x242px.

.box content-box

One could argue that in the majority of cases, this is neither what is expected nor what is desired. Fortunately, CSS3 offers the very useful property box-sizing, which can be used to override the default sizing of elements (content-box), and allow for sizing them more naturally simply by setting box-sizing to border-box:

By setting box-sizing: border-box, elements with the .box class will render at the expected size, 200x200px, as defined by the width and height properties; with the content area being 158px, padding 40px, and border at 2px.

.box border-box

Box-sizing Global Resets

Paul Irish has a great solution for this very problem whereby a global reset is used to ensure all elements are sized with border-box. I highly recommend this approach as it provides a starting point from which all elements will be sized “naturally”. The reset is simple, safe, and works perfectly well in supported browser:

CSS3 background-clip and background-origin

The background-clip and background-origin properties, respectively, can both be used in tandem with box-sizing; each accepting the same values as that of box-sizing, allowing for related control of how backgrounds are displayed for elements with respect to the Box Model.

Concluding Thoughts

It was quite some time ago while trying to understand how the sizing of elements is determined in more detail that I first learned of the box-sizing property. In the time since, I have been using box-sizing:border-box with great results and have really come to appreciate this property.

And so, if you haven’t leveraged box-sizing: border-box in your designs yet, I strongly recommend giving it a try, as you will likely find it to result in more “naturally” sized elements.

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

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.

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.

Test Driven Javascript with QUnit

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