Dlaczego nie wybrano ścisłego analizowania HTML?

Często zastanawiałem się, dlaczego podczas tworzenia HTML nie wybrano ścisłego analizowania. Przez większość historii Internetu przeglądarki zaakceptowały każdy rodzaj znaczników i starały się je przeanalizować. Proces ten obniża wydajność, umożliwia pisanie bełkotów i utrudnia zaprzestanie przestarzałych funkcji.

Czy istnieje konkretny powód, dla którego HTML nie jest ściśle analizowany?

Powód jest prosty: w czasie pierwszych przeglądarek graficznych, NCSA Mosiac, a później Netscape Navigator, prawie cały HTML został napisany ręcznie. Autorzy przeglądarki (Netscape został zbudowany przez byłych ludzi z Mozaiki) szybko zauważyli, że odmowa renderowania niepoprawnego HTML zostanie im zarzucona przez użytkowników i voila!

Ponieważ właściwe odgadywanie jest właściwe, z perspektywy twórcy przeglądarki. Rozważ sytuację: najlepiej, jeśli otrzymany kod HTML jest całkowicie poprawny i zgodny ze specyfikacją. To wspaniale. Ale ciekawe jest to, co się dzieje, gdy HTML jest nie zgodne z prawdą; skoro mamy do czynienia z danymi wejściowymi ze źródła, na które nie mamy wpływu, naprawdę musimy się na to przygotować. Kiedy to się stanie, co możemy zrobić? Mamy dwie opcje: a) nieudane i b) dokładamy wszelkich starań, aby naprawić błąd. Jeśli nam się nie powiedzie, użytkownik ma tylko bezużyteczny komunikat o błędzie i nic nie może na to poradzić, ponieważ nie kontroluje serwera. Jeśli dołożymy wszelkich starań, użytkownik ma przynajmniej tyle, ile możemy zrobić ze strony, i często zgadywanie jest w większości słuszne.

Jedynym prawdziwym problemem jest to, że potrzebujesz komunikatów o błędach, co zwykle ma miejsce w fazie programowania - chcesz się upewnić, że generowany kod HTML jest poprawny, a ponieważ „działa w przeglądarce X” nie jest równoważne z „poprawnym”, nie możemy po prostu uruchomić go za pomocą przeglądarki i sprawdzić, czy to działa: nie możemy odróżnić poprawnego kodu HTML od niepoprawnego kodu HTML, który przeglądarka dla Ciebie naprawiła. Jest to jednak problem do rozwiązania; istnieją wtyczki do przeglądarek, które zgłaszają naruszenia standardów, weryfikator W3C i wiele innych podobnych narzędzi.

Autorzy HTML i narzędzia autorskie tworzą marne znaczniki. Przeglądarki robią to, co w ich mocy, ze względów konkurencyjnych: przeglądarki, które nie renderują większości stron internetowych w jakikolwiek rozsądny sposób, zostaną odrzucone przez użytkowników, którzy nie będą obchodzić się, czyja to wina.

Raczej różni się od tego, co robią implementacje języka programowania. Kompilatory i interpretatory pracują na kodzie, który programista może założyć, podczas gdy każdy i jego brat mogą pisać HTML przy minimalnym przeszkoleniu lub bez niego. Znaczniki HTML to w pewnym sensie kod, ale są to dane, a nie instrukcje języka programowania, a (dobrą) tradycją oprogramowania jest tolerowanie danych.

XHTML w zasadzie narzuca ścisłe reguły analizowania (XML), dzięki czemu dokument XHTML obsługiwany z typem treści XML będzie wyświetlany tylko wtedy, gdy jest dobrze sformatowany w sensie XML - w przeciwnym razie tylko pierwszy błąd zostanie przekazany użytkownikowi. To nigdy nie stało się popularne przy tworzeniu stron internetowych - prawie cały „XHTML” jest podawany jako text / html i przetwarzany jako tradycyjna zupa tagowa w bardzo liberalny sposób, z pewnymi nowymi dziwactwami.

Krótko mówiąc, HTML byłby oparty na innym, nie hiperłączonym języku znaczników o nazwie SGML, często używanym do dokumentacji i podręczników itp.

Z artykułu o historii HTML:

Tim wspomniał, że niektóre wczesne dokumenty HTML były oparte na starym języku SGML, którego już używał CERN: - Zawarliśmy w HTML niektóre tagi z zestawu znaczników SGML używanych i obsługiwanych w CERN [...] Parser HTML zignoruje tagi, których nie rozumie i zignoruje atrybuty, których nie rozumie z tagów CERN-SGML .

