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,
querySelectorAll, facilitate this functionality by querying the DOM via CSS selector strings. However, these new methods lack the performance of their closely related functions:
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.
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.
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.
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.