Sprawdzanie poprawności HTML: czy warto?

Jakie są zalety i wady (jeśli w ogóle) upewnienia się, że wszystkie strony sprawdzają poprawność w porównaniu z niepoprawnym kodem HTML, który jednak działa na wszystkich głównych przeglądarkach?

Czy posiadanie prawidłowego kodu HTML po uruchomieniu Javascript jest równie ważne?

Myślę, że zdecydowanie warto to zrobić , ale nigdy nie powinieneś być niewolnikiem walidacji - to głupia gra.

http://www.codinghorror.com/blog/2009/03/html-validation-does-it-matter.html

1. Sprawdź poprawność kodu HTML. Dowiedz się, co to znaczy mieć prawidłowy znacznik HTML. Zrozum oprzyrządowanie. Więcej informacji jest zawsze lepsze niż mniej informacji. Dlaczego warto latać w ciemno?

2. Nikt nie dba o to, czy Twój HTML jest prawidłowy. Oprócz Ciebie. Jeśli chcesz. Nie zastanawiaj się przez chwilę, że tworzenie doskonale poprawnego HTML-a jest ważniejsze niż prowadzenie witryny, oferowanie funkcji, które zachwycają użytkowników lub wykonywanie pracy.

Uważam prawidłowy HTML za wartościowy cel, ale nie widzę go jako całościowego budowania dobrych stron internetowych.

Sztuczka polega na tym, że twoje znaczniki mogą być całkowicie poprawne, ale mogą nie być semantyczne - np. Używając tabel do układu lub nawigacji. Istnieje różnica między poprawnym kodem a kodem semantycznym.

Z drugiej strony, jeśli korzystasz ze skryptów reklamowych lub zewnętrznych, mogą wstawić własne znaczniki, które mają szansę naprawdę zepsuć własne.

Myślę, że warto, ponieważ próbowałem zweryfikować wiele błędów znaczników i błędów logicznych. Jest to jedna z tych „niezbędnych, ale niewystarczających” rzeczy. Prawidłowe znaczniki, takie jak kod, który kompiluje (lub pobiera za pośrednictwem JSlint) wolny od błędów, ostrzeżeń i wskazówek, jest dobrym pierwszym krokiem do poprawnego działania.

Dużym plusem prawidłowego HTML jest to, że twoja strona jest wtedy bardziej dostępna dla rzeczy innych niż „główne przeglądarki”. Wszystkie „główne przeglądarki” mają nieskończone obejścia, aby poradzić sobie z wszystkimi nieprawidłowymi śmieciami zaludniającymi WWW. Jednak trzymanie się prawidłowego kodu HTML pomaga, na przykład, jeśli ktoś używa przeglądarki dla osób niedowidzących lub uzyskuje dostęp do stron w trybie offline itp.

Walidacja sama w sobie nie jest tak krytyczna, ponieważ niewiele przeglądarek jest w 100% zgodnych, a specyfikacja nie jest w 100% jasna, jak interpretować reguły.

Jednak poprawny kod HTML pozwala lepiej dostosować i ulepszyć witrynę. Wraz ze zmianami standardów będą one zazwyczaj migrować do przodu, a jeśli nowa witryna jest ważna, aktualizacja do najnowszej wersji powinna być łatwiejsza.

Dół, będąc ważnym, ułatwia pozostanie na szczycie gry i być jak najbardziej kompatybilny z jak najszerszą publicznością.

Najlepszym rozwiązaniem jest sprawdzenie, który nieprawidłowy HTML jest zły, a który nieprawidłowy HTML nie ma znaczenia.

Na przykład zapomnienie o zamknięciu <div>tagu jest bardzo złe , ponieważ twój układ prawie na pewno zepsuje się w jednej lub kilku przeglądarkach.

