Rendering Layer
The rendering layer is where the browser assembles the final pixels a user sees. It is a compositing surface, not a storage format: the DOM is structured data, the source asset is raw imagery, and the rendering layer is where structure and imagery meet the viewport. CSS filters operate at this layer, applying their transformations to the rasterized output before it reaches the screen. This architecture has specific consequences for the wiki's illustration system. A single stipple PNG stored once on disk can appear rendered in a dozen different ways across the site — inverted for dark mode, sepia-tinted for parchment mode, desaturated for print stylesheet — without any modification to the source file. The layer does the work.
In the AI Story
Because filters are evaluated at the rendering layer, they are recomputed on every repaint. A user who scrolls, zooms, or resizes the window causes the filter chain to re-run. For simple recipes on small images, this is cheap. For complex recipes (multiple saturations, multiple rotations) on large images, it can produce noticeable performance costs, especially on lower-powered devices.
The rendering layer also interacts with the browser's stacking contexts in ways that surprise developers. An element with a non-trivial filter becomes its own stacking context, which can reorder overlaps with adjacent elements and affect how drop shadows cast. Filters interact with z-index, with opacity, with transforms; the interactions are specified but not always intuitive.
For the wiki's purposes, the rendering layer is both an advantage and a constraint. The advantage is the one-source-many-renderings efficiency that makes responsive theming feasible. The constraint is that filter-based theming cannot produce effects the layer does not support: you cannot filter an image into a completely different image, only into a transformation of the one you started with. When a theme requires a fundamentally different illustration — not a recolored version but a different drawing — the rendering layer cannot help, and the source asset itself must change.
The distinction between what the layer can do and what requires new sources is one of the core judgments in maintaining a filter-based illustration system. Early in the system's development, it is tempting to reach for filters for every adjustment; with experience, practitioners learn to recognize which adjustments belong at the rendering layer and which should be baked into the source.
Origin
The rendering layer as a concept predates CSS filters — it is fundamental to how all modern graphics systems work — but its relevance to CSS authoring became sharp with the introduction of filter effects in 2012. Before that, CSS authors could treat rendering as a black box; after, the layer's behaviors became directly addressable.
Key Ideas
Where filters run. Filters are applied at the rendering layer, not to the source asset; the source remains unchanged.
Recomputed on repaint. Every scroll, zoom, or resize that triggers a repaint re-runs the filter chain.
Creates stacking contexts. Filtered elements become their own compositing roots, with implications for overlap and shadow behavior.
One source, many renderings. The layer's architecture is what enables responsive theming from a single asset.
Appears in the Orange Pill Cycle
Further reading
- Paul Irish and Surma, "The Anatomy of a Frame," web.dev, 2020.
- Chrome DevTools documentation, Rendering Performance, accessed 2026.
- Mozilla Hacks, "Quantum: The Next-Generation Web Engine," 2017.
- W3C, CSS Compositing and Blending Level 1, Recommendation, 2015.