Porządkowanie tekstu w HTML wygląda prosto tylko na pierwszy rzut oka. W praktyce hasło enter w html sprowadza się do wyboru między nową linią a nowym akapitem, a to decyduje o semantyce, dostępności i tym, jak treść zachowa się na telefonie. Poniżej pokazuję, kiedy użyć , a kiedy lepiej sięgnąć po albo CSS.
Najkrótsza odpowiedź o łamaniu linii w HTML
-
-
służy do oddzielania pełnych akapitów, a odstępy między nimi powinny wynikać z CSS, nie z pustych znaczników. -
przydaje się do kodu, logów i tekstów, w których układ znaków ma zostać zachowany. - Sam klawisz Enter w źródle HTML nie tworzy widocznego akapitu ani łamania linii.
- Do tekstu z formularzy i CMS-ów często lepiej pasuje
white-space: pre-linealbopre-wrapniż dokładanie kolejnych
Kiedy potrzebujesz nowej linii, a kiedy akapitu
Przeglądarka nie czyta kodu tak jak edytor tekstu. Zwykły Enter w pliku HTML nie daje sam z siebie widocznej przerwy, bo białe znaki są zwykle upraszczane. Dlatego najpierw trzeba odpowiedzieć na proste pytanie: czy masz jeden ciągły fragment treści, czy kilka oddzielnych myśli.
Ja patrzę na to tak: jeśli da się streścić fragment jednym zdaniem przewodnim, zwykle wystarczy jeden akapit. Jeśli każdy kawałek ma własny sens i własną puentę, potrzebujesz osobnych bloków. To rozróżnienie jest ważniejsze niż samo wstawienie znacznika, bo wpływa na czytelność, SEO i obsługę przez technologie wspomagające.
W praktyce dobrze jest myśleć o tekście jak o układzie logicznym, a nie o dekoracji. Kiedy to rozdzielisz, dobór elementu staje się prosty, a sam kod przestaje walczyć z treścią.
Najprostszy sposób na pojedyncze złamanie linii
Znacznik
Cmsatora.pl
ul. Przykładowa 12
00-000 Warszawa
Ten sam zabieg dobrze działa też w krótkich cytatach, podpisach pod grafikami albo w formularzach, gdzie treść ma zachować liniowy rytm. Nie używaj jednak serii kilku
Kiedy akapit działa lepiej niż br
Akapit to nie tylko wygodniejszy zapis wizualny, ale też lepsza decyzja semantyczna. W dokumentacji MDN jest opisany jako element oznaczający akapit, a nie zwykłą linię tekstu, i właśnie dlatego to on powinien nosić ciężar zwykłej prozy. W praktyce czytniki ekranu i inne technologie wspomagające dużo lepiej radzą sobie z tekstem podzielonym na prawdziwe akapity niż z blokami sklejonymi z
Ja stosuję zawsze wtedy, gdy tekst ma być czytany jak normalna treść strony. To dotyczy między innymi:
- artykułów blogowych i poradników,
- opisów usług i kategorii,
- leadów oraz krótkich wstępów,
- notek firmowych i sekcji „o nas”.
Odstęp między akapitami ustawiam w CSS, zwykle przez margin i line-height, a nie przez puste znaczniki. Dzięki temu tekst wygląda stabilnie także po zmianie motywu, długości treści albo szerokości ekranu. Kiedy to masz pod kontrolą, sensownie staje się porównanie z innymi sposobami formatowania.
.article p {
margin: 0 0 1rem;
line-height: 1.7;
}Co wybrać między br, p, pre i white-space
W codziennej pracy najwięcej czasu oszczędza mi prosta tabela decyzyjna. Zamiast zgadywać, co „będzie wyglądało lepiej”, wybieram element pod konkretny rodzaj treści.
| Element lub reguła | Kiedy go użyć | Największa zaleta | Typowy błąd |
|---|---|---|---|
|
Pojedyncze złamanie linii wewnątrz tego samego bloku | Prosty i czytelny sposób na adres, podpis albo krótki wers | Używanie go do odstępów między akapitami |
|
Oddzielne akapity i zwykła treść redakcyjna | Dobra semantyka i lepsza dostępność | Robienie pustych akapitów tylko po to, by zwiększyć odstęp |
|
Kod, logi, ASCII art, tekst z zachowanym układem znaków | Przeglądarka zachowuje spacing i łamanie linii | Stosowanie go do zwykłych akapitów, które mają wyglądać lekko |
white-space: pre-line |
Treści z CMS, formularzy lub textarea, gdzie chcesz zachować nowe linie | Zachowuje łamanie wierszy, ale nadal pozwala na normalne zawijanie | Zakładanie, że to zadziała tak samo jak |
white-space: pre-wrap |
Teksty, w których liczą się także odstępy i oryginalny układ | Najwierniej odwzorowuje treść źródłową | Brak testu na małych ekranach i zbyt szerokie bloki |
To właśnie przy treściach z paneli CMS najczęściej wygrywa CSS, bo pozwala zachować układ bez ręcznego wstawiania znaczników. Warto też pamiętać, że przy długich adresach, identyfikatorach albo importowanych notatkach dobór reguły ma większe znaczenie niż sam wygląd w edytorze. I tu zaczynają się błędy, które widać dopiero po wdrożeniu.
Najczęstsze błędy przy formatowaniu tekstu
Najczęściej psują układ nie same znaczniki, tylko ich nadużycie. W projektach stron i CMS-ów widzę te same potknięcia bardzo regularnie, zwłaszcza gdy ktoś wkleja treść z Worda albo zewnętrznego edytora.
- Robienie odstępów serią
- Wstawianie pustych
tylko po to, by „oddychał” layout. - Liczenie na to, że Enter w źródle HTML zadziała jak w edytorze tekstu.
- Używanie
do zwykłej prozy, przez co treść wygląda ciężko i technicznie. - Mieszanie akapitów z nagłówkami, listami i tabelami bez zrozumienia, że akapit sam się zamyka przed elementem blokowym.
W praktyce te błędy kosztują czas już po publikacji: trzeba poprawiać odstępy, dostosowywać mobile i sprawdzać, co zrobił edytor treści po stronie panelu. Na hostingu nic się tu magicznie nie naprawi, bo problem siedzi w strukturze HTML, nie w serwerze. Gdy wiesz, czego unikać, można złożyć prosty schemat pracy, który działa w większości stron.
Prosty schemat, który stosuję w projektach stron i CMS-ów
Jeśli mam uporządkować łamanie linii w kilku krokach, robię to zawsze tak samo:
- Dzielę treść na akapity semantyczne i zapisuję je jako
. -
- Do kodu, adresów i transkrypcji wybieram
albo CSS zwhite-space. - Odstępy i rytm tekstu ustawiam w CSS, zwykle przez
marginiline-height. - Sprawdzam efekt na telefonie, bo tam najłatwiej widać, czy układ jest jeszcze czytelny.
.wysiwyg {
white-space: pre-line;
}Jeśli mam zostawić jedną zasadę, to prostą: najpierw wybieram poprawny semantycznie element, dopiero potem dopracowuję wygląd CSS-em. Dzięki temu tekst jest czytelniejszy, łatwiejszy w utrzymaniu i mniej podatny na błędy, gdy zmieni się szablon, CMS albo długość treści.