[...] większość wczesnych tagów HTML została faktycznie zaczerpnięta z języka CERN SGMLGuid, który sam był odmianą AAP (wczesnego języka SGML). Na przykład tytuł, hn, p, ol itd. Najwyraźniej pochodzą z tego języka. Jedyną radykalną zmianą było dodanie ważnego linku anchor (), bez którego WWW nie wystartowałoby.

Biorąc pod uwagę część, którą pogrubiłem, w zasadzie zaimplementowali podzbiór tagów dostępnych w znanym im systemie SGML, dodając nowy tag anchor <a> i wybierając ignorowanie któregokolwiek z wielu tagów, których nie zrobili t dba o lub chce wspierać z przyczyn wahtever (takich jak znaczniki do list bibliograficznych, znaczniki xmp dla „przykład”, znacznik „pole”, aby narysować pole wokół bloku tekstu itp.). Najprostszym sposobem na to jest wybaczenie znaczników, które nie są rozpoznawane przez analizator składni i ignorowanie nieznanych znaczników najlepiej, jak to możliwe, niezależnie od tego, czy przyczyną jest zły znacznik wpisany przez użytkownika, czy najszybszy najprostszy sposób na konwersję istniejących dokumentów na ten nowy format HTML ma dodawać hiperłącza do istniejących dokumentów SGML i ignorować wszelkie tagi, które nie są obsługiwane lub implementowane.

Jest to częściowo historyczny ślad wojny przeglądarkowej

IE i netscape rywalizowały o przejęcie rynku i wciąż wypuszczały nowe funkcje, które stawały się coraz bardziej „niesamowite” i zmuszone były akceptować strony zaprojektowane dla drugiej przeglądarki.

Oznacza to, że przeglądarka po cichu akceptuje i ignoruje nieznane tagi, po tym jak komitety zaczęły się angażować ... cóż, masz komitet projektujący rzeczy, w wyniku czego powstało wiele różnych wersji (z niejednoznacznie sformułowanymi specyfikacjami), w których przeglądarka chce obsługiwać większość i utworzenie osobnego parsera dla każdej wersji byłoby ogromnym rozszerzeniem. Dlatego (względnie) łatwiej jest używać jednego parsera z różnymi trybami.

Z drugiej strony netscape i IE chcieli, aby html był dostępny dla zwykłego człowieka (co było modą w tamtych czasach), co oznacza próbę zrobienia tego, co użytkownik chciał zrobić zamiast tego, co powiedział, i potknięcia się o każdy wiszący tag.

Problem pogarsza to, że istnieje również kilka stron z samouczkami, które uczą niewłaściwej rzeczy i myślą, że mają rację, ponieważ to, czego uczą, działa.

W ostatecznym rozrachunku oznacza to, że jeśli teraz utworzysz przeglądarkę z dokładnym analizowaniem html 99% witryn nie będzie działać.

Cóż, próbowaliśmy ustanowić fajną ścisłą opcję w tysiącleciach, ale nie udało się to, ponieważ ludzie ślepo przestrzegali „najlepszych praktyk”, obwiniali przeglądarki, gdy ich nieprawidłowe znaczniki rozpadły się na części w trybie ścisłym. A dostawcy przeglądarki nie lubili obwiniać.

Twierdzili, że było tak, ponieważ chcieli, aby sieć była bardziej dostępna dla nieprofesjonalistów, ale nikt nie powstrzymywał się przed używaniem HTML 4 w najbardziej łagodnej formie.

To powiedziawszy, możesz nadal obsługiwać HTML5 jako XML, jeśli chcesz mieć układ w ścisłym stylu. IMO może być dobrym sposobem na czerpanie korzyści z tworzenia układu lub pracy interfejsu użytkownika w bardziej rygorystycznym trybie, zanim przekażesz go innym osobom, które mogą chcieć lub nie być tak surowe bez żadnego rzeczywistego ryzyka (uniemożliwiając im wyrywanie dokumentu, ponieważ tak naprawdę faworyzują tryb dziwactw - w 2017 r. (czas tej edycji) powinni zostać zastrzeleni. Więc nadal tam jest, ale przeprowadzam badania. Wydaje mi się, że istnieją pewne zastrzeżenia, których nie mieliśmy z XHTML, które nie naprawdę wpływa na pracę nad układem. Po prostu nie rozpowszechniaj słowa, że ​​jest to „jedyny sposób, aby zrobić to dobrze”, albo twits, którzy kupią tego rodzaju rozmowy, będą dogmatować pomysł, ponownie obwinią przeglądarki i zabiorą zęby z jedynej surowej alternatywy, którą pozostawiliśmy. (edycja 2017:

http://mathiasbynens.be/notes/xhtml5