Version 0.3 of dtg is out. Check it out on GitHub!
This is a substantial release. By the end of 0.2, I knew that the next version would entail major changes. I didn’t appreciate their extent until the work was underway:
- A new top-level
palettekeyword in the definition file. Palettes collect colors into a set for viewing and manipulating. They are for an earlier, more exploratory stage of color work, where designers puts colors side by side and adjust them until they work well together. Palettes also serve as inputs torolesandsystems, and replace the use ofconstantstoday. - System addressing now uses method parameters instead of paths. Use
sky(3 tint)instead ofsky/3/tint. Dot notation is still used for traversal, e.g.,warm-wash.red(6). This syntax makes it easier to distinguish what’s being used from what’s being configured, while more closely resembling CSS color functions. - A simpler set of out-of-the-box algorithms.
ink-rampbecametint,oklch-scalebecamescaleandblendwas removed by a group oftintsystems. The algorithms are also more focused, with simpler interfaces and fewer responsibilities. Definitions are more concise, and output is now explicitly controlled by the definition file rather than the algorithms. - Modes support color-scheme and inheritance. Modes can now be associated with light or dark color schemes, and they can inherit from other declared modes as well. This makes it easier to build related themes, including high-contrast variants or themes that differ by only a handful of colors.
- Edit the definition file through the bundled web editor. As much as I like the syntax, color work is fundamentally visual. In 0.2, the web editor let you preview colors and how they are used. In 0.3, it supports editing and saving directly. I’ve paid particular attention to the color picker, making it easy to adjust colors, especially when working with
dtg dev --build. A few things are still missing before it is possible to author a definition file from scratch, but we’re getting there. - Quality of life updates to the web editor. Systems can now be simulated without requiring a reference. Color scales are displayed more clearly, and hovering over any swatch reveals its color information.
- And tons of changes to smooth out the rough edges while using
dtg:- The config file
dtg.yamlis renamed todtg.config.yamlso that it’s both more differentiated from the definition file, and closer to other config files inside a codebase. - There is no longer a default path for definition files. Specify them in the config file.
dtg emitbecomesdtg buildand the--liveflag got renamed to--watchto align the verbs to other tools.
- The config file
The CLI can also generate static pages for publishing (dtg docs --out <dir>). Here are the colors that fifthrevision uses, along with a preview of Mosaic’s (my design system) colors and component library.
Truthfully, we’re still in the early stages of the project, where many of the building blocks are still being reconsidered and refined. Version 0.2 demonstrated the value of a color tool that captures how colors are derived. Version 0.3 focused on making the idea practical, with a coherent foundation and usable interface. The basic shape should now be largely stable, with fewer breaking changes going forward. The focus for the next release will be on from-scratch authoring and extension points, as well as support for gradients.
This tool has been invaluable to me and my coding agents as we iterate on Mosaic, and hopefully it will be for you as well.