Почему строгий анализ не был выбран для HTML?

38

Я часто задавался вопросом, почему строгий синтаксический анализ не был выбран при создании HTML. На протяжении большей части истории Интернета браузеры принимали любую разметку и старались изо всех сил ее анализировать. Этот процесс снижает производительность, позволяет людям писать бессмысленно и затрудняет отказ от устаревших функций.

Есть ли конкретная причина, по которой HTML не подвергается строгому анализу?

Shubham
источник
7
Возможно, вас заинтересует статья Джоэлса « Марсианские наушники» . Особо следует отметить RFC 793: принцип надежности , в котором прямо говорится, что реализации TCP должны стараться изо всех сил анализировать мусор. Этот принцип с тех пор был применен к браузерам.
Брайан
25
@ Брайан: Надежность означает, что вы не должны упасть, когда вы получаете дерьмо. Это не значит, что вы должны разобраться в этом дерьме.
Марьян Венема
2
XHTML использует строгий анализ.
user16764
3
Это только я, или ни один из этих ответов не очень удовлетворяет?
gsingh2011
2
@ gsingh2011 Ни один из ответов не удовлетворителен, но мой ответ - это правда. Некоторые из нас были активны в сети давно :-) Но да, это удивительно, сколько мусора у нас осталось по таким простым причинам.
Росс Паттерсон

Ответы:

39

Причина проста: во времена первых графических браузеров, NCSA Mosiac и позже Netscape Navigator, почти весь HTML был написан от руки. Авторы браузера (Netscape был создан бывшими людьми из Mosaic) быстро осознали, что отказ от рендеринга некорректного HTML будет против них пользователями, и вуаля!

Росс Паттерсон
источник
7
+1 да, так все и началось, в vi или блокноте. С большинством страниц, скопированных из плохого примера кода, это никогда не поправлялось. Плюс WWW быстро развивался, поэтому любой, кто мог печатать, становился веб-разработчиком, и все решалось быстро.
JQA
1
По-видимому, этот ответ в сочетании с комментарием @ Юкки дают наилучшее возможное объяснение
Шубхам
35

Потому что делать правильные предположения - это правильно, с точки зрения производителя браузера. Рассмотрим ситуацию: в идеале HTML-код, который вы получаете, является полностью правильным и точным. Замечательно. Но интересная часть - это то, что происходит, когда HTML не верен; поскольку мы имеем дело с информацией из источника, на который мы не имеем никакого влияния, на самом деле, мы должны быть готовы к этому. Теперь, когда это произойдет, что мы можем сделать? У нас есть два варианта: а) потерпеть неудачу и б) приложить максимальные усилия для восстановления после ошибки. Если мы терпим неудачу, у пользователя не остается ничего, кроме бесполезного сообщения об ошибке, и он ничего не может с этим поделать, потому что он не контролирует сервер. Если мы приложим максимум усилий, у пользователя будет по крайней мере то, что мы могли бы сделать со страницей, и часто предположение в основном верно.

Единственная реальная проблема с этим - когда вам нужны сообщения об ошибках, которые обычно находятся в ситуации разработки - вы хотите убедиться, что сгенерированный вами HTML-код правильный, а поскольку «работает в браузере X» не эквивалентно «правильному», мы не можем просто запустить его через браузер и посмотреть, работает ли он: мы не можем определить разницу между правильным HTML и неправильным HTML, который браузер исправил для вас. Это решаемая проблема, хотя; есть плагины для браузеров, которые сообщают о нарушениях стандартов, есть валидатор W3C и множество других подобных инструментов.

tdammers
источник
7
Ну, я не думаю, что кто-то будет обслуживать HTML, который выдает ошибки. Почему вы думаете, что компилятор, предполагающий, что код отличается от браузера, предполагающего HTML?
Шубхам
1
Я согласен с Шубхамом здесь - «поскольку мы имеем дело с информацией из источника, на который мы не имеем никакого влияния», ложно, влияние косвенное, но некоторые веб-сайты все еще поддерживают IE6 из-за этого влияния.
Steve314
2
@Shubham: компилятор отличается тем, что его целью является не преобразование машиночитаемого исходного кода в удобоваримую форму, а преобразование читаемого человеком исходного кода в нечто, более удобное для компьютера (машинный код или некоторый промежуточный код) формат). С помощью компилятора вы исправляете ввод и радуетесь, что код не попал в производство. С помощью браузера вы проклинаете создателя браузера или автора веб-сайта, но в любом случае вы не видите страницу.
tdammers
2
@Shubham: Обычно пользователь компилятора будет иметь контроль над компилируемым исходным кодом. Как правило, это не относится к веб-страницам.
суперкат
17

