Dlaczego nie wybrano ścisłego analizowania HTML?

38

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?

Shubham
źródło
7
Być może znajdziesz artykuł Joelsa, Martian Headsets . Na szczególną uwagę zasługuje także RFC 793: Zasada niezawodności , która wyraźnie stwierdza, że ​​implementacje TCP powinny starać się parsować śmieci. Odtąd ta zasada została zastosowana w przeglądarkach.
Brian,
25
@Brian: Wytrzymałość oznacza, że ​​nie powinieneś przewracać się, gdy otrzymujesz bzdury. To nie znaczy, że musisz mieć bzdury.
Marjan Venema
2
XHTML używa ścisłej analizy.
user16764,
3
Czy to tylko ja, czy żadna z tych odpowiedzi nie jest zbyt satysfakcjonująca?
gsingh2011
2
@ gsingh2011 Żadna z odpowiedzi nie jest satysfakcjonująca, ale moja odpowiedź jest prawdą. Niektórzy z nas tutaj już dawno działali w sieci :-) Ale tak, to zadziwiające, ile śmieci pozostało z tak prostych powodów.
Ross Patterson

Odpowiedzi:

39

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!

Ross Patterson
źródło
7
+1 tak, tak to się wszystko zaczęło, w vi lub notatniku. Ponieważ większość stron jest kopiowana ze złego przykładowego kodu, nigdy nie było lepiej. Plus WWW rozkwitło, więc każdy, kto potrafił pisać, został programistą i chodziło o to, aby szybko załatwić sprawę.
jqa
1
Najwyraźniej ta odpowiedź w połączeniu z komentarzem @ Jukki daje najlepsze możliwe wyjaśnienie
Shubham,
35

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.

tdammers
źródło
7
Cóż, nie sądzę, żeby ktokolwiek podawał HTML, który wyrzuca błędy. Dlaczego według ciebie kompilator zakładający kod różni się od przeglądarki z założeniem HTML.
Shubham,
1
Zgadzam się z Shubhamem tutaj - „ponieważ mamy do czynienia z danymi wejściowymi ze źródła, na które nie mamy wpływu”, jest fałszywy, wpływ jest pośredni, ale niektóre strony internetowe nadal obsługują IE6 z tego powodu.
Steve314
2
@Shubham: Kompilator jest inny, ponieważ jego celem nie jest przekształcenie kodu źródłowego odczytywalnego maszynowo w czytelną dla człowieka formę, ale przekształcenie kodu źródłowego odczytywalnego przez człowieka w coś wygodniejszego dla komputera (kod maszynowy lub jakiś pośredni format). Dzięki kompilatorowi naprawiasz dane wejściowe i cieszysz się, że kod nie wszedł do produkcji. Za pomocą przeglądarki przeklinasz twórcę przeglądarki lub autora strony, ale tak czy inaczej, nie zobaczysz strony.
tdammers
2
@Shubham: Zasadniczo użytkownik kompilatora będzie miał kontrolę nad kompilowanym kodem źródłowym. Zasadniczo tak nie jest w przypadku stron internetowych.
supercat
17

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.

Jukka K. Korpela
źródło
15
HTML authors and authoring tools produce crappy markup.- robią to, ponieważ przeglądarki to akceptują. Gdyby od początku przeglądarki tego nie akceptowały - te narzędzia i autorzy nie byliby w stanie uciec od
marnych znaczeń
3
@GrandmasterB - myślę, że nie rozumiesz sensu - Nawet jeśli na rynku była tylko jedna przeglądarka - nie przeprowadzała ścisłej analizy.
user93353
3
Zabawna uwaga: mówisz, że jeśli przeglądarka nie będzie mogła przeanalizować nieprawidłowej witryny, straci udział w rynku. Ale spójrz tylko na: jakkolwiek jest źle, nie traci on udziału w rynku. Zmusza to tylko biednych programistów do pisania brudnych hacków przy użyciu starych interfejsów API ... I nie zaczynaj od schematu wersji ...
Max
3
Na początku przeglądarki pisano w pośpiechu, aby radzić sobie z językiem znaczników, który nie został sfinalizowany i nie miał oficjalnej specyfikacji - nie było ścisłych reguł analizy. (HTML 2.0, w 1995 r., Był nominalnie oparty na SGML, ale było już za późno, aby go faktycznie wdrożyć.)
Jukka K. Korpela,
2
IE faktycznie straciło sporo ze swojego udziału w rynku. Ale prawdopodobnie nie ma to nic wspólnego z dokładnym analizowaniem. IE, ze swoimi osobliwościami, rządził siecią wystarczająco długo, aby zmusić inne przeglądarki w dużej mierze naśladować jej osobliwości, ponieważ w przeciwnym razie wiele stron rozpadłoby się.
Jukka K. Korpela,
9

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.

Jessica Brown
źródło
Składnia HTML była rzeczywiście oparta na konkretnej składni referencyjnej SGML pod względem formy znaczników. Ale sam SGML nie miał elementów do oznaczania dokumentów, które HTML mógłby pożyczyć, zestaw elementów HTML faktycznie przypomina język znaczników dokumentów GML IBM , transliterowany na SGML RCS.
Ross Patterson
5

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ć.

maniak zapadkowy
źródło
6
Nawet zanim IE pojawiło się na rynku, Netscape nigdy nie przeprowadzał ścisłej analizy. Pamiętam Netscape z początku 1997 roku.
user93353
Nawet gdyby istniały jasne standardy, przeglądarka miałaby trudności z rozróżnieniem między tagami, które zostały prawnie zdefiniowane po jej wydaniu, a tagami, które nigdy nie były i nigdy nie byłyby zgodne z prawem. Jeśli „opcjonalne” znaczniki, które ulepszyły dokument, ale nie były wymagane ze względu na jego poprawność semantyczną, zawierały numer wersji standardu, który je zaimplementował, to przeglądarka, która zaimplementowała wersję 23 standardu, może po cichu zignorować <o24wowzo>znacznik <o23wowzo>, ale nie może projekt osłabiłby aspekt HTML „czytelny dla człowieka”.
supercat
2

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

Erik Reppen
źródło