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.