Czy walidacja HTML ma znaczenie?

Oryginalny post: HTML Validation: Does It Matter?

Autor: Jeff Atwood

Sieć jest, ujmijmy to litościwie, raczej wyrozumiałym miejscem. Możesz karmić przeglądarki internetowe prawie każdym rodzajem kodu HTML czy JavaScript, a one dzielnie postarają się zrobić z tym coś sensownego i wyrenderować to w najlepszy możliwy sposób. Dla porównania, większość języków programowania jest niemal srodze bezlitosna. Jeśli choć jeden znak nie jest na swoim miejscu, Twój program prawdopodobnie się nie skompiluje, a tym bardziej nie uruchomi. W rezultacie, środowisko HTML + JavaScript jest raczej unikalną -- a często frustrującą -- platformą do tworzenia oprogramowania.

Ale tak nie musi być. Istnieją mechanizmy dające możliwość walidowania Twojego kodu HTML poprzez oficjalny Walidator W3C. Zabawa z walidatorem podkreśla tylko, jak głeboko polityka standardowej wyrozumiałości przenikneła do sieci. Dennis Forbes przepuścił ostatnio parę stron internetowych przez walidator, łącznie z tą, z przewidywalnie złym rezultatem:

FAIL - http://www.reddit.com - 36 błędów jako XHTML 1.0 Transitional. EDIT: Ponownie sprawdziłem Reddit i teraz jest PASS
FAIL - http://www.slashdot.org - 167 błędów jako HTML 4.01 Strict
FAIL - http://www.digg.com - 32 błędów jako XHTML 1.0 Transitional
FAIL - http://www.cnn.com - 40 błędów jako HTML 4.01 Transitional (wywnioskowane, iż nie było wyspecifikowanego doctype)
FAIL - http://www.microsoft.com - 193 błędów jako XHTML 1.0 Transitional
FAIL - http://www.google.com - 58 błędów jako HTML 4.01 Transitional
FAIL - http://www.flickr.com - 34 błędów jako HTML 4.01 Transitional
FAIL - http://ca.yahoo.com - 276 błędów jako HTML 4.01 Strict
FAIL - http://www.sourceforge.net - 65 błędów jako XHTML 1.0 Transitional
FAIL - http://www.joelonsoftware.com - 33 błędów jako XHTML 1.0 Strict
FAIL - http://www.stackoverflow.com - 58 błędów jako HTML 4.01 Strict
FAIL - http://www.dzone.com - 165 błędów jako XHTML 1.0 Transitional
FAIL - http://www.codinghorror.com/blog/ - 51 błędów jako HTML 4.01 Transitional
PASS - http://www.w3c.org - bez błędów jako XHTML 1.0 Strict
PASS - http://www.linux.com - bez błędów jako XHTML 1.0 Strict
PASS - http://www.wordpress.com - bez błędów jako XHTML 1.0 Transitional

W skrócie, żyjemy w zdeformowanym świecie. Tak bardzo, że zaczynasz wątpić w to, czy walidatory w ogóle mają rację bytu. Kiedy widzisz takie logo na stronie, co ono dla Ciebie znaczy? Jak bardzo wpłynie na Twoje odczucia związane z daną stroną? Z punktu widzenia programisty? Z punktu widzenia użytkownika?

w3c-pass-html

Właśnie zrobiliśmy ćwiczenie polegające na zwalidowaniu kodu HTML strony Stack Overflow. Prawie od razu odrzuciłem pomysł walidowania jako XHTML, ponieważ jak najbardziej zgadzam się z Jamesem Bennettem

Prostym i słodkim powodem jest po prostu to: XHTML nie oferuje korzyści nie do odparcia -- jak dla mnie -- w porównaniu do HTMLa , ale nawet jeśli, to oferowałby również większą złożoność i niepewność, co według mnie nie byłoby atrakcyjne.

Całe to walidowanie HTMLa jest wątpliwe, ale walidowanie jako XHTML jest masochizmem pełną parą. Rekomendowane tylko tym, którzy lubią ból. Albo programistom. Nigdy ich nie rozróżniam.

Mimo wszystko zwalidowaliśmy stronę jako bardziej rozsądny HTML 4.01 strict, ale nawet teraz nie jestem pewien, czy warto było na to poświęcać czas. Wiele zasad walidacji wydaje się być dowolnymi i bez znaczenia. A co gorsza, niektóre z nich są najnormalniej szkodliwe. Na przykład poniższe nie jest dozwolone w HTML strict:

<a href="http://www.example.com/" target="_blank">foo</a>

