Abstract Away the Performance Faults of querySelectorAll

With the introduction of the Selectors API in HTML5, developers finally got a native means to selecting specific nodes without the need to traverse the DOM in tedious loops. The two new methods, querySelector and querySelectorAll, facilitate this functionality by querying the DOM via CSS selector strings. However, these new methods lack the performance of their closely related functions: getElementById, getElementsByTagName, and getElementsByClassName. This paired with the fact that effective CSS design should translate into an abundance of simple selectors that could be leveraged by one of these functions, and the unnecessary performance loss becomes much more apparent. For this article, I will be discussing the performance considerations for querying the DOM and interacting with the results, and offer a simple abstraction for an all-encompassing solution.

Project Agnostic CSS Declaration Blocks

Low specificity is key to good fundamental CSS design. Avoiding overly specific selectors and grouping similar characteristics helps to modularize your stylesheets resulting in greater portability and reusability of declaration blocks. This serves as an effective means to decoupling your CSS from your HTML. For this article, I will be focusing on some useful project agnostic declaration blocks, many of which form the basis of my CSS boilerplate given the ease in which they can be applied to any project without being too specific to any one project.

Maintain Responsiveness by Capturing Unbound Action Events

Responsiveness is critical for modern client-side applications. When a user clicks on something, they expect a result and some are not too keen on waiting. At the very least, a user’s actions should be acknowledged via a loading indicator or the like. The absolute worse case scenario is having nothing happen at all. This is often the case pre-initialization. The user interacts with a component without any effect or even error message because, unbeknownst to the user, the page is still in the process of initialization and event handlers had yet to be bound to their correlative elements. It’s an issue I have encountered on numerous occasions. A less technically inclined user may assume the site is broken, that makes for a bad first impression. For this article, I will be exploring a solution to this problem by way of capturing user triggered action events pre-initialization to maintain responsiveness.

The State of Browser Detection

Despite the progress client-side scripting has made in the last decade or so, it seems some bad practices are poised to never die. With the medium transitioning into a more mobile-centric world in recent years, an influx in bugs has many turning back to browser detection for a solution. History seems to repeat itself in this regard. It has long been my contention that browser detection should not and can not be relied upon. However, the validity of the use case has become difficult to dismiss, and the lack of an alternative leaves me with no other options and more than a little conflicted. For this article, I will be discussing the various facets of browser detection and offer some recommendations to maximize reliability.

Feature Testing CSS At-Rules

The CSS Object Model (CSSOM) is a standardized convention which defines JavaScript APIs for CSS, similar to what the DOM is to HTML. The W3C specification was originally drafted way back in the year 2000, and as you can imagine, was fairly limited. More recently the spec was expanded to encompass all of what CSS has to offer. This has provided JavaScript a new window into CSS and all of its supported features that was not previously available. This bodes well for feature testing. This article will be specifically addressing the detection of at-rules and how we can leverage them in supported browsers while still providing a fallback solution for those that don’t.

Exploring the Eternal Abyss of Null and Undefined

When discussing primitive data types in JavaScript, most are aware of the basics, starting with String, Number, and Boolean. These primitives are fairly straightforward and function as you might expect. This article, however, will be focusing on the more unique primitive data types known as Null and Undefined; what makes them similar, dissimilar, and overall unusual.

Determine HTML5 Tag Support in JavaScript

The dawn of HTML5 brought about a whole heap of new semantic tags. However, like CSS3, the specification is still relatively new and many of the browsers are slow to adopt the new elements. Tags such as <header>, <footer>, <nav>, <section>, <progress>, <template>, <aside>, <article>, and <canvas> do not possess widespread browser support just yet. Despite this level of inconsistent support, you should not be deterred from using these new tags, but it may be pertinent to be aware of their availability.

Reinventing the Try/Catch Block

The try/catch block is a unique construct, both in how it works and what it is capable of. Fundamentally, it is able to isolate one or more statements to capture and suppress any runtime errors that may be encountered as a result of execution. It is such a powerful construct that in a perfect world you would want to wrap everything in a try/catch block to provide simple and effective error trapping. However, due to concerns in performance critical situations, employing the construct is often frowned upon. But what if I told you there was a means of emulating the try/catch block without the concern for performance? This article will be exploring just such a method.

Leveraging the Most Out of CSS Classes

To harness the most out of CSS classes is to take advantage of what truly is the unsung hero of advanced RIA development as it relates to the presentation layer. When we observe our markup, we find that various portions of the DOM may require styling influences on the initial page load as well as interaction events or cues to adjust its structure, positioning, visibility, state, and skin. For this, classes are the clear suitor as it brings flexibility, modularity, inheritance, and a dynamic and unobtrusive nature to the table.

Detecting CSS Style Support

CSS tends to be in a constant phase of transition as new specifications are continuously proposed, drafted, and then left to the browsers for implementation. How and when a new feature is implemented is determined by the browser, often including their vendor prefix (-moz-, -webkit-, -o-, -ms-) to further dilute the feature. In fact, sometimes the W3C will define an official specification for a feature after one or more browsers have already implemented it. Despite the emergence of CSS3 in both support and usage over the last couple years, it is still very much in the early stages of standardization and implementation which is often changing and debated over. To help combat the confusion, the following article will focus on methods of determining support not just for styles but also their supported assignable values.