Principles
Core principles
These are the design-system rules this foundation should reinforce.
- Useful systems need layout reasoning, not just pretty tokens.
- Composition quality should be measurable when screens get denser or more responsive.
- Collection surfaces deserve as much mathematical scrutiny as color palettes.
Model
How DK models it
This section connects the concept to the actual DK math and token pipeline.
- Layout tools solve min, preferred, and max constraints into stable stack layouts.
- Composition tools score balance, rhythm, density, and order from geometric inputs.
- These same principles show up in component containment proofs for dense and narrow states.
Practice
How to use it in product work
These are the decisions designers and engineers should make with this foundation in mind.
- Use DK layout reasoning when building dashboards, inspectors, and data-heavy surfaces.
- Treat cards, tables, dialogs, and drawers as layout systems instead of isolated widgets.
- Cross-check responsive states before accepting a component recipe as done.
Interactive route
layout Use the interactive route to explore this foundation live.
Interactive route
compose Use the interactive route to explore this foundation live.
Interactive route
saliency Use the interactive route to explore this foundation live.
Proofs
What the proof layer guarantees
These are the reliability claims DK makes about this foundation today.
- Containment checks catch overflow-prone states before visual review alone would.
- Component proofs can include estimated inline fit and narrow-width behavior.
- The docs system keeps these proof surfaces visible instead of hiding them behind the CLI.
Token notes
- Layout and composition are not just page-level concerns; they influence component recipes and docs guidance.
- Representative collection and overlay components are linked from these foundations pages.