Niepoprawny HTML: które błędy przeglądarka wybacza, a które kosztują

Zduplikowane id, niedomknięte tagi, zagnieżdżone formularze. Błędy znaczników, które żyją, bo przeglądarka je naprawia, i te, które po cichu psują działanie.

HTML · Opublikowano: 8 września 2026 · 3 min czytania · Марк Лебедев

Przeglądarki wybaczają z założenia: parser HTML ma opisaną procedurę odzyskiwania niemal dla każdego zepsutego wejścia. Ta pobłażliwość sprawia, że niepoprawne znaczniki żyją latami — a część z nich wyrządza realną szkodę, której nikt nie zauważa.

Błędy, które naprawdę psują

Zduplikowane id. document.getElementById zwraca pierwsze dopasowanie i tylko je. Etykieta wskazuje niewłaściwe pole; skrypt podpina handler do elementu, w który nikt nie klika. To najczęstsze znalezisko na witrynach komponentowych, bo id zaszyte wewnątrz komponentu staje się duplikatem w sekundzie, w której komponent wyrenderuje się dwa razy.

Zagnieżdżone formularze. HTML ich nie dopuszcza, a parser po cichu usuwa wewnętrzny. Przycisk wysyłki w środku przestaje działać, a kod w edytorze wygląda poprawnie.

Label bez celu. for="email" przy braku id="email" psuje klikanie w etykietę i pozbawia pole dostępnej nazwy — jeden błąd kosztujący zarówno użyteczność, jak i dostępność.

Elementy interaktywne zagnieżdżone w sobie. Przycisk wewnątrz linku albo link wewnątrz przycisku dają różne zachowanie w różnych przeglądarkach i nieprzewidywalną kolejność fokusa.

Zduplikowane atrybuty. <input value="a" value="b"> — drugi jest odrzucany i zwykle jest to ten dodany później przy naprawie buga.

Błędy w zasadzie kosmetyczne

Niedomknięty <li>, samotny & zamiast &, przestarzały <center>, brakujący type przy skrypcie. Parser radzi sobie ze wszystkimi, a wyrenderowana strona jest identyczna. Warto je poprawić, gdy to tanie, ale na sprint nie zasługują.

Jedno zastrzeżenie: niedomknięte tagi w tabelach i listach zmieniają kształt drzewa DOM, a nie tylko tekst znaczników — czyli przesuwają treść na stronie. Te traktuj poważnie.

Dlaczego linter źródeł nie wystarcza

Szablony składane są w czasie działania. Komponent poprawny sam w sobie staje się niepoprawny na stronie, gdzie wyrenderowano go dwa razy albo opakowano w już otwarty formularz. Linter czyta pliki; przeglądarka widzi złożony dokument. Jedyna wiarygodna kontrola dotyczy wyrenderowanego HTML-a prawdziwych stron:

dla każdej odwiedzonej strony:
  sparsuj serwowany HTML
  czy są id występujące więcej niż raz?
  czy są formularze wewnątrz formularzy?
  czy jest label[for] bez pasującego id?
  czy są elementy interaktywne wewnątrz interaktywnych?

Uruchamiaj to na całej witrynie i grupuj według szablonów — jak przy większości problemów ze znacznikami, jeden zły komponent tłumaczy sto złych stron.

Ile kosztuje pominięcie tego

Nic dramatycznego — i w tym cały kłopot. Formularz, który nie wysyła się na jednym szablonie. Czytnik ekranu nazywający niewłaściwe pole. Handler podpięty do niewidocznego duplikatu. Każde wygląda na osobny błąd, dostaje zgłoszenie, dostaje obejście — a prawdziwa przyczyna, trzy linijki znaczników, zostaje na miejscu i szykuje kolejny "osobny błąd".