Custom Devices
Device profiles drive the compile: each entry in the device map becomes a screen--{name} class with its dimensions, density, and color depth baked in. Configure $custom-devices to add your own profiles without touching framework source.
The device map
$devices in
framework/config/_devices.scss defines every
device profile the framework ships. The map is generated from the platform's device registry
(db/data/framework_devices.yml), so it is not
edited by hand.
Each entry becomes a screen--<name> class
carrying the device's dimensions and rendering variables.
Screen
Screen
Device screen dimensions, orientation, and display properties
The Screen component is the outermost container that defines the device dimensions and provides global settings for your content.
shows
how the class is used in markup. Every profile carries the same schema:
| Key | What it sets |
|---|---|
screen-w, screen-h |
Screen dimensions in CSS pixels. |
pixel-ratio |
Physical-to-CSS pixel ratio of the display. |
dither-pixel-ratio |
Ratio dither tiles render at, so patterns stay crisp on high-DPI panels. |
ui-scale |
The device's native interface density factor. |
color-depth |
The grayscale tier: 1, 2, or 4. Full-color profiles carry 12 or 24. |
density-tier |
'1x' or '2x': picks the pixel-font or vector typography tier. |
gap-scale |
Multiplier applied to the gap variables. |
size |
'sm', 'md', or 'lg': the size class the device extends. |
Configure your own
Custom stacks add device profiles without touching framework source: configure
$custom-devices where you load the framework.
Every generator that walks the device set picks the profile up, so a configured device behaves exactly
like a built-in one.
// my-build.scss
@use 'framework' with (
$custom-devices: (
'my-panel': (
'screen-w': 1024px,
'screen-h': 758px,
'pixel-ratio': 1.0,
'dither-pixel-ratio': 1.0,
'ui-scale': 1.0,
'color-depth': 2,
'density-tier': '1x',
'gap-scale': 1.0,
'size': 'lg'
)
)
);<div class="screen screen--my-panel">
<div class="view view--full">...</div>
</div>
Profiles are validated at compile time: a missing key or an invalid
size or
density-tier fails the build with a named
error. An entry that reuses a built-in device name overrides that device. Compile as usual; see
Compiling the Framework
Compiling the Framework
Compile plugins.css and the theme stylesheets from source with Dart Sass
Compile the framework from source with Dart Sass: one entrypoint, one load path, plus a stylesheet per theme. The result is the same plugins.css the release pipeline produces. You only need a source build when a released one is not enough, for modified source or custom device profiles.
.
What a profile generates
- A
screen--<name>class publishing the device variables (--screen-w,--pixel-ratio,--color-depth, ...). - The size behavior of its
sizeclass, and the typography tier of itsdensity-tier. See Scale Scale Scale interface to affect content density and readability Scale the whole interface from one screen modifier by changing the UI scale factor. Use it to match content density to viewing distance or user preference. for how density and scale compose. - The per-device utility rules, like high-DPI outline dots for profiles with a
dither-pixel-ratioof 2 and up.
The JavaScript runtime reads the same variables when it normalizes screen context at render time; see Framework Runtime Framework Runtime How the runtime applies layout, clamping, overflow, and presentation adjustments at render time Different devices have different, fixed amounts of screen space. The Framework Runtime fills that space when a plugin layout renders, doing the heavy, repetitive measuring and fitting for you. Expand the "Framework Runtime" panel under any example on this site to see the stats for that render. .
The built-in byod profile
The map ships a generic byod_custom profile, so
even a released build has a bring-your-own-device class. Apply
screen--byod_custom for a quick start without
compiling anything, then graduate to
$custom-devices when you need your panel's
exact dimensions and depth.