Авторы HTML и инструменты авторинга создают дрянную разметку. Браузеры прилагают все усилия для этого по конкурентным причинам: браузеры, которые не в состоянии отобразить большинство веб-страниц любым приемлемым способом, будут отклонены пользователями, которым наплевать, чья это вина.

Это довольно отличается от того, что делают реализации языка программирования. Компиляторы и интерпретаторы работают над кодом, который может быть написан программистом, тогда как каждый и его брат могут писать HTML с минимальным обучением или без него. В некотором смысле HTML-разметка - это код, но это данные, а не инструкции языка программирования, и (хорошая) традиция в программном обеспечении - быть терпимым к данным.

XHTML в принципе налагает строгие правила синтаксического анализа (XML), так что документ XHTML, обслуживаемый с типом содержимого XML, будет отображаться только в том случае, если он правильно сформирован в смысле XML - в противном случае пользователю сообщается только первая ошибка. Это никогда не становилось популярным в веб-дизайне - почти весь «XHTML» вокруг представлен как text / html и обрабатывается как традиционный суп с тегами очень либеральным способом, только с некоторыми новыми эксцентричностями.

Юкка К. Корпела
источник
15
HTML authors and authoring tools produce crappy markup.- они делают, потому что браузеры принимают это. Если бы с самого начала браузеры не приняли его - тогда эти инструменты и авторы не смогли бы сойти с рук в создании дрянной разметки
user93353
3
@GrandmasterB - Я думаю, вы упустили момент - даже там, где был только один браузер на рынке - он не выполнял строгий анализ.
user93353
3
Забавное примечание: вы говорите, что если браузер не сможет проанализировать недействительный сайт, он потеряет долю рынка. Но просто посмотрите на то, что: как бы плохо это ни было, оно не теряет долю рынка. Это просто вынуждает бедных разработчиков писать грязные хаки с использованием старых API ... И не заставляйте меня начинать с этой схемы управления версиями ...
Макс
3
В начале браузеры были написаны на скорую руку, чтобы иметь дело с языком разметки, который не был завершен и не имел официальной спецификации - не было строгих правил синтаксического анализа. (HTML 2.0, в 1995 году, был номинально основан на SGML, но было уже слишком поздно, чтобы это на самом деле реализовывалось.)
Юкка К. Корпела
2
IE фактически потерял довольно большую долю рынка. Но это, вероятно, имеет мало общего со строгим анализом. IE со своими странностями управлял вебом достаточно долго, чтобы заставить другие браузеры в значительной степени имитировать его странности, потому что в противном случае многие страницы развалились бы.
Юкка К. Корпела
9

Суть в том, что HTML основан на другом языке без гиперссылок, называемом SGML, который часто используется для документации и руководств и тому подобного.

Из статьи об истории HTML:

Тим упомянул, что некоторые из ранних документов HTML были основаны на старом языке SGML, который CERN уже использовал: - Мы включили в HTML некоторые теги из набора тегов SGML, которые использовались и когда-то поддерживаются в CERN [...] Анализатор HTML будет игнорировать теги, которые он не понимает, и игнорирует атрибуты, которые он не понимает в тегах CERN-SGML .

[...] большинство ранних HTML-тегов были взяты из языка CERN SGMLGuid, который сам был вариантом AAP (раннего языка SGML). Например, title, hn, p, ol и так далее, по-видимому, взяты из этого языка. Единственным радикальным изменением было добавление всей важной ссылки anchor (), без которой WWW не взлетела бы.

