diff --git a/assets/css/site.css b/assets/css/site.css index eb7cc8b..c2ff284 100644 --- a/assets/css/site.css +++ b/assets/css/site.css @@ -513,12 +513,12 @@ main { &.rounded { img { - border-radius: 1rem; + border-radius: 0.5rem; } } &.rounded-tl { img { - border-radius: 1rem 0 0; + border-radius: 0.5rem 0 0; } } } @@ -536,6 +536,8 @@ nav { z-index: 2; ol { + backdrop-filter: blur(0.5rem); + background: rgba(247, 247, 247, 0.8); display: flex; flex-direction: row; list-style: decimal-leading-zero; @@ -546,8 +548,7 @@ nav { } li { - background: var(--white); - border-bottom: 1px solid var(--faded); + border-bottom: 1px solid var(--black); height: 3rem; padding: 0.7rem 1.5rem 0.5rem; position: relative; @@ -1619,10 +1620,20 @@ body.simple { } /* article adjustments */ - main > article { + main > article + { p { font-size: 1rem; } + + figure { + &.rounded img { + border-radius: 1rem; + } + &.rounded-tl img { + border-radius: 1rem 0 0; + } + } } /* table of contents is now on the left of the article */ diff --git a/content/studies/honeycomb/index.md b/content/studies/honeycomb/index.md index de63691..e5cfe8f 100644 --- a/content/studies/honeycomb/index.md +++ b/content/studies/honeycomb/index.md @@ -79,7 +79,7 @@ Honeycomb was a large, foundational design-system effort: a **unified design lan But this case study is not primarily about the mechanics of building a design system. Many systems define tokens, document components, and create a composable UI. The more interesting problem was **how we designed Honeycomb from the start _to be used_ inside our particular set of constraints**: different products, different codebases, different teams, different levels of frontend skill, and very different modernization timelines. -That shaped both the earliest decisions and the later priorities: browser-native web technologies, a small JavaScript footprint, CSS variables for theming, progressive adoption, and [unusually thorough documentation](https://honeycomb.style). The system had to meet teams where they were, so the central design and engineering constraint became: make the right thing, but make it easy to adopt before the organization was technically uniform enough to deserve a perfect system. +That shaped both the earliest decisions and the later priorities: browser-native web technologies, a small JavaScript footprint, CSS variables for theming and progressive adoption, and [unusually thorough documentation](https://honeycomb.style). The system had to meet teams where they were, so the central design and engineering constraint became: make the right thing, but make it easy to adopt before the organization was technically uniform enough to deserve a perfect system. {{< /intro >}} @@ -272,8 +272,8 @@ We combined open source icons and drew others to fill the gaps, and **shipped ou {{< figure src="img/stable-icons@2x.png" - alt="Final versions of the app headers for all 6 portfolio products" - caption="Final versions of the app headers for all 6 portfolio products. Certain elements became consistent across products for the first time." >}} + alt="Sampling of the outline and solid icons from the icon set" + caption="Sampling of the outline and solid icons from our set, shown in the Figma component here." >}} We also added ligatures for every icon as well, so that teams could write readable names like `arrow-left` as text instead of the normal `Supporting this request was just one more way we drove adoption.