Tak jest, target, całkowicie bezpieczny atrybut dla odnośników, które chcesz, aby się otwierały w osobnej zakładce bądź oknie przeglądarki, jest z jakiegoś powodu zabroniony w HTML 4.01 strict. Jest na to oficjalnie wspierane obejście, ale jest zaimplementowane jedynie przez Operę, więc w efekcie.. nie ma obejścia.

Aby dostosować się do walidatora HTML 4.01 strict, musisz pousuwać atrybuty target i w zamian wstawić JavaScript, który robi dokładnie to samo. Tak więc, natychmiast zacząłem się zastanawiać: Czy ktokolwiek waliduje nasz JavaScript? A co z CSS? Czy ktokolwiek waliduje nasze manipulacje na DOM'ie, które JavaScript uskutecznia na kodzie HTML? Kto waliduje walidator? Dlaczego nie mogę przestać myśleć o zebrach?

Czy naprawdę ma znaczenie to, czy wyrenderujemy coś w ten sposób..

<td width="80"> <br/>

.. czy w ten?

<td style="width:80px"> <br>

Znaczy się, kto wymyśla te zasady? I z jakiego powodu?

Nie mogłem się powstrzymać od uczucia, iż walidowanie jako HTML 4.01 sctrict, przynajmniej w naszym przypadku, było jednym wielkim ćwiczeniem na znajdowanie nic nieznaczących różnic, przerywanym denerwującymi zmianami, które byliśmy zmuszeni zrobić bez praktycznego zysku. (Co więcej, jeśli posiadasz masę zawartości wygenerowanej przez użytkowników, tak jak my, od razu możesz wyrzucić przez okno swoje marzenia o 100% zgodności.)

Po tym wszystkim, walidacja ma swoje uroki. Było parę rzeczy w naszym kodzie HTML, które proces walidacji uwydatnił, a które były wyraźnie źle - osamotniony tag tutaj, parę niekonsekwencji podczas aplikowania tagów tam. Mark Pilgrim przedstawia argumenty za walidacją:

Nie twierdzę, że Twoja strona raz zwalidowana, będzie się się bezbłędnie wyświetlać w każdej przeglądarce; może tak nie być. Nie twierdzę również, że nie ma utalentowanych twórców, którzy piszą strony w starym stylu, ze źle sformatowanym kodem HTML, które wyświetlają się bezbłędnie w każdej przeglądarce; z pewnością tacy są. Ale walidator to automatyczne narzędzie, które potrafi wyłapać małe, ale ważne błędy, które są trudne do ręcznego wytropienia. Jeśli w większości tworzysz walidujący się kod, możesz skorzystać z tej automatyzacji do wyłapywania sporadycznych błędów. Ale jeśli Twój kod nie przypomina nawet poprawnego, będziesz działał na oślep, jeśli coś pójdzie źle. Walidator wypluje dziesiątki, jak nie setki, błędów na Twojej stronie i znalezienie jednego, który w rzeczywistości powoduje Twój problem, będzie jak szukanie igły w stogu siana.

Jest w tym trochę prawdy. Przyswajanie zasad walidatora, nawet jak się z nimi nie zgadzasz, uczy Cię definicji "poprawności". Osadza Twój kod w rzeczywistości. To jest jak przepuszczenie swojego kodu przez bardzo restrykcyjny program walidujący typu lint bądź ustawienie opcji kompilatora na najbardziej rygorystyczny poziom. Wiedza na temat zasad i ograniczeń pomaga Ci zdefiniować to, co robisz i daje Ci uzasadnione argumenty na zgodzenie się z tym bądź nie. Możesz dokonać świadomego wyboru zamiast takiego w stylu "po prostu tak robię i to działa".

Po naszych przejściach związanych z walidacją HTML, oto moja rada:

  1. Waliduj swój kod HTML. Wiedz co to znaczy mieć walidujący się kod HTML. Zrozum narzędzia. Więcej informacji to zawsze lepiej niż mniej informacji. Po co błądzić po omacku?
  2. Nikogo nie obchodzi to, czy Twój kod HTML jest poprawny. Oprócz Ciebie. Jeśli tego chcesz. Nie pomyśl sobie, że wyprodukowanie idealnie walidującego się kodu HTML jest ważniejsze od uruchomienia swojej strony, dostarczania funkcjonalności, które cieszą użytkowników albo od skończenia swojej pracy.

Ale pytanie pozostaje: czy walidacja HTML faktycznie ma znaczenie? Tak. Nie. Może. To zależy. Powiem Wam to samo, co mi powiedział mój ojciec: to jest moja rada, a zrobisz z tym co chcesz.

Data publikacji oryginału: 5 marca, 2009

17 komentarze:

