Ustawianie krojów pisma w serwisie internetowym nie sprowadza się dziś do jednego znacznika. Temat html font prowadzi w praktyce do CSS, bo to tam decyduje się o rodzinie fontów, zapasowych krojach i sposobie ładowania własnych plików. Jeśli tekst ma być czytelny na komputerze, telefonie i w różnych systemach, te decyzje robią większą różnicę niż sam wybór „ładnego” kroju.
Najważniejsze rzeczy do zapamiętania
- HTML opisuje treść, a CSS odpowiada za wygląd - font ustawiaj w arkuszu stylów, nie w znaczniku.
- Znacznik
jest przestarzały i nie powinien trafiać do nowych projektów. - Dobry zapis fontów to zawsze lista z fallbackiem, a nie jeden pojedynczy krój.
- Własne fonty najlepiej ładować jako
WOFF2i ograniczać do potrzebnych wag. - W projekcie po polsku sprawdź, czy font dobrze obsługuje polskie znaki i nie psuje czytelności przy dłuższym tekście.
Co dziś naprawdę oznacza ustawianie fontu w HTML
W praktyce nie chodzi już o to, żeby „w HTML ustawić czcionkę”, tylko żeby przekazać przeglądarce, jak ma wyglądać tekst. Sam HTML buduje strukturę, a CSS ustala rodzinę fontów, rozmiar, grubość i interlinię. To rozdzielenie jest ważne, bo pozwala jednym miejscem sterować wyglądem całego serwisu zamiast poprawiać każdy akapit osobno.
Najprostszy mechanizm wygląda tak: deklarujesz listę fontów, a przeglądarka wybiera pierwszy dostępny. Jeśli nie ma kroju brandowego, przechodzi do kolejnego z listy, aż w końcu ląduje na rodzinie generycznej, takiej jak sans-serif albo serif. Dzięki temu tekst nie „rozsypuje się” tylko dlatego, że dany font nie został wczytany albo nie istnieje na urządzeniu użytkownika.
Ja patrzę na to zawsze jak na umowę między projektem a przeglądarką: podajesz preferencję, ale zostawiasz bezpieczny plan B. I właśnie dlatego kolejna sekcja zaczyna się od rzeczy, której dziś lepiej unikać.
Dlaczego znacznik font lepiej odłożyć do archiwum
Stary znacznik był kiedyś używany do ustawiania kroju, koloru i rozmiaru tekstu, ale dziś jest już rozwiązaniem przestarzałym. W nowych projektach nie warto się do niego wracać, bo miesza treść z prezentacją, utrudnia utrzymanie kodu i nie pasuje do nowoczesnego podejścia opartego na CSS.
To nie jest tylko kwestia estetyki czystszego kodu. Gdy styl jest wpisany w treść, trudniej go zmienić globalnie, trudniej go testować, a jeszcze trudniej rozbudowywać interfejs bez przypadkowych efektów ubocznych. W praktyce jeden arkusz stylów daje większą kontrolę niż setki drobnych poprawek w samym HTML-u.
| Metoda | Kiedy ma sens | Dlaczego zwykle wygrywa lub przegrywa |
|---|---|---|
|
Tylko przy starym kodzie do poprawy | Przestarzały, trudny w utrzymaniu, nie powinien pojawiać się w nowych wdrożeniach |
Inline style
|
Mały test albo jednorazowa poprawka | Szybkie, ale mało skalowalne i kłopotliwe przy większym projekcie |
| CSS z klasami | Większość stron i aplikacji | Najlepszy balans między kontrolą, czytelnością i możliwością rozwoju |
Jeśli więc widzę pytanie o fonty w HTML, od razu tłumaczę je na język CSS. To prowadzi nas do konkretnego zapisu, który faktycznie warto stosować w projekcie.
Jak poprawnie wskazać kroje pisma w CSS
Najbardziej praktyczny wariant zaczyna się od reguły dla całego dokumentu albo dla wybranych sekcji. Ja zwykle ustawiam rodzinę fontów na poziomie body, a później tylko wyjątkowo nadpisuję ją dla nagłówków, cytatów czy bloków kodu. Dzięki temu typografia zachowuje spójność, a liczba wyjątków nie rośnie bez kontroli.
body {
font-family: "Inter", "Segoe UI", Roboto, Arial, sans-serif;
font-size: 16px;
line-height: 1.6;
}
h1, h2, h3 {
font-family: "Inter", "Segoe UI", Roboto, Arial, sans-serif;
font-weight: 700;
}Ten zapis wygląda prosto, ale zawiera trzy ważne decyzje. Po pierwsze, wskazujesz krój główny. Po drugie, dodajesz fonty zapasowe. Po trzecie, zostawiasz przeglądarce jasny sygnał, jak ma renderować tekst, nawet jeśli pierwszy wybór nie jest dostępny.
Warto też pamiętać o skróconej właściwości font. Potrafi być wygodna, ale wymaga poprawnej kolejności wartości i łatwo ją zepsuć przy szybkiej edycji. W większości projektów wolę rozdzielić odpowiedzialność: font-family do kroju, font-size do rozmiaru, a line-height do komfortu czytania.
To dobra baza, ale jeszcze lepsze efekty daje sensowny łańcuch zapasowy, bo to właśnie on ratuje stronę wtedy, gdy główny font nie zadziała.
Jak zbudować sensowny font stack
Font stack to po prostu kolejność fontów, z której przeglądarka korzysta po kolei. Zaczynasz od kroju głównego, potem dodajesz bliskie zamienniki z danego systemu, a na końcu bezpieczną rodzinę generyczną. Taki układ ma ogromne znaczenie, bo w praktyce nie każdy użytkownik ma te same fonty, a nie każdy własny font zdąży się wczytać natychmiast.
Najlepiej sprawdza się lista z 3 do 5 pozycji. Mniej oznacza słabszy fallback, a więcej zwykle nie wnosi już realnej wartości. Zbyt długa lista wygląda jak zbiór życzeń, a nie przemyślany system typograficzny.
| Zastosowanie | Przykładowa lista | Po co taki układ |
|---|---|---|
| Nowoczesny tekst główny | "Inter", "Segoe UI", Roboto, Arial, sans-serif |
Daje nowoczesny wygląd, a jednocześnie dobrze działa na Windows, Androidzie i w starszych przeglądarkach |
| Treść redakcyjna | Georgia, "Times New Roman", serif |
Sprawdza się tam, gdzie chcesz bardziej klasycznego, książkowego charakteru |
| Kod i bloki techniczne | ui-monospace, SFMono-Regular, Consolas, "Liberation Mono", monospace |
Ułatwia odczyt znaków podobnych do siebie i poprawia czytelność fragmentów kodu |
W polskich projektach zawsze zwracam uwagę na znak diakrytyczny. Font może wyglądać dobrze w angielskim demo, ale dopiero polski akapit pokazuje, czy rzeczywiście nadaje się do dłuższych treści. Jeśli litery takie jak ą, ę, ł, ś, ż są zbyt ciasne albo nieproporcjonalne, efekt końcowy od razu traci klasę.
Gdy stack jest już dobrze ułożony, można pójść krok dalej i dołożyć własny font, ale wtedy trzeba pilnować wydajności i ładowania plików.
Jak bezpiecznie dodać własny font
Własny krój dodaje się dziś przez @font-face. To rozwiązanie pozwala korzystać z fontu przechowywanego lokalnie na serwerze albo pobieranego z innego źródła, a potem używać go w zwykłym font-family. Najczęściej zaczynam od pliku WOFF2, bo to najpraktyczniejszy format do internetu: jest lekki i dobrze wspierany.
@font-face {
font-family: "Cschool Sans";
src: url("/fonts/cschool-sans.woff2") format("woff2");
font-weight: 400;
font-style: normal;
font-display: swap;
}
body {
font-family: "Cschool Sans", "Segoe UI", Arial, sans-serif;
}font-display: swap ma znaczenie większe, niż wielu osobom się wydaje. Dzięki niemu użytkownik widzi tekst od razu, nawet jeśli właściwy font ładuje się jeszcze w tle. To zwykle lepszy kompromis niż pusta przestrzeń albo długie czekanie na perfekcyjny wygląd.
Ja ograniczam też liczbę wariantów. Jeśli potrzebuję tylko regularnej i pogrubionej wersji, nie ma sensu ładować sześciu wag „na wszelki wypadek”. Każdy dodatkowy plik to kolejne kilobajty, a czasem realnie odczuwalne opóźnienie. W przypadku fontów zmiennych można ten problem zmniejszyć, bo jeden plik potrafi pokryć szerszy zakres wag i stylów.
W praktyce najczęstszy błąd nie polega na tym, że font jest zły. Problem zaczyna się wtedy, gdy jest zbyt ciężki, źle opisany albo wczytywany bez planu awaryjnego. To właśnie prowadzi do kolejnej sekcji, czyli typowych potknięć.
Najczęstsze błędy, które psują typografię
W projektach internetowych widzę kilka powtarzalnych problemów. Nie są spektakularne, ale potrafią sprawić, że tekst wygląda przypadkowo, a strona traci profesjonalny charakter.
- Brak fallbacku - jeśli ustawisz tylko jeden font, każda awaria ładowania od razu staje się widoczna.
- Za wiele rodzin pisma - trzy różne kroje na jednej stronie zwykle wystarczą; więcej zaczyna wprowadzać chaos.
- Zbyt dużo wag i stylów - regularny, medium, semibold, bold, italic, bold italic i jeszcze kilka wariantów często robią więcej szkody niż pożytku.
- Za mały rozmiar i zbyt ciasna interlinia - nawet ładny font przegrywa, jeśli tekst trzeba „wydrapywać” wzrokiem.
- Ignorowanie polskich znaków - część fontów wygląda atrakcyjnie w próbnym zdaniu, ale rozjeżdża się przy dłuższych treściach po polsku.
- Poleganie na ustawieniach z projektu graficznego bez testu w przeglądarce - makieta może wyglądać świetnie, ale dopiero realny rendering ujawnia problemy z odstępami, hintingiem i wagą.
Jeśli miałbym wskazać jeden błąd najdroższy w skutkach, byłoby to ślepe zaufanie do samego wyglądu fontu zamiast do jego działania w realnym środowisku. Właśnie dlatego ostatnia sekcja nie będzie już o teorii, tylko o zestawie zasad, które można wdrożyć od ręki.
Najprostszy zestaw zasad, który działa w większości projektów
Gdybym miał zamknąć temat w kilku praktycznych punktach, zrobiłbym to tak:
- Ustawiaj fonty w CSS, nie w HTML.
- Wybieraj jedną rodzinę główną i rozsądny łańcuch zapasowy.
- Trzymaj się umiarkowanej liczby wag, najlepiej tylko tych, które faktycznie są potrzebne.
- Dbaj o czytelność: rozmiar, kontrast i interlinię traktuj jako część typografii, nie dodatek.
- Testuj wygląd na Windows, macOS i Androidzie, bo systemowe zamienniki nie zachowują się identycznie.
- Jeśli używasz fontu własnego, sprawdź wagę pliku i włącz sensowne ładowanie, zamiast liczyć na szczęście.
W projektach takich jak portal technologiczny najczęściej wygrywa nie najbardziej efektowny krój, tylko taki, który nie przeszkadza czytelnikowi. Dobrze ustawiony font ma wspierać treść, a nie walczyć o uwagę z treścią. Jeśli trzymasz się tej zasady, typografia staje się narzędziem, a nie problemem do poprawiania po publikacji.
W praktyce właśnie tak rozwiązuje się temat fontów w nowoczesnym HTML: przez CSS, sensowny fallback i kontrolę nad tym, jak tekst zachowuje się na różnych urządzeniach.
