Semantyczne tagi HTML brzmią prosto, dopóki nie trzeba ich użyć w praktyce. W teorii większość osób mniej więcej wie, czym są header, main, footer, section czy article. Problem zaczyna się dopiero wtedy, gdy trzeba zdecydować, czy dany fragment strony naprawdę zasługuje na taki element, czy jednak jest tylko zwykłym kontenerem.

To właśnie tu pojawia się większość nieporozumień. header bywa mylony z górnym paskiem strony, footer z czymkolwiek umieszczonym na dole, section z każdym większym blokiem, a article z dowolnym tekstem. Tymczasem semantyczne elementy HTML nie opisują wyglądu strony, tylko rolę danego fragmentu w dokumencie.

I właśnie dlatego warto je rozumieć trochę głębiej.

Semantyczne tagi nie opisują wyglądu, tylko znaczenie

 

To jest najważniejsza zasada. Semantyczny HTML nie służy do tego, żeby kod wyglądał nowocześniej albo bardziej elegancko. Jego zadaniem jest nadanie znaczenia poszczególnym częściom strony.

header nie znaczy po prostu „na górze”.

footer nie znaczy po prostu „na dole”.

section nie znaczy „większy blok”.

article nie znaczy „dowolny tekst”.

main nie znaczy „środkowy wrapper”.

Te elementy mają sens tylko wtedy, gdy odpowiadają na pytanie: czym ten fragment jest w dokumencie?

To duża zmiana perspektywy. W modelu wizualnym myślimy o stronie jako o układzie sekcji, kolumn, przycisków i bloków. W modelu semantycznym zaczynamy myśleć o niej jak o dokumencie z treścią główną, nawigacją, sekcjami tematycznymi, artykułami i częściami pomocniczymi.

main

to nie zwykły środek strony

 

Element main oznacza główną treść konkretnej podstrony. To nie jest po prostu obszar między menu a stopką ani dowolny kontener na środek layoutu. main ma wskazywać tę część dokumentu, która stanowi jego właściwy sens.

Na stronie usługowej main obejmie zwykle treść strony: nagłówek, opis oferty, sekcje z korzyściami, FAQ i CTA. Na wpisie blogowym będzie obejmował właściwy artykuł. Na stronie kontaktowej — treść dotyczącą kontaktu, formularz, dane i mapę.

W praktyce najczęściej powinno się używać jednego main na stronie. To właśnie ten element ma odróżnić część właściwą od elementów powtarzalnych, takich jak globalne menu, nagłówek strony czy stopka.

header

nie jest tylko paskiem z logo

 

To chyba jedno z najczęstszych uproszczeń. header nie oznacza wyłącznie górnej belki strony. Może być oczywiście nagłówkiem całej witryny, zawierającym logo, nawigację i inne elementy wprowadzające. Ale może też być nagłówkiem konkretnej sekcji albo artykułu.

To ważne, bo header nie opisuje położenia na ekranie, tylko funkcję wprowadzającą. Jeśli jakiś fragment otwiera daną część dokumentu, przedstawia jej temat, tytuł albo kontekst, może być header.

Dlatego możesz mieć:

• globalny header strony,

• header wewnątrz article,

• a czasem także header wewnątrz sekcji.

 

To nie jest błąd, jeśli wynika z logiki dokumentu.

footer

to nie tylko stopka całej strony

 

Podobnie działa footer. Najczęściej kojarzy się ze stopką witryny: copyrightem, linkami, danymi firmy czy dodatkowymi odnośnikami. To jest poprawne użycie, ale nie jedyne.

footer może zamykać także konkretną część dokumentu, na przykład artykuł. W takim przypadku może zawierać informacje o autorze, dacie publikacji, tagach, linkach do kolejnych treści albo przypisach związanych właśnie z tym jednym wpisem.

Tak samo jak header, footer nie dotyczy miejsca na ekranie. Dotyczy funkcji zamykającej w obrębie określonego obszaru.

section

ma sens tylko wtedy, gdy naprawdę wydziela temat

 

section jest jednym z najczęściej nadużywanych elementów semantycznych. Bardzo łatwo zacząć traktować go jako wygodny zamiennik div-a dla każdego większego bloku. To jednak prowadzi do sytuacji, w której cała strona składa się z sekcji tylko dlatego, że w builderze ma kilka modułów jeden pod drugim.

Tymczasem section powinien oznaczać logicznie wydzielony fragment dokumentu. Najczęściej taki, który ma własny temat i zwykle da się go opisać nagłówkiem.

Dobra sekcja to nie po prostu kontener na layout, ale część większej całości. Może to być:

• sekcja z korzyściami,

• sekcja FAQ,

• sekcja z opiniami,

• sekcja z opisem procesu.

 

Jeśli element istnieje głównie po to, żeby ułożyć spacing, kolumny albo tło, często zwykły div będzie lepszym wyborem.

