You are currently browsing the HTML5 archives.

Natural Box Model Sizing

Saturday, April 6th, 2013

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.

Windows 8 Web App Start Screen Tiles

Friday, March 1st, 2013

Having had to certify a Web Application for use on the HTC Windows Phone 8X, as well as the Microsoft Surface Tablet, I was interested in providing a Start Screen Tile similar to that of the application’s current iOS Web Clip Icon. Not the least, the new Tile Based UI in Windows 8 presents significant UX improvements over that which has been seen in previous versions of Windows; thus, I felt compelled to take advantage of the new UI from a Web Application context.

Conveniently, adding a Windows 8 Start Screen Tile (Pinned Site) can be accomplished quite easily, and in much the same way as that which is used when specifying a Web Application to run in standalone-mode on iOS. To do so, one need only add additional meta elements with a name attribute of msapplication- followed by a specific Tile property. A standard content attribute can then be used to provide the corresponding attribute value.

For example, a Tile can be defined with a specific color using msapplication-TileColor:

Likewise, a specific Tile image can be provided using msapplication-TileImage:

Note: Tile images should be 144x144px, in .png format (transparent).

This site, for instance, utilizes both of the above:

While creating and defining a Start Screen Tile is simple enough, Microsoft also provides a handy Web based utility which allows for automating the Pinned Site creation process by generating a selected Tile Image in the correct dimensions, and providing the corresponding source at

Simplifying Designs with Parameter Objects

Tuesday, January 22nd, 2013

Recently, while reading the HTML5 Doctor interview with Ian Hickson, when asked what some of his regrets have been over the years, the one he mentions, rather comically so as being his “favorite mistake”, also happened to be the one which stood out to me most; that is, his disappointment with pushState; specifically, the fact that of the three arguments accepted, the second argument is now ignored.

I can empathize with his (Hixie’s) frustration here; not simply because he is one of the most influential figures on the web – particularly for his successful work surrounding CSS, HTML5, and his responsibilities at the WHATWG in general – but rather, it is quite understandable how such a seemingly insignificant design shortcoming would bother such an obviously talented individual, especially considering the fact that pushState's parameters simply could not be changed due to the feature being used prior to completion. Indeed, the Web Platform poses some very unique and challenging constraints under which one must design.

While the ignored pushState argument is a rather trivial issue, I found it to be of particular interest as I often employ Parameter Objects to avoid similar design issues.

Parameter Objects

The term “Parameter Object” is one I use rather loosely to describe any object that simply serves as a wrapper from which all arguments are provided to a function. In the context of JavaScript, object literals serve quite well in this capacity, even for simpler cases where a function would otherwise require only a few arguments of the same type.

Parameter Objects are quite similar to that of an “Options Argument” – a pattern commonly implemented by many JavaScript libraries to simplify providing optional arguments to a function; however, I tend to use the term Parameter Objects more broadly to describe a single object parameter from which all arguments are provided to a function, optional arguments included. The two terms are often used interchangeably to describe the same pattern. However, I specifically use the term Options Argument to describe a single object which is reserved exclusively for providing optional arguments only, and is always defined as the last parameter of a function, proceeding all required arguments.


Parameter Objects can prove beneficial in that they afford developers the ability to defer having to make any final design decisions with regard to what particular inputs are accepted by a function; thus, allowing an API to evolve gracefully over time.

For instance, using a Parameter Object, one can circumvent the general approach of implementing functions which define a fixed, specific order of parameters. As a result, should it be determined that any one particular parameter is no longer needed, API designers need not be concerned with requiring calling code to be refactored in order to allow for the removal of the parameter. Likewise, should any additional parameters need to be added, they can simply be defined as additional properties of the Parameter Object, irrespective of any particular ordering of previous parameters defined by the function.

As an example, consider a theoretical rotation function which defines five parameters:

Using a Parameter Object, we can refactor the above function to the following:

Should we wish to remove a parameter from the function, doing so simply requires making the appropriate changes at the API level without changing the actual signature of the function (assuming of course, there are no specific expectations already being made by calling code regarding the argument to be removed). Likewise, should additional parameters need to be added, such as a completion callback, etc., doing so, again, only requires making the appropriate API changes, and would not impact current calling code.

Additionally, taking these potential changes as an example, we can also see that with Parameter Objects, implementation specifics can be delegated to the API itself, rather than client code insofar that the provided arguments can be used to determine the actual behavior of the function. In this respect, Parameter Objects can also double as an Options Argument. For example, should the arguments required to perform a 3D rotation be omitted from the Parameter Object, the function can default to a 2D rotation based on the provided arguments, etc.


Parameter Objects are rather convenient in terms of there being less mental overhead required than that of a function which requires ordered arguments; this is especially true for cases where a function defines numerous parameters, or successive parameters of the same type.

Since code is generally read much more frequently than it is written, it can be easier to understand what is being passed to a function when reading explicit property names of an object, in which each property name maps to a parameter name, and each property value maps to parameter argument. This can aid in readability where it would otherwise require reading the rather ambiguous arguments passed to a function. For example:

With Parameter Objects it becomes more apparent as to which arguments correspond to each specific parameter:

As mentioned, if a function accepts multiple arguments of the same type, the likelihood that users of the API may accidentally pass them in an incorrect order increases. This can result in errors that are likely to fail silently, possibly leading to the application (or a portion thereof) becoming in an unpredictable state. With Parameter Objects, such unintentional errors are less likely to occur.


While Parameter Objects allow for implementing flexible parameter definitions, the arguments for which being provided by a single object, they are obviously not intended as a replacement for normal function parameters in that should a function need only require a few arguments, and the function’s parameters are unlikely to change, then using a Parameter Object in place of normal function parameters is not recommended. Also, perhaps one could make the argument that creating an additional object to store parameter/argument mappings where normal arguments would suffice adds additional or unnecessary overhead; however, considering how marginal the additional footprint would be, this point is rather moot as the benefits outweigh the cost.

