andrew/portfolio
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Micro fixes!

Browse Source
This commit is contained in:
Andrew Gioia 2026-05-08 21:25:18 -04:00
parent a855c13ba3
commit 748a7c4b8b
Signed by: andrew
GPG Key ID: FC09694A000800C8
2 changed files with 19 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
assets/css/site.css
View File

@ -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 */

6
content/studies/honeycomb/index.md
View File

@ -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: <mark>make the right thing, but make it easy to adopt before the organization was technically uniform enough</mark> 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: <mark>make the right thing, but make it easy to adopt before the organization was technically uniform enough</mark> 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 `<i class="hc-icon hc-icon--arow-left></i>`. This was partly an implementation convenience but mostly a response to a real product request: one team specifically wanted to place icons using words, as they were doing it that way in their app currently. <mark color="red">Supporting this request was just one more way we drove adoption.</mark>