Road

Road

map

Hardcoding of CSS functions, selectors, selector wildcards, @-rules etc., into the code was avoided because they may change as the W3C specification evolves.

hardcoding CSS functions, selectors like where() is one of the shortcomings of the existing software for removing unused CSS

A summary of the final draft of the algorithm used to get the style block of used CSS selectors

whatever-style-entity [# or .]
if it is an element in [the array of likely CSS selectors]
used-CSS-selector
if not a [string, number or whitespace]
extra style entity {
/*this style block is added to the string of matched styles if the conditions [hover over the hilighted text to see them] above are true*/
}

#1 A frustrating quirk, not a bug, in Node.js happens when matching used style blocks in files of over 1MB in size like the TailwindCSSstylesheet ↴

for(•••) {
/*  this regular for loop begins to increment slowly as though it is a much-delayed setTimeout callback*/
}

The solution to this quirk came from the insight that worded this comment above - "/* this regular for loop begins to increment slowly as though it is a much-delayed setTimeout callback*/"

Wrapping the regular for loop in the code with a lifecycle method in Node.js like process.nextTick, setTimeout or setImmediate fixed this quirk that seems to stem from an event-loop-blocking cause

setImmediate performed the fastest and thus was used with the for loop with a variable number of iterations to increase throughput of the code without slowdowns.
The client-side equivalent of setImmediate - requestAnimationFrame is used in the client-side version of the code