Принимая во внимание часть, которую я выделил, в основном они реализовали подмножество тегов, доступных в системе SGML, с которой они были знакомы, добавили новый тег привязки <a> и решили игнорировать любой из многих тегов, которые они не делали ' не заботиться или не желать поддерживать по какой-либо причине (например, теги для библиографических списков, xmp для «примера», тег «box» для рисования рамки вокруг блока текста и т. д.). Таким образом, самый простой способ сделать это - простить разметку, которая не известна синтаксическому анализатору, и игнорировать неизвестную разметку как можно лучше, независимо от того, является ли причина введенной пользователем неверной разметкой, или самый быстрый и простой способ преобразовать существующие документы в Этот новый формат HTML предназначен для добавления гиперссылок к существующим документам SGML и игнорирования любых тегов, которые не поддерживаются или не применяются.

Джессика Браун
источник
HTML-синтаксис действительно был основан на эталонном синтаксисе SGML для формы разметки. Но в самом SGML не было элементов для разметки документов, которые HTML мог заимствовать. Набор элементов HTML фактически напоминает набор языков разметки документов GML от IBM , транслитерированный в RCS SGML.
Росс Паттерсон
5

Это частично исторический пережиток браузерной войны

IE и netscape конкурировали, чтобы захватить рынок, и продолжали выпускать новые функции, которые становились все более и более «крутыми», и были вынуждены принимать страницы, предназначенные для другого браузера.

Это означает, что браузер принимает и игнорирует неизвестные теги молча, после того, как комитеты начали вовлекаться ... ну, у вас есть комитет, разрабатывающий материал, и в результате множество разных версий (с некоторыми неоднозначно сформулированными спецификациями), где браузер хочет поддерживать большинство их, и создание отдельного парсера для каждой версии было бы огромным явлением. Так что (относительно) проще использовать один парсер с разными режимами.

С другой стороны, netscape и IE хотели, чтобы html был доступен для обычного человека (как это было в те времена), что означает попытку сделать то, что хотел сделать пользователь, вместо того, что он сказал, и отключить все висячие теги.

Проблема усугубляется тем, что есть также несколько «обучающих» сайтов, которые учат неправильному и думают, что они правы, потому что то, чему они учат, работает.

В конечном итоге это означает, что если вы сейчас создадите браузер с только строгим html-анализом, 99% сайтов там просто не будут работать.

чокнутый урод
источник
6
Даже до того, как IE появился на рынке, Netscape никогда не выполнял строгий анализ. Я помню Netscape с начала 1997 года.
user93353
Даже если бы существовали четкие стандарты, браузеру было бы трудно различать теги, которые были законно определены после выпуска браузера, и теги, которые никогда не были и никогда не будут законными. Если «необязательные» теги, которые улучшают документ, но не требуются для его семантической корректности, включают номер версии стандарта, который их реализовал, то браузер, который реализовал версию 23 стандарта, мог бы молча игнорировать <o24wowzo>тег, но отказываться от него <o23wowzo>, но такой дизайн нарушил бы «читабельный» аспект HTML.
суперкат
2

Ну, мы пытались создать хороший строгий вариант в тысячах, но он не удался, потому что люди, слепо следовавшие «лучшим практикам», обвиняли браузеры, когда их неправильная разметка разваливалась на части в строгом режиме. И поставщики браузеров не любят, когда их обвиняют.

Они утверждали, что это потому, что они хотели, чтобы Интернет был более доступным для непрофессионалов, но никто не был остановлен от использования HTML 4 в его самой снисходительной форме.

Тем не менее, вы все равно можете использовать HTML5 в качестве XML, если хотите использовать строгий макет. IMO, это может быть хорошим способом пожинать плоды работы макета или пользовательского интерфейса в более строгом режиме, прежде чем передать его другим людям, которые могут или не могут хотеть его как строгого, без каких-либо реальных рисков (запретив им вырывать доктрину, потому что они на самом деле предпочитают режим причуд - в 2017 году (время этого редактирования) их следует снимать. Так что это все еще там в основном, но проведите некоторое исследование. Я, кажется, вспоминаю некоторые предостережения, которых у нас не было с XHTML, которые не сделали действительно влияют на работу с версткой. Просто не распространяйте слово, что это «единственный способ сделать это правильно», или твики, купившиеся на такого рода разговоры, будут напрасно выдвигать идею, обвинять браузеры снова, и они возьмут зубы из единственной строгой альтернативы, которую мы оставили. (2017 редактировать:

http://mathiasbynens.be/notes/xhtml5

Эрик Реппен
источник