Hver dev-blogg jeg leste før jeg bygde denne brukte samme skrifttype. Inter, eller system-ui, eller en eller annen geometrisk groteskskrift som ser flott ut på et komponentbibliotek og ikke sier noe om personen som skriver. Min gjør det ikke. Åpne hvilken som helst side her og du leser Literata, en antikva, på både overskriftene og brødteksten. Det var ikke tilfeldig og det tok lenger tid å lande på enn jeg forventet.
oppdraget jeg ga meg selv
Da jeg satte meg ned for å gjøre om utseendet på denne siden (hele greia gikk gjennom flere redesignrunder enn jeg vil innrømme, sporet som V1 til V7.3 i mine egne notater hvis du vil ha den pinlige detaljen) var første forsøk "feltnotater, mose og papir." Generisk naturbloggenergi. Min egen anmelder, altså meg selv en uke senere, forkastet det for å lese akkurat som enhver annen bloggmal der ute. Ideen som overlevde var "dagboken, høylytt": noe som leser som en faktisk notatbok noen fører, ikke en content marketing-landingsside med en blogg boltet på.
En groteskskrift for grensesnitt tar deg ikke dit av seg selv. Grotesk er det du griper til som standard fordi hvert designsystem leveres med en, og fordi den rendres rent i små grensesnittstørrelser. Men et avsnitt med brødtekst satt i en geometrisk grotesk leser som programvare, ikke skriving. Antikvaskrifter bærer den gamle avis- og bok-assosiasjonen enten du vil eller ikke, og siden denne siden stort sett handler om meg som skriver om hva jeg har bygget og hva som gikk galt, ville jeg at den skulle lese som noe skrevet, ikke som et dashbord.
hvorfor akkurat Literata
Jeg ville ikke ha en display-antikva som bare fungerer i overskriftsstørrelse og faller fra hverandre ved 17px. Literata er bygget nettopp for dette, den startet livet som et Google-prosjekt for skjermlesing i bokformat, og den kommer som en variabel skrifttype, vekter fra 400 til 900, både rett og kursiv, i én fil per stil. Det betyr noe fordi en tung vekt for h1 og en lett en for brødtekst kommer fra samme skrifttype i stedet for to forskjellige fonter som later som de matcher.
--font-display: 'Literata', ui-serif, Georgia, serif;
--font-body: 'Literata', ui-serif, Georgia, serif;
--font-mono: 'IBM Plex Mono', ui-monospace, monospace;Både display og body peker på samme familie. Overskrifter og avsnitt er samme skrifttype i forskjellige vekter, som er en del av det som gjør at hele siden leser som én stemme i stedet for at en overskriftsfont gjør en forestilling over en generisk brødtekst under.
CDN-tabben
Første forsøk på å koble dette til gjorde jeg det enhver tutorial forteller deg å gjøre: link-tag rett til Google Fonts, ferdig på fem minutter.
<!-- first pass -->
<link
rel="stylesheet"
href="https://fonts.googleapis.com/css2?family=Literata:wght@400..900&display=swap"
/>Det fungerte, i den forstand at skrifttypen dukket opp. Det jeg ikke tenkte på før senere er at dette betyr at hver besøkendes nettleser gjør en ekstra nettverkstur til Google før den faktiske teksten kan rendres, og hvis den forespørselen er treg eller blokkert, kobles fallback-stakken inn og byttes så ut under deg, som er den flash-of-unstyled-text alle klager på men ingen navngir riktig (det er ikke "ustylet", det er "stylet i feil font i ett sekund").
Fiksen var å vendore den. Jeg hentet de faktiske woff2-filene fra Google Fonts CSS2-API-et én gang, for hånd, og committet dem under static/fonts/, subsettet ned til latin pluss latin-ext så jeg ikke sendte kyrilliske og greske glyftabeller ingen på denne siden trenger:
@font-face {
font-family: 'Literata';
font-style: normal;
font-weight: 400 900;
font-display: swap;
src: url('/fonts/literata-normal-latin.woff2') format('woff2');
unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+0304,
U+0308, U+0329, U+2000-206F, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}Fire slike blokker totalt, rett og kursiv, latin og latin-ext, hver med sitt eget unicode-range slik at en nettleser bare laster ned subsettet den faktisk trenger for å rendre siden foran seg. Ingen npm-pakke, ingen font-CDN ved kjøretid, ingenting pekt mot en Google-server lenger. IBM Plex Mono, kodeblokk-fonten, kommer fortsatt fra Google Fonts-CDN-et fordi det er en mye mindre forespørsel (ett vektpar, brukt til kode, ikke hele siden) og jeg har ikke fått gjort noe med å vendore den også ennå. Konsistens skulle tilsi at jeg burde. Jeg har ikke ennå.
lesebredde, tingen ingen legger merke til før den er feil
Det er en CSS-klasse i layoutet som heter .measure:
.measure {
max-width: 68ch;
}ch er en enhet som betyr "omtrent bredden på tegnet 0 i gjeldende font." Sett brødtekst til 68 av dem og du setter linjelengden til et sted rundt 65-75 tegn avhengig av bokstavformene, som er det området typografifolk har sitert i tiår som det søte punktet før øyet begynner å miste plassen sin på vei tilbake til starten av neste linje. Full-bredde tekst på en bred skjerm uten noen begrensning er ekte ubehagelig å lese i mer enn ett avsnitt, og nesten ingen bloggmaler bryr seg om å håndheve det, de bare lar innholdskolonnen strekke seg til hva enn grid-et gir den.
Jeg kjente ikke dette begrepet før jeg begynte å legge merke til hvorfor noen blogger føles lette å lese og andre føles som arbeid selv når selve skrivingen er grei. Det er ikke ordene, det er linjelengden.
den faktiske grunnen, under alt det der
All den tekniske begrunnelsen er sann, men den er også litt i etterkant. Den ekte grunnen er at jeg ville at dette skulle føles som mitt og ikke som et tema jeg installerte. En fyr på Lovund som skriver om Django-skript og halvmaratoner i samme skrifttype som Random House bruker på faktiske bøker føltes som riktig mengde mismatch. De fleste dev-blogger er grotesk fordi "rent" og "teknisk" ble likestilt et sted underveis og ingen stilte spørsmål ved det. Min trenger ikke se ut som en SaaS-landingsside. Den er ikke det.
skalaen er heller ikke flat
Når skrifttypen var bestemt måtte jeg fortsatt bestemme hvor høylytt hver størrelse fikk lov til å være i forhold til de andre. Typeskalaen her går på omtrent et 1,25-forhold mellom trinnene, en h3 på 1.3125rem, h2 på 1.6875rem, opp gjennom h1 på 2.125rem, med brødtekst på 1.0625rem og en linjehøyde på 1.65 (det tallet betyr nesten like mye som skrifttypevalget, for stramt og en antikva i brødtekststørrelse blir visuelt støyende, for løst og avsnittene begynner å føles frakoblet fra hverandre). Innleggstitler spesifikt følger ikke den faste trinnstigen i det hele tatt, de skalerer med clamp() mellom 2.25rem og 3.5rem avhengig av skjermbredde, siden en innleggstittel er det ene stedet på en side der jeg ville ha et genuint høylytt display-øyeblikk i stedet for enda et trinn på en forutsigbar skala. h1 bærer den tyngste vekten på siden, 800, mens h2 til h4 alle ligger på 700, så det er nøyaktig ett "rop" i hele hierarkiet og alt annet holder seg ett trinn roligere enn det, med vilje.