A Look at pushState’s Parameters

Consider the parameters defined by pushState:

  1. data: Object
  2. title: String
  3. url: String

The second parameter, title, is the parameter of interest here as it is no longer used. Thus, calling push state requires passing either null or an empty String (recommended) as the second argument (i.e. title) before one can pass the third argument, url. For example:

Using a Parameter Object, pushState could have been, theoretically, implemented such that only a single argument was required:

  1. params: Object
    • data: Object
    • title: String
    • url: String

Thus, the ignored title argument could be safely removed from current calling code:

And simply ignored in previously implemented calls:

As can be seen, the difference between the two is quite simple: the specification for pushState accepts three arguments, whereas the theoretical Parameter Object implementation accepts a single object as an argument, which in turn provides the original arguments.

Concluding Thoughts

I certainly do not assume to understand the details surrounding pushState in enough detail to assert that the use of a Parameters Object would have addressed the issue. Thus, while this article may reference pushState as a basic example to illustrate how the use of a Parameter Object may have proved beneficial, it is really intended to highlight the value of using Parameter Objects from a general design perspective, by describing common use-cases in which they can prove useful. As such, Parameter Objects provide a valuable pattern worth considering when a function requires flexibility.

HTML5 Document Outliner

Sunday, October 21st, 2012

Recently, while preparing a training session on HTML5 Semantic and Structural Elements, I was rather intent on conveying the importance of an application’s overall markup and structure, while also expressing the importance of not being overly concerned with the absolute technical “correctness” of each and every element used.

With this in mind, providing a general overview of HTML5 sectioning content, and HTML5 Document Outlines, seemed appropriate points to emphasize.

Before doing so, I was looking to utilize a simple utility to provide a means of visualizing an HTML5 Document Outline, and the very useful Chrome Extension, HTML5 Outliner, proved to be an ideal tool for the task.

In particular, the HTML5 Outliner is quite helpful in validating the overall structure of single page web applications, whereby the constructed page is based on multiple disparate client-side templates being rendered at runtime; in which case it can be rather useful to have a holistic view of an application’s structure.

And so, if you are building modern client-side web applications, and using Chrome, if you haven’t done so already, I certainly recommend installing the HTML5 Document Outline for quickly viewing an application’s overall structure.

Managing Client-side Templates with RequireJS

Sunday, July 15th, 2012

When developing single page web applications, patterns of structure, organization and reuse become ever more important. This especially holds true when there is a need to maintain mulitiple web applications, each of which targeting a specific form factor, while also sharing many of the same underlying core APIs.

In the context of client-side templating, such patterns begin to emerge, quite naturally so, when leveraging RequireJS modules and the RequireJS text plugin.

Template Modules

One specific pattern I have found myself implementing is that of a single Templates Module which provides a centralized location from which all compiled templates within an application can be referenced. A rather simple pattern, Template Modules are only concerned with loading, compiling and providing a public API to access compiled templates; that is, a Templates Module simply requires all external templates, and provides named methods for retrieving the compiled template functions of each.

A basic implementation of a Templates module is as follows (while Handlebars may be used in this example, any template engine would suffice):

The main benefit of implementing a Templates Module is reuse, as different modules can use the same templates without a need for redundantly requiring and compiling the templates themselves. Additionally, Template Modules provide a convenient means of abstracting away the underlying template engine from client code, thus reducing the amount of refactoring needed should the template engine itself ever need to change.

When using the RequireJS Optimizer, each external template will be included in the optomized build and loaded synchronously, and so there is no additional overhead in terms of HTTP requests when requiring each template in a single location.

You can check out a basic example implementation of a Templates Module (in the context of Backbone) here.

JavaScript Comma Delimiter Pattern

Tuesday, June 5th, 2012

Perhaps the most common syntactic error I find myself correcting in JavaScript is that of a simple missing comma separator on new lines. Such marginal oversights can become quite a nuisance to correct time and time again. Fortunately, there is a rather simple pattern which can be used to help avoid these errors with very little effort – only requiring code to be rewritten in a manner that reads more naturally while also being syntactically correct.

Typical missing comma scenario

If we are to consider the most common scenario where a comma is unintentionally omitted (and a subsequent exception is thrown), it can most likely be found within The Single var Pattern (irrespective of any personal preference towards or against the pattern itself).

For example, consider a typical block of code implementing a single var:

The above example, being rather typical and admittedly simple, does not pose much of a maintenance issue itself. However, if one is to refactor these declarations into a different order, add additional declarations, or specify more complex assignments, the probability of a comma being omitted unintentionally or becoming out of place increases.

In addition to The Single var Pattern, object literals are also a good source of occasional commas being omitted unintentionally, especially when nested within additional literals:

A Simple Solution

To help avoid such mistakes altogether, we can simply place commas before declarations, rather than after. At first, this may feel a bit awkward, but in time it becomes quite easy to get used to.

With this in mind, by placing commas first, the above could easily be refactored to the following:

As can be seen in the above example, considering we generally read code left to right, it becomes immediately apparent if a comma is missing.

For instance, take note of which implementation is easier to notice the missing comma:

I suspect most would agree that commas placed before stand out much more, and therefore it becomes much more apparent when one is missing. This appears to be so as the difference between the two is such that with commas placed after one needs to look for what is missing, whereas with commas placed before one sees what is missing.

As humans, our tendency towards patterns in general, and visual patterns in particular can not be understated. As developers, considering patterns are a significant part of our work, we should strive to take advantage of the most natural ones especially, even for things as seemingly marginal as placing comma separators first.