Custom selectors, custom rules and custom events. You determine its behavior
I wrote the engine to repeat the same thinking process that the original developers went through, and to understand the difficulties and challenges that they faced. Why? Because it helps you think. With a custom implementation of CSS you can achieve exactly what I mentioned in the first paragraph and thus understand the mechanism a lot better.
disclaimer: I haven’t looked into the native implementation of CSS. There’s a lot you can take from my article (at least I hope), yet please take my words with a grain of salt.
First thing first — demo
Here’s an example of a stylesheet with a custom rule named
This rule will change an element’s contents to “BOOM!” and its border, background, and text color based on the given parameters. Here’s the rule in action:
If you’ll look at the demo’s source code (which I highly advice before you continue any further) you’ll see how I define custom properties to my stylesheet with the
Rule classes. The engine does follow the native CSS path, although it’s still in early stages and doesn’t support many features and capabilities, such as:
- Separation of concerns for styles and events. They can still be used and modified outside the stylesheet.
- Re-evaluation of style if stylesheet gets updated.
- Selector context specifiers e.g.
div + span).
- Any kind of query (
Since this is a customizable engine, with a little bit of creativity you can implement a lot of things, such as animations, URLs, selection and transformation functions, etc.
Indeed, there’s a lot going on under the hood and a lot to go through, so let’s get into the interesting bits.
Keynotes from the implementation
Reading the stylesheet
Receiving information from a given CSS string is a challenge as for itself. Since I wanted to strictly preserve the original CSS experience, I didn’t settle for a JSON, but rather an actual sheet with a set of rules and selectors. To parse it, you first need to be familiar with the concept of an AST.
AST stands for Abstract Syntax Tree, and it’s made out of a hierarchy of nodes; each node represents a different feature of the syntax. Essentially the AST is an in-memory representation of the code from which data can easily be retrieved. In this case, the retrieved data will be the selectors and the rules underneath them. If you wanna know more about the AST, I recommend you to read my article about building a Babel plug-in.
The CSS is broken down into AST nodes like following:
The AST is now presented as a plain JSON. To make things even more convenient, I run it through a second iteration where it’s gonna get wrapped with the classes defined in the registry of the stylesheet, e.g.
ClassNameSelector. A node will be wrapped if it matches the properties of the target class:
With a wrapped AST, not only we can get information about the given CSS string, but we can also call related methods directly from a specific node. So given a node of
Selector type, we can call the
test method to see whether an element actually matches the selector or not.
Detecting changes in the DOM
The engine is heavily based on the
MutationObserver to detect changes in the DOM tree. The mutation observer will trigger a callback with details regards the occurred mutations (see
MutationRecord) from the recent execution loop. The problem with the
MutationObserver is that it will create a mutation record for each mutation occurred without taking into an account the final result. That means that if a DOM node was added, removed, added, removed, and then added, it will appear as if it was removed 2 times and added 3 times, rather than added just once.
To overcome this issue, I’ve normalized the collection of mutation records to include only the mutations which are relevant, based on the logic that I just mentioned (see
One of the core behaviors of CSS is that once it’s loaded, the style is immediately applied. The catch here, is that the mutation observer callback will not be invoked unless real mutations occurred. One way to apply the loaded style is to force the mutations; remove all nodes and re-add them to the observed element. However, this would be very inefficient.
The other, more efficient way of solving this is to synthesize the mutations. Yes, go through each and every node in the DOM tree recursively and create a fake mutation JSON. Once it’s done, the set of mutation records can be injected to the observation callback and the style should be applied based defined customizations to the engine (see
One thing to note is that we‘re likely to change the
style attribute inside rule event handlers, which will unnecessarily re-trigger the mutation callback and might potentially cause an infinite mutation loop. To avoid that I used the
takeRecords() function to dispose the pending mutations from triggering.
Triggering custom events
Events management is a crucial part in the implementation because it will determine the efficiency of the engine. If events aren’t disposed or reallocated exactly when needed, this will dramatically affect how fast will things work.
With each mutation callback, elements are filtered based on the selectors found in the stylesheet AST. Once an element has been cherry-picked, event listeners will be added to it based on the set of rules that are defined under the CSS block that the target selector represents at the current iteration.
The engine uses a very naive approach where events are disposed and reallocated for a specific element whenever there are incoming mutations of addition or attribute modification types. This way I make sure that even if a node was modified and a selector is not relevant anymore, only the right handlers would run once a specific event has been triggered.
If you looked at the source code of the demo, you probably noticed that each rule has a disposal function. In case you didn’t, here’s a snapshot of a sample rule:
The disposal function will run each time the selector is not relevant anymore in which case the element in question will stop listening to the event. So how did I make sure that the disposal function runs on each event disposal? Simple. I’ve splitted the logic into a dedicated module which is responsible for managing the events (see events.js).
The module will add and remove events for given event target as normally, but in addition to that, it will store the event handler alongside the disposal method with internal cache maps. Once an event is removed, the corresponding disposal methods in the cache will be called as well.
How can it be better?
Disposing and reallocating events only when necessary
Right now all registered events for a specific element are being disposed and re-allocated to make sure that only the right handlers will run; this way if a selector becomes irrelevant due to recent changes to the element, it won’t effect its style.
This is a not all-too-bad yet naive approach. It works well, but it’s inefficient, something which will become very noticeable once the stylesheet will grow bigger and bigger. One thing that can be done is to run the
test() function of a specific selector before event listeners are disposed. If there has been a change in the outcome of tests, only then proceed to disposing and reallocating the event listeners.
This can be taken a step further by observing which properties of the element has changed during the application of specific rule, and store them all in-order. Once a selector becomes irrelevant and its rules don’t apply anymore, the style would be re-evaluated only relatively to the style properties which are not affected anymore. This is a very complex mechanism to implement but still achievable.
Unleashing the full potential using web-assembly and WebGL
Needless to say that this is only relevant if you want to implement graphical manipulations such as element shadows, text stroke or image filtering. It’s better to keep things simple and use only the style API which is offered to us right out of the box by the browser.
Concept: Rethink event handling in UI frameworks
Most modern UI frameworks such as React, Angular and Vue are tightly coupling event registering and handing with the component itself. While this has proven itself to work (greatly) over the years, a customizable stylesheet (or eventsheet as you may call it) can be an alternative that can offer some benefits.
- The sheet can be loaded and applied on any existing DOM element regardless of the used UI framework.
- The sheet is heavily customizable and can easily share rules and behaviors between different DOM elements.
- The sheet is very declarative and easy to go through. It’s flat with no indentions of few levels deep.
- different sheets can be loaded on top of different customizations of selectors and rules.
- The sheet is light weight and can be loaded quickly.
Have any counter claims? Prove me wrong! Or maybe prove me right :-) Constructive criticism with solid arguments from any side of the divide will be more than welcome.
☆ The source code is available on GitHub ☆
Note: It’s still just a concept. DO NOT use in production.