Чому для HTML не було обрано суворий аналіз?

Я часто замислювався, чому при створенні HTML не було обрано суворого аналізу. Більшу частину історії Інтернету браузери приймали будь-яку розмітку та намагалися її проаналізувати. Процес погіршує продуктивність, дозволяє людям писати безглуздість і ускладнює припинення застарілих функцій.

Чи є конкретна причина, чому HTML не є чітко проаналізованим?

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

Оскільки робити найкращі здогадки - це правильно, з точки зору виробника браузера. Розгляньте ситуацію: в ідеалі HTML, який ви отримуєте, є абсолютно правильним та специфічним. Це чудово. Але найцікавіше те , що відбувається , коли HTML є НЕ правильно; оскільки ми маємо справу з джерелом джерела, на який ми не маємо впливу, насправді, ми повинні бути готові до цього. Тепер, коли це відбувається, що ми могли зробити? У нас є два варіанти: а) невдача та б) докласти максимум зусиль для відновлення помилки. Якщо ми не вдається, користувачеві не залишається нічого, крім марного повідомлення про помилку, і вони нічого з цим не можуть зробити, оскільки вони не контролюють сервер. Якщо ми докладемо максимум зусиль, користувач має принаймні те, що ми могли б зробити на сторінці, і часто здогадки здебільшого вірні.

Єдина реальна проблема з цим полягає в тому, що вам потрібні повідомлення про помилки, які зазвичай знаходяться в ситуації розробки - ви хочете переконатися, що створений вами HTML правильний, а оскільки "працює в браузері X", не є рівнозначним "правильним", ми не можемо просто запустити його через браузер і перевірити, чи працює він: ми не можемо визначити різницю між правильним HTML і неправильним HTML, який браузер встановив для вас. Це все ж вирішувана проблема; є плагіни браузера, які повідомляють про порушення стандартів, є валідатор W3C та багато інших подібних інструментів.

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

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

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

Коротше кажучи, це те, що HTML базувався на іншій мові розмітки без гіперпосилання під назвою SGML, яка часто використовується для документації та посібників тощо.

Зі статті про історію HTML:

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

[...] більшість ранніх тегів HTML були фактично взяті з мови CERN SGMLGuid, яка сама була варіантом AAP (ранньої мови SGML). Наприклад, назва, hn, p, ol і так далі, очевидно, взяті з цієї мови. Єдиною радикальною зміною було додавання всіх важливих посилань () якоря (), без яких WWW не злітала б.

Враховуючи частину, яку я виділив жирним шрифтом, в основному вони реалізували підмножину тегів, наявних у системі SGML, з якою вони були знайомі, додавши новий тег <a> тега і вирішили ігнорувати будь-який із багатьох тегів, які вони зробили '. t не хвилюється або бажає підтримати з причини wahtever (наприклад, теги для списків бібліографії, xmp для "example", "box" тег, щоб намалювати поле навколо блоку тексту тощо). Тож найпростіший спосіб зробити це - пробачити розмітку, яка не відома аналізатором, і ігнорувати невідому розмітку якнайкраще, незалежно від того, причиною є неправильна розмітка користувача або найшвидший спосіб перетворення існуючих документів у цей новий формат HTML - додавати деякі посилання на існуючі документи SGML та ігнорувати те, що теги не підтримуються та не реалізуються.

Частково це історичний залишок війни в браузері

IE і netscape змагалися за те, щоб зайняти ринок і продовжували випускати нові функції, які ставали все більш "приголомшливими", і змушували приймати сторінки, призначені для іншого браузера.

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

З іншого боку, netscape та IE хотіли, щоб html був доступний для простої людини (як це було примхами тих днів), що означає намагатися робити те, що користувач хотів зробити, а не те, що він сказав зробити, і перемикатися на кожен звисаючий тег.

Погіршення проблеми полягає в тому, що є також кілька сайтів "підручника", які викладають неправильну річ і думають, що вони праві, тому що те, що вони навчають, працює.

Зрештою, це означає, що якщо ви зараз створили браузер зі строгим html-розбором 99% сайтів, вони просто не спрацюють.

Добре, що ми намагалися встановити хороший строгий варіант у тисячах, але це не вийшло, тому що люди, слідуючи за «найкращими методами» сліпо, звинувачували браузери, коли їх неправильна розмітка розбиралася в суворому режимі. І постачальникам браузерів не подобалося, що їх звинувачують.

Вони заявляли, що це тому, що вони хотіли, щоб Інтернет був доступнішим непрофесіоналам, але ніхто не перешкоджав використанню HTML 4 у його найбільш м'якій формі.

З цього приводу, ви все ще можете служити HTML5 як XML, якщо хочете строгого макета. ІМО, це може бути хорошим способом скористатись перевагами компонування або роботи інтерфейсу в більш жорсткому режимі, перш ніж передавати його іншим людям, які можуть або не хочуть цього як суворого, без реальних ризиків (забороняючи їм виривати доктрип, оскільки вони насправді віддають перевагу режиму примх - у 2017 році (час цієї редагування) їх слід знімати. Отже, це все ще є в основному, але проводять деякі дослідження. Здається, я пам'ятаю, що у XHTML у нас не було певних застережень, які не мали по-справжньому впливають на верстку роботи. Просто не поширюйте слово, що це "єдиний спосіб зробити це правильно", або твітни, які купують цю розмову, зроблять ідею, знову звинувачуйте браузери, і вони приймуть зуби з єдиної суворої альтернативи, яку ми залишили. (2017 редакція:

http://mathiasbynens.be/notes/xhtml5