Ryan Morr

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.

The CSS Object Model (CSSOM) is a W3C specification that defines APIs for CSS in JavaScript, encompassing 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.

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.

The dawn of HTML5 brought about a whole bunch of new elments. However, like CSS3, the specification is still relatively new and many of the browsers are slow to adopt the new elements. Elements 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.

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.