What’s next? CSS data structures?
I think the issue is that an algorithm is typically an unambiguously defined, imperative solution to a problem. It involves step by step instructions that happen in a certain order. Even though you can argue that these CSS patterns are clearly defined solutions to specific problems, the fact that there are no steps involved, no procedure, nothing imperative, makes it odd to call it an algorithm. There are other established words to use, like pattern, utility, hack.
There’s added confusion since CSS obviously involves actual algorithms, like how the engine calculates selector matching, specificity, layout, filters, etc.
I still think it's fair to include the person's activity in the broader idea of what constitutes an "algorithm" here, and I believe the article's language does support my interpretation.
First, the author explicitly acknowledges that "algorithm" is being somewhat misused compared to it's conventional programmer usage, and gives a bunch of reasons why she thinks it's still "useful" to co-opt this word. Some of the point behind this article is precisely to explain and defend her use of the world "algorithm" in this context. Language is fluid, and that's okay & sometimes fun & useful & interesting, right?
Also, there are steps listed in the article, such as defining boxes for layout, then naming them, then listing changes, then determining dependencies. That counts as step-by-step instructions, I think.
The author also said: "A CSS algorithm is well-defined declaration or set of declarations that produces a specific styling output." and "Phrased another way, a CSS algorithm is a very intentional and well thought-out utility pattern."
That's pretty explicitly including the design & thinking in the "algorithm" as I read it, don't you agree?
> an algorithm is typically an unambiguously defined, imperative solution to a problem
The English definition of an algorithm is closer to "a process or set of rules to be followed", and that's basically the extent of it. We programmers can use the word to mean more specific things if we want, but can't claim that the word always means the same thing to others as it does in our expert domain, or even that it always means the same thing in our domain.
I'd have to disagree with the qualification of "imperative", math algorithms and functional algorithms are widely accepted as algorithms by programmers. Unambiguous is always desirable, but can't be the definition. The words "process" and "rules" imply minimal ambiguity.
FWIW, I've been trying to find examples of things conventionally called algorithms, but which are not in essence imperative (in the sense that there are multiple operations that must happen in a certain order - "procedural" is perhaps a more precise word than "imperative"), but I can't really find anything, so I would like to insist that it's one of the defining characteristics of an algorithm.