pozycjoner.net pisze...

Jest jeszcze jedna strona medalu - pozycjonowanie .
Roboty wyszukiwarek z natury nastawione są na czytanie "relatywnie" poprawnego kodu strony.
Jeśli w kodzie strony robot znajduje jakiś kosmos to strona może zostać niepoprawnie zaindeksowana (albo w ogóle) , oraz może mieć "punkty ujemne" w wynikach wyszukiwania .

Weźmy np kod HMTL wygenerowany przez FronPage - przecież tutaj są 2000 linii niezgodnego kodu dla strony którą można napisać w 200 liniach, że o zagnieżdzeniach tabel do n-tego poziomu nie wspomnę. Przy takim nawale kodu wystarczy porosty błąd aby robot zgłupiał...

Walidator ma 1 podstawowy plus - wyłapuje niedomknięte znaczniki - a to IMHO kluczowa sprawa (dla robotów i SEO ). A strony WEB2.0/3.0 w całości zgodne z w3c rzadko się zdarzają (ale jest możliwe)

Immortal pisze...

@pozycjoner: Wydaje mi się, że boty całkiem sprawnie radzą sobie z niepoprawnym kodem HTML. Jest sporo bibliotek typu HTML::Sanitizer, które są w stanie w miarę sensownie sparsować nawet mocno niepoprawny kod. Może masz jednak rację co do "punktów ujemnych" - to może być dosyć istotne.

koziołek pisze...

kod poprawny ma też tą zaletę, że ładuje się szybciej. Biblioteki parsujące i przeglądarki nie muszą stosować obejść i różnych trików by "domyślić się co poeta miał na myśli". Kod poprawny wpływa zatem na komfort użytkownika. Czy kod poprawny jest dobrze wyświetlany przez przeglądarki? Obecnie już w większości tak. Należy tylko uzbroić się w cierpliwość i użyć zasad opisanych tutaj:
http://css-tricks.com/examples/CleanCode/Beautiful-HTML.png

vashpan pisze...

Jak dla mnie HTML nalezaloby zlikwidowac i stworzyc od nowa. Niestety na to juz jest za pozno.

batman pisze...

Zawsze staram się pisać kod zgodny ze standardami. W końcu po coś one powstały. Z drugiej jednak strony wspomniany target w xhtml, a raczej jego brak, to jedno wielkie nieporozumienie. Dlatego też na pierwszym miejscu stawiam wygodę pisania, na drugim zgodność z przeglądarkami, a dopiero na końcu zgodność z W3C.

Anonimowy pisze...

Nudny temat, wałkowany 10000 razy - zamykam yyy no :D

Pozdrawiam
Cysiaczek

Krzysiek pisze...

Powody podane przeciwko walidacji świadczą tylko o nieznajomości tematu:

1. target="_blank" w znaczniku a

Intencją wyrzucenia tego znacznika jest przerzucenie na użytkownika wyboru gdzie nowa strona powinna być otworzona (to okno - domyślnie / nowe okno / nowa karta). Jeśli komuś tak bardzo to przeszkadza i chcę mieć kontrolę nad tym niech nie używa HTML Strict tylko Transitional, który dopuszcza target.

2. td width="80" / td style="width:80px"

Kierunkiem w którym podąża tworzenie stron jest oddzielenie danych od sposobu wyświetlania. Jeśli używasz atrybutu width a zarazem części języka (x)HTML wtedy wygląd ustawiasz w treści. Używając style (a konkretniej powinien to być zewnętrzny plik css), oddzielasz formę od treści. Dzięki temu jesteś w stanie zmienić wygląd dowolnego elementu na stronie nie dotykając się do danych czyli html.

Jeśli większość argumentów jest tego typu to proponuję poczytać trochę zanim zacznie się osądzać.

Tomasz Kowalczyk pisze...

Dlatego generalnie jest tak, że najpierw tworzy się kod maksymalnie poprawny i taki, który się waliduje, a potem się go "poprawia" dla konkretnych przeglądarek. Gdyby wszystkie przeglądarki wyświetlały kod w ten sam sposób, nie byłoby problemu.

Krzysiek pisze...

Wszystkie nowoczesne przeglądarki (czyli Firefox,Opera,Safari,Chrome,IE >= 7) wyświetlają kod tak samo, tylko trzeba odpowiednie DOCTYPE ustawić.

Konradzik pisze...

Pracuję przy dużym serwisie który ma dużo contentu dodawanego przez userów - więc tak jak napisano w artykule - nie da się utrzymać porządku. Zrezygnowaliśmy z bibliotek typu html tidy, bo po prostu uszkadzały użytkownikom kod. Dodaliśmy edytory WYSIWYG które, naszym zdaniem, produkują wystarczająco dobry kod.