Jednak używanie <br>zamiast <br />w XHTML nie ma znaczenia - wszystkie przeglądarki bez problemu interpretują oba jako podział wiersza. Użycie targetatrybutu w linkach jest nieprawidłowe, ale najgorszym scenariuszem jest to, że przeglądarka nie otwiera łącza w nowym oknie.

Podczas uruchamiania walidatora należy sprawdzić błędy, które daje, w poszczególnych przypadkach. Czy sprawdzanie poprawności jest ważne? Dla mnie tak, to bardzo ważne. Ale czy to wymóg? Nie.

Rzeczy takie jak wielokrotne używanie tego samego identyfikatora (zamiast klasy), umieszczanie elementów na poziomie bloku wewnątrz elementów na poziomie (zwykle te elementy również nie pasują semantycznie w ten sposób), brak atrybutów alt na obrazach (słaba dostępność dla osób z zaburzeniami ) są ważne. Rzeczy takie jak nieznane atrybuty tagów NIE są ważne. W ogóle. Frameworki JavaScript, takie jak Dojo lub ten okropny pasek mediów społecznościowych Meebo, używają niestandardowych atrybutów jako haczyków, a specyfikacja HTML stwierdza, że ​​są one dozwolone i że każdy nieznany atrybut należy zignorować. Walidator ich nie ignoruje, ale generuje błędy. Te błędy można zignorować.

Podczas sprawdzania poprawności nie należy zakładać, że jeśli masz błędy, robisz to źle. Semantyka jest znacznie ważniejsza i tak się składa, że ​​prawidłowy HTML jest często naturalnym wynikiem posiadania właściwej semantyki.

Jednym z powodów przetestowania witryny pod kątem prawidłowego kodu HTML jest to, że zapewnia ona, że ​​pająki wyszukiwarek będą mogły w pełni zaindeksować i ustalić znaczenie stron. Jeśli nie mogą tego zrobić z powodu źle sformułowanego kodu HTML (który może działać z głównych przeglądarek z przyczyn historycznych), potencjalnie ograniczasz swoje pozycje w wyszukiwarkach.

Pojawiły się również spekulacje, że podczas gdy główne wyszukiwarki dobrze radzą sobie ze źle sformatowanym HTML, mogą również przypisywać „punkty” jakości strony za poprawność, co dodatkowo wpływa na twoją pozycję w rankingu na tak wysoką, jak na to zasługuje.

Naprawdę nie sądzę, żeby to miało już znaczenie. Kiedyś byłem niewolnikiem walidacji, teraz rzadko go sprawdzam. Być może wypaliło mnie to, że upewniłem się, że moja strona jest ważna, a może już mnie to nie obchodziło, bo nikt inny tego nie zrobi. Mogę zagwarantować, że 99,9% naszych gości nawet nie wie, co to jest, a nawet obchodzi, czy to zrobili. Przyszłe oprogramowanie przeglądarki może, ale kiedy nadejdzie ten dzień, będę się tym martwić.

Sprawdzanie poprawności jest przydatne, ponieważ może pomóc w wykryciu trudnych do złapania błędów, takich jak

<input name=foo value=<?php echo htmlspecialchars($_GET['foo']); ?> />

lub nieprzewidywalne zachowanie przeglądarki (na przykład umieszczanie elementów blokowych aw przeglądarce Firefox może czasem psować się w brzydki sposób).

Nikt jeszcze nie wspomniał, że nieprawidłowy HTML może spowolnić renderowanie, podczas gdy przeglądarka stara się zrozumieć niestandardowy HTML podczas wyświetlania.

nie ma wady posiadania prawidłowego HTML. istnieje powód, dla którego istnieje specyfikacja i dlaczego włożono wiele wysiłku w specyfikację, aby określić, jak rzeczy powinny działać.

