We introduced the with abstraction when we realized there was a common pattern across logo (logo files), color (color palette) and typography (fonts). Upon implementing the spec, @cscheid and I realized that fonts are sufficiently different from files and the color palette that they don't fit the with abstraction (see #3).
With only two fields supporting with, it's worth reconsidering. While I like the abstraction, I think color.palette is significantly easier to explain and understand than color.with and I think this is a strong reason to consider switching back to palette instead of with.
That leaves logo.with as a singleton, which could be renamed images without changing the implementation (in theory).
logo:
images:
primary: full-color.png
reverse: full-color-reverse.png
icon: favicon.png
both:
light: primary
dark: reverse
small: icon
medium: both
color:
palette:
white: "#FFFFFF"
black: "#151515"
blue: "#447099"
foreground: black
background: white
primary: blue
typography:
fonts:
- source: google
family: Open Sans
base:
family: "Open Sans"
line-height: 1.25
size: 1rem
We introduced the
with
abstraction when we realized there was a common pattern acrosslogo
(logo files),color
(color palette) andtypography
(fonts). Upon implementing the spec, @cscheid and I realized that fonts are sufficiently different from files and the color palette that they don't fit thewith
abstraction (see #3).With only two fields supporting
with
, it's worth reconsidering. While I like the abstraction, I thinkcolor.palette
is significantly easier to explain and understand thancolor.with
and I think this is a strong reason to consider switching back topalette
instead ofwith
.That leaves
logo.with
as a singleton, which could be renamedimages
without changing the implementation (in theory).