To co mówią pozycjonerzy, że kod w3c-poprawny zwiększa szanse na dobre wypozycjonowanie, moim zdaniem jest przesadzone. Widzimy wszyscy jak przeglądarki radzą sobie z nawet najgorszym kodem i wiemy wszyscy, że internet jest pełen właśnie tego najgroszego kodu. Czy ktoś może być tak nieświadom rzeczywistości, żeby pisać boty które dobrze rozpoznają i interpretują tylko kod validujący się? Szczerze wątpię.

Mimo wszystko uważam, że walidacja jest ważna a pisanie poprawnego, przejrzystego kodu to nie jest nadmiarowa, niepotrzebna praca. Taki kod łątwiej utrzymać, rozwijać, szybciej się ładuje, jest mniejsza szansa, na to, że wystąpią różnice między przeglądarkami.

Zgadzam sie z Krzyśkiem, że wszystkie nowe przeglądarki wyświetlają już dobrze napisane strony niemal identycznie.

Immortal pisze...

@Krzysiek:

1. target="_blank"

Twórcy standardu mogliby zostawić decyzję developerom. To że niektórzy użytkownicy mogą się irytować, przeglądając jakąś stronę, to już problem jej twórców.

2. width="80" vs style="width: 80px;"

Tutaj również wszystko zależy od projektanta strony, ale przynajmniej w nowym standardzie mamy sposób na mieszanie prezentacji z semantyką - jeśli tylko ktoś chce tak robić.

grov pisze...

Pomijając wyżej w komentarzach zalety pisania poprawnego kodu, 100% strict validacji dobrze świadczy o developerze.

target="_blank"

To użytkownik powinien decydować, czy strona ma się otworzyć w nowej karcie czy w tej samej.

Immortal pisze...

@grov: W takim razie przeglądarki mogłyby umożliwiać użytkowniki taką konfigurację, która ignoruje atrybut target :]

koziołek pisze...

@Immortal, @grov, musicie jednak pamiętać o tym, że pierwotnie HTML miał wyglądać trochę inaczej. W wyniku różnych perturbacji związanych z tajemniczym zniknięciem wersji HTML 1.0 (ponieważ był sobie HTML Tags i HTML+) w pierwszej oficjalnej wersji standardu (2.0). Pojawiło się wiele niespodzianek. Jednak najważniejszą cechą języka w tamtej wersji był brak opisu wyglądu, a opisywano tylko zawartość dokumentu.
Należy też wziąć pod uwagę, że była to pierwsza połowa lat 90-tych i komputery nie za bardzo były by wstanie poradzić sobie z np. parsowaniem CSS. Sam CSS jest wynikiem prób opanowania zmian w kolejnych HTML, które były wynikiem zapotrzebowania na ożywienie wyglądu strony.
W specyfikacji jest zatem wiele pozostałości.

Co do konfigurowania opcji przez użytkownika to w FF about:config i flagi browser.tabs.*. W IE nie wiem, bo nie używam.

rafek pisze...

@Krzysiek: To jakie DOCTYPE ustawić, żeby wszystkie przeglądarki (nowoczesne) wyświetlały kod tak samo? Bardzo często mam problem pomiędzy Firefoxem 3.x a Operą 9.x.

Tomasz Kowalczyk pisze...

Dokładnie, "wystarczy doctype ustawić" - wolne żarty i pobożne życzenia. Zawsze jest problem chociażby z IE, vide komentarze warunkowe, żeby to jakoś ogarnąć. A pomiędzy "normalnymi" przeglądarkami może i wielkich różnic nie ma, ale strony nie zawsze wyświetlają się identycznie.

Krzysiek pisze...

@rafek: wybierz sobie:

http://hsivonen.iki.fi/doctype/

@Tomek: poczytaj sobie na powyższej stronie o Quriks Mode i Standard Mode. Dowiedz się czym się różnią, to nie będziesz miał tyle problemów.

Faktycznie są czasem jakieś problemy z wyświetlaniem, głównie dotyczą IE (w praktyce wystarczy spróbować nadać szerokość elementowi (choćby i 100% i to załatwia większość problemów)).

A co do poprzednich komentarzy:

HTML jest od treści, CSS od wyglądu a użytkownik od klikania (czyli to ja powinienem decydować gdzie ma mi się zasób otworzyć, możę lubię wszystko otwierać w nowej zakładce a może nie). Jakby każdy stosował te zasady o ile czystszy i ładniejszy (pod względem kodu byłby Internet).

Prześlij komentarz

Related Posts with Thumbnails