Explanation

Discussion of why Krysalicss is shaped the way it is. No steps, no API tables. Read these to build a mental model; you don't need them to use the framework.

• Design philosophy: what "JS-free", "extremely modular", and "multi-theme by design" mean in practice, and the tradeoffs each one carries.
• Why semantic CSS: why class names should describe role, not presentation — and which helpers in the framework drift from that line.
• Comparison: Bulma, Picnic, Tailwind : where Krysalicss sits in the existing ecosystem and which problems it is and isn't trying to solve.
• Architecture overview: the SCSS module graph, the plugin pattern, and the anti-circularity rules: at a height useful for adding components, not just consuming them.
• Combinations and light variants: how $default-combination, $enable-light, and the .is-<combo> / .is-<combo>.is-light contract work across every theme-aware component.
• Variable layers: the three-layer split (declarative / semantic / runtime) that lets themes re-tune everything without touching component source.
• Theme architecture: what each bundled theme (default, dark, high-contrast) targets, and why high-contrast is opt-in only.
• Recommendation: variable typography: why a variable font is the recommended default for $family-sans-serif, and what you trade off in exchange.
• RTL support: how the framework stays bidirectional via logical properties, what consumers verify in their own CSS, and how to test both directions.