Declarative vs Imperative
Declarative systems describe outcomes; imperative systems describe steps. CSS is declarative: the author writes filter: invert(1) sepia(1) and the browser figures out how to produce those pixels. A canvas-based image editor is imperative: the author writes code that loops over pixels, reads color values, computes new ones, writes them back. Filter hacks live in the declarative world, but they often express what would otherwise be imperative operations. A developer who understands both modes can reach for whichever fits the task; a developer who only knows one will stretch it into territory where the other would serve better.
In the AI Story
The declarative mode has specific virtues. Stylesheets are small, legible, and amenable to authoring by humans who do not think of themselves as programmers. The browser's implementation absorbs complexity the author never has to confront: color space conversions, GPU acceleration, caching, compositing. The cost is that the author has only the primitives the specification provides; novel operations require either waiting for the spec to add them or abandoning declarative authoring for imperative rendering.
The imperative mode offers complete control at the cost of complete responsibility. A canvas script can produce any transformation of pixel data that fits in memory, but the script author must handle every edge case — color precision, alpha compositing, sub-pixel sampling — that the CSS engine handles automatically. For complex one-off operations this is a reasonable trade; for pipelines that run on every page load across a large site, it is usually the wrong choice.
The wiki's illustration system lives firmly in the declarative world. Its filter recipes are stylesheet fragments, not scripts; its theming is attribute-driven, not computed; its rendering is handled by the browser, not by custom code. This discipline is deliberate. It means the system degrades gracefully (a browser that cannot apply a filter displays the source asset), scales to many devices, and remains legible to authors who join the project without specialized graphics knowledge.
The trade-off becomes visible at the edges. Occasionally an illustration requires an effect the declarative vocabulary cannot express — a specific kind of dithering, a non-uniform color remapping, an effect that depends on the semantic content of the image. In those cases, the correct move is to produce a new source asset (imperatively, in whatever editor the practitioner prefers) rather than to stretch the declarative system into territory where it will break.
Origin
The declarative/imperative distinction is older than computing — it appears in mathematical logic and in the philosophy of language — but its prominence in software engineering grew with the rise of configuration languages, stylesheets, and infrastructure-as-code in the 2000s and 2010s.
Key Ideas
What vs how. Declarative systems specify outcomes and delegate implementation; imperative systems specify steps.
CSS is declarative. Filter recipes describe transformations the browser implements; the author does not write pixel loops.
Graceful degradation. Declarative systems tend to degrade gracefully when primitives are missing; imperative systems tend to fail hard.
Know where to stop. Declarative filter hacking has limits; when the limits bite, produce new source assets rather than fighting the system.
Appears in the Orange Pill Cycle
Further reading
- Harold Abelson and Gerald Jay Sussman, Structure and Interpretation of Computer Programs (MIT Press, 1985).
- Eric S. Raymond, The Art of Unix Programming (Addison-Wesley, 2003) — on policy vs mechanism.
- Martin Fowler, Domain-Specific Languages (Addison-Wesley, 2010).
- Håkon Wium Lie and Bert Bos, Cascading Style Sheets: Designing for the Web, 3rd ed. (Addison-Wesley, 2005).