article

to treść względnie samodzielna

 

Najlepszy sposób na zrozumienie article jest prosty: to taki fragment treści, który ma sens także poza bieżącym kontekstem strony.

Najbardziej oczywistym przykładem jest wpis blogowy. Ale article może oznaczać też:

• news,

• kartę produktu,

• opinię użytkownika,

• wpis w katalogu,

• post na forum,

• samodzielny element treści na stronie z wieloma rekordami.

 

Kluczowa różnica między article a section polega na tym, że article jest bardziej samodzielny. section jest częścią większego dokumentu. article sam w sobie może być osobną jednostką znaczenia.

To nie znaczy, że każdy blok tekstowy powinien być article. Jeśli coś nie funkcjonuje jako samodzielny byt, często lepsza będzie sekcja albo zwykły kontener.

Nie każdy element musi być semantyczny

 

To też warto powiedzieć wprost. Poprawna semantyka nie polega na tym, żeby usunąć wszystkie div-y ze strony. divnadal jest potrzebny i całkowicie normalny. To po prostu neutralny kontener, który nie niesie dodatkowego znaczenia.

I właśnie dlatego bywa lepszym wyborem niż section czy article, jeśli dany blok nie pełni konkretnej roli w dokumencie. Czasem element służy tylko do stylowania, grupowania albo układu. Wtedy nie ma sensu udawać semantyki na siłę.

Błąd nie polega na używaniu div-ów. Błąd polega na używaniu semantycznych elementów bez zrozumienia, co naprawdę znaczą.

Najczęstsze nieporozumienia wokół semantycznych tagów

 

W praktyce najczęściej powtarza się kilka pomyłek.

Pierwsza to traktowanie każdego większego bloku jako section. To bardzo kuszące, zwłaszcza w builderach, ale semantyka nie polega na mechanicznym zamienianiu wszystkich kontenerów na bardziej „ładne” tagi.

Druga to mylenie położenia z funkcją. To, że coś jest u góry strony, nie czyni z tego automatycznie header. To, że coś jest na dole, nie oznacza jeszcze footer.

Trzecia to używanie article dla zwykłych bloków treści, które nie są samodzielne. Czwarta to traktowanie main jako kolejnego wrappera, który można powielić kilka razy. Piąta to całkowite pomijanie semantyki i budowanie dokumentu wyłącznie jako układu wizualnego.

Wszystkie te błędy mają wspólne źródło: mylenie struktury layoutu ze strukturą znaczenia.

Jak wygląda prosty, zdrowy układ semantyczny

 

Na zwykłej stronie bardzo często wystarczy prosty model:

<header>
<nav>…</nav>
</header>

<main>
<article>
<header>
<h1>Tytuł strony lub artykułu</h1>
</header>

<section>
<h2>Pierwsza sekcja</h2>
<p>Treść…</p>
</section>

<section>
<h2>Druga sekcja</h2>
<p>Treść…</p>
</section>
</article>
</main>

<footer>
<p>Stopka strony</p>
</footer>

To oczywiście tylko przykład, ale dobrze pokazuje logikę:

• header otwiera całość,

• main zawiera główną treść,

• article obejmuje samodzielną jednostkę,

• section dzieli ją na tematyczne części,

• footer zamyka dokument.

 

Nie zawsze potrzebujesz wszystkich tych elementów. Ważniejsze od kompletności jest to, żeby każdy z nich był użyty zgodnie z funkcją.

Najpierw pytaj: czym to jest?

 

Najlepszy sposób myślenia o semantyce jest bardzo prosty. Zanim nazwiesz jakiś fragment strony, nie pytaj najpierw, jak go wystylować. Zapytaj, czym on właściwie jest.

Czy to nagłówek jakiegoś obszaru?

Czy to główna treść tej podstrony?

Czy to logiczna sekcja o własnym temacie?

Czy to samodzielna jednostka treści?

Czy to tylko techniczny kontener?

To jedno pytanie porządkuje więcej niż lista definicji z dokumentacji. Bo semantyczne tagi HTML nie działają dobrze wtedy, gdy używasz ich z pamięci. Działają dobrze wtedy, gdy odpowiadają realnej logice dokumentu.

Semantyka zaczyna się od zrozumienia roli elementu

 

Im lepiej rozumiesz rolę takich elementów jak main, header, footer, section i article, tym łatwiej przestajesz budować stronę jak zbiór bloków wizualnych. Zaczynasz za to budować dokument, który ma sens także poza samym wyglądem.

I właśnie o to chodzi w semantyce. Nie o ładniejsze tagi. Nie o modę. Nie o techniczny rytuał. Chodzi o to, żeby struktura strony mówiła coś więcej niż tylko to, jak została ułożona.

To jest moment, w którym HTML zaczyna opisywać nie tylko interfejs, ale też znaczenie.