w zasadzie wszystko, co zyskujesz, to spełnić specyfikacje. co z kolei oznacza, że ​​programy napisane w celu odczytu html (przeglądarki, boty) nie mogą Cię winić za niespełnienie specyfikacji, jeśli coś pójdzie nie tak. a niektóre z tych programów dają dodatkowe punkty (wyższy ranking w wyszukiwarkach, jeśli bot zgłasza „spełnia specyfikację”). jeśli spełnisz specyfikację, zaskoczy Cię znacznie mniej, jeśli niektóre przeglądarki nie wyświetlają uszkodzonego HTML-a tak, jak myślisz.

więc spełnienie specyfikacji i napisanie prawidłowego kodu HTML jest dla ciebie dobre, bez żadnych wad.

Niektóre błędy sprawdzania poprawności HTML mogą powodować nieoczywiste problemy z układem (np. Niepoprawnie zagnieżdżone / niezamknięte tagi), błędy JavaScript (np. Użycie idwięcej niż raz) i problemy dla niektórych użytkowników (np. Nie zawierające znaczącego lub pustego altatrybutu na obrazach).

Jeśli wszystkie nasze strony się sprawdzą, jest to miły automatyczny sprawdzian, który możesz zrobić, aby wykluczyć źródła błędów. Jeśli pozostawisz kilka błędów sprawdzania poprawności, ponieważ wiesz, że nie powodują one żadnych szkód, czek nie jest już zautomatyzowany: musisz spojrzeć na każdy błąd i pamiętać, że jest w porządku. Osobiście wolę, gdy komputery zmniejszają ilość pracy, którą muszę wykonać, niż ją zwiększać.

Jedną z kwestii, o których nikt nie wspomniał, są przyszłe zmiany przeglądarki. Chociaż wszystkie dzisiejsze przeglądarki stosunkowo dobrze radzą sobie z nieprawidłowymi znacznikami, nie zawsze tak jest.

Twórcy przeglądarek będą w przyszłości dbać o to, by ich przeglądarki działały zgodnie ze standardami HTML / XHTML, dlatego też twórcy stron internetowych powinni to robić. Tylko dlatego, że określony fragment nieprawidłowych znaczników działa teraz, nie gwarantuje, że będzie działać w przyszłych przeglądarkach.

Ważność pomaga uniknąć niezgodności i pomaga w utrzymywaniu kodu. Przeglądarki odzyskują po błędach znaczników, ale czasami w bardzo nieintuicyjny sposób.

• Oparte na DTD (HTML4, XHTML1 @ W3C) - może nie być tego warte. DTD jest prymitywne i np. Nie może sprawdzić poprawności większości atrybutów. W większości przypadków trudno będzie zrozumieć błędy dotyczące elementów i zagnieżdżania.

• Walidator HTML5 - Tak . Zdecydowanie. HTML5 jest bardziej pragmatyczny i dopuszcza pewne nieszkodliwe konstrukcje, które kiedyś były błędami. Walidator OTOH Henri jest znacznie dokładniejszy i lepiej odkrywa prawdziwe problemy.

Ważność kodu generowanego przez JS może mieć znaczenie, ponieważ przeglądarki działają w DOM, niezależnie od tego, jak został stworzony. Jeśli używasz document.write(), musisz nawet zadbać o poprawną składnię (przechodzi przez ten sam parser co źródło strony).

Nawet jeśli Twój HTML działa we wszystkich głównych przeglądarkach, nadal warto go robić, ponieważ czasami może powodować problemy z robotami wyszukiwarek, takimi jak googlebot. Na przykład zobacz to:

http://www.codeproject.com/KB/server-management/Google_Indexing_Problem.aspx

Google i Bing nie używają, nie będą i nigdy nie będą używać walidacji CSS ani HTML jako czynnika rankingowego.

Większość stron ma dziesiątki do setek błędów i nie musisz się o nie martwić, ponieważ wszystkie wyszukiwarki dbają o to, jak strona się wyświetla. Po prostu upewnij się, że Twoja strona wyświetla się poprawnie we wszystkich głównych przeglądarkach i Google Fetch .