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

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

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

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

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

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

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

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

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

Суть в том, что 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 и игнорирования любых тегов, которые не поддерживаются или не применяются.

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

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

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

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

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

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

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

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

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

http://mathiasbynens.be/notes/xhtml5