Чому б не XHTML5?

53

Отже, HTML5 - це великий крок вперед, мені кажуть. Останнім кроком, який ми зробили, про який я знаю, - це впровадження XHTML. Переваги були очевидні: простота, строгість, можливість використовувати стандартні XML-аналізатори та генератори для роботи з веб-сторінками тощо.

Як дивно і страшно, що HTML5 відкочує все це назад: ми знову працюємо з нестандартним синтаксисом; ще раз, ми маємо мати справу з історичною складністю багажу та розбору; ми знову не можемо використовувати наші стандартні XML-бібліотеки, аналізатори, генератори чи трансформатори; і всі переваги, введені XML (розширюваність, простори імен, стандартизація тощо), що W3C витратив десятиліття на поважні причини, втрачаються.

Добре, у нас є XHTML5, але, схоже, він не набув популярності, як кодування HTML5. Дивіться, наприклад, це питання SO . Навіть специфікація HTML5 говорить, що HTML5, а не XHTML5 "- це формат, запропонований для більшості авторів".

Чи помиляюсь я про свої факти? В іншому випадку, чому я єдиний, хто так почувається? Чому люди обирають HTML5 через XHTML5?

— джемешфішер
джерело

6

+1 Я бачу, що я не єдиний, який засмучений втратою всіх переваг XML у HTML5.

— Арсеній Муренко

Добре запитання, добре.

— Конрад Рудольф

1

Я сподіваюся, що я не єдиний, хто радий втраті всіх недоліків XML у HTML5. Наприклад, порівняємо дійсний HTML5 з дійсним XHTML. HTML5:, <!DOCTYPE html>Hello WorldXHTML:

<?xml version="1.0" encoding="iso-8859-1"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0  Transitional//EN" "DTD/xhtml1-transitional.dtd"><html xml:lang="en" lang="en" xmlns="http://www.w3.org/1999/xhtml"><head><title></title></head><body>Hello World</body></html>

— zzzzBov

@zzzzBov, ти, безумовно, не єдиний, хто радий, і саме тому я задав це питання в першу чергу. Також: ви б серйозно не писали <!DOCTYPE html>Hello World, чи не так? Спробуйте це на цьому валідаторі .

— jameshfisher

1

@eegg, мабуть, ти не читав специфікації на необов'язкових початкових тегах , тому що я серйозно написав би<!DOCTYPE html>Hello World! , оскільки це абсолютно дійсний HTML5. Більш короткі документи означають менші витрати на пропускну здатність, що приводить до значної економії великих компаній (ви бачили, що Google надсилає на www.google.com?).

— zzzzBov

25

Я б рекомендував прочитати, Як ми потрапили сюди? . Марк Пілігрим дає чудову та коротку історію HTML до HTML5.

По суті, я розумію, що багато веб-сторінок навіть не користуються "X" XHTML, оскільки вони не визначають відповідний тип MIME для нього.

— птеза
джерело

18

Так. Моє резюме цієї історії було б: "Ей, ніхто не відповідає специфікації. Можливо, ми могли б змусити їх відповідати специфікації, вказавши, що люди можуть робити будь-які помилки. Тоді нарешті всі наші документи будуть помилковими. і відповідають стандартам ". Немає користі від написання специфікації з початковим припущенням, що ніхто не поважає специфікації.

— jameshfisher

1

@eegg, останній рядок показує ваше невігластво до реальності. Багато хорошого вже вийшло з того, що припускати, що ніхто не ідеальний . Замість того, щоб специфікація сказала: "якщо ви зробите будь-яку помилку, все порушено", це замість цього говорить: "якщо ви робите [цей тип помилки], то [цей результат] - це те, що повинно статися". Скільки книг було б на наших полицях, якби вони мали мати 100% правильні написання, пунктуацію та граматику, щоб вони були видані?

— zzzzBov

6

@zzzzBov, ваша аналогія з виданими книгами дивна. Чому HTML-аналізатор повинен пробачати більше, ніж аналізатор [будь-якої іншої мови тут], де синтаксична помилка зустрічається із повідомленням про помилку? Уявіть собі хаос, у якому ми опинилися б, коли наші компілятори C намагалися зробити все можливе, щоб мовчки переосмислити розбитий синтаксис.

— jameshfisher

@eegg, я можу уявити, що трапиться, якби аналізатор будь-якої іншої мови реагував на синтаксичні помилки більш прощально: ми витратили б менше часу на пошук пропущених дужок і відсутніх напівколонок і більше часу набравши функціональний код. Я не кажу, що хороші програмісти все ще не роблять своїх програм добре сформованими, але це, безумовно, допоможе посереднім програмістам написати робочий код. CПрограма, ймовірно , в кінцевому підсумку виглядає набагато більш схожа на Pythonпрограму в тому , що точка з коми і дужки могли в основному зникнути, і то , що залишилося б це важливий код.

— zzzzBov

"Запитаний ресурс /past.htmlбільше не доступний на цьому сервері, і немає адреси переадресації."

— Марко,

6

Якщо ви створюєте xml-сумісний html5 і надсилаєте їх з xml як mime type, тоді аналізатор xml буде використаний усе, що повертається хороший джаз;)

EDIT: див. Для отримання додаткової інформації: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

— мертвексалкс
джерело

Визначте "хороший джаз". AFAIK не має переваги для розбору HTML як XML. Генерування та трансформація - це інші питання, які можуть бути зручними, але сам розбір не дає переваг, а лише недоліки (це робить косметичні помилки фатальними).

— Joeri Sebrechts

3

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

— Конрад Рудольф

Ви також можете надати деякі функціональні можливості, недоступні в стандартному html, наприклад, micin xhtml з іншим вмістом xml, і взагалі використовувати всі функції xml, простори імен для приклад. html-аналізатор може виправити поганий вихідний код - косметичні помилки, як ви їх називаєте, але ці виправлення мають ціну. Ціна полягає в тому, що браузер повинен знати, що він може знайти в коді, тим самим обмежуючи доступні функції.

— deadalnix

3

HTML5 - це логічний і неминучий висновок браузерів, які приймають закон Постеля ("Будьте ліберальні у тому, що ви приймаєте").

Після того, як один веб-переглядач з достатньою часткою ринку сприймає цей принцип, інші змушені наслідувати його, не тільки бути ліберальним, приймаючи невідповідний вміст, але і надаючи його так само, як це роблять їх конкуренти. HTML5 - це логічний результат такої ситуації: постачальники браузерів вирішили, що оскільки вони не збираються відхиляти будь-який вміст як недійсний (принаймні, не на рівні HTML - JavaScript інша справа!), Вони також можуть сидіти навколо таблиці та погодьтесь з інтерпретацією всього, що автор вмісту може на них кинути. У цьому середовищі вони не реагували доброзичливо на стандартів-вундеркіндів, говорячи їм, що якби вони відхилили недобре сформований контент від слова go, вони не потрапили б у цей безлад.

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

— Майкл Кей
джерело

3

Історія конкурентоспроможності браузерів досить правдива. Але ось у чому річ: саме тому стандарти-вундерки існують. Якби всі браузери з самого початку застосовували пряме і вузьке, організаціям, як W3C, не потрібно було б бути тут, щоб тримати речі під контролем. Вся суть стандартів - це контроль за пошкодженнями; щоб орган зі стандартів поступився і прийняв неохайність, перемагає саме його призначення.

— jameshfisher

1

@eegg: HTML5 переосмислює правила розбору, щоб зробити всі вхідні дані дійсними та все-таки мати передбачувані наслідки. Якщо помилки синтаксису неможливі, цілий клас помилок виключається з самого початку. Здатність XML мати помилки розбору є вадою дизайну, і його слід визнати таким.

— Joeri Sebrechts

1

@Joeri, ваша позиція, схоже, у специфікації HTML5, прийнята до її божевільного логічного завершення. "HTML5 перевизначає правила синтаксичного аналізу, щоб зробити всі вхідні дійсними" - це не так. Концепція помилок розбору досі існує. "Якщо помилки синтаксису неможливі, цілий клас помилок виключається з самого початку" - можливо, це пародія? Ця логіка - це те, що я саркастично перефразовував у своєму коментарі до відповіді @pthesis. Так, клас синтаксичних помилок видаляється та замінюється більшим класом помилок виправлення синтаксису браузера .

— jameshfisher

2

Специфікація HTML5 фактично значно покращена в порівнянні зі специфікацією HTML4. Зокрема, обробка умов помилок та недійсної розмітки фактично стандартизована, тобто всі веб-переглядачі, які правильно реалізують стандарт, будуть обробляти недійсну розмітку так само.

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

Переваги у створенні дійсних XML є дуже мало, оскільки інструменти та бібліотеки для обробки HTML є (майже) настільки ж доступними, і люди HTML простіше писати, ніж XML.

— Дін Хардінг
джерело

За специфікацією HTML4 , так. Але моя думка полягає в тому, що XHTML1.1 на цьому вже вдосконалився. Інструменти / бібліотеки для обробки HTML, як правило, схожі на BeautifulSoup - хоча чудові інструменти, вони повинні гинути разом зі сторінками, на яких вони були зроблені для розбору.

— jameshfisher

1

Ви ніколи не отримаєте переваг більш простого аналізатора або стандартних інструментів XML на стороні клієнта.

В Інтернеті є мільярди сторінок в HTML, деякі з них написані людьми, що давно померли, тому вони ніколи не будуть оновлюватися до XML. Отже, якщо ви хочете створити загально корисний користувальницький агент, ви все одно повинні мати можливість аналізувати старомодний HTML. Можливо, XHTML вводить лише додаткові складності, оскільки вимагає нового режиму розбору на додаток до HTML-розбору, який ви вже повинні підтримувати.

На стороні сервера ви все ще можете скористатися інструментами XML, наприклад, генерування XHTML за допомогою XSLT. Але якщо ви спеціально не використовуєте ланцюжок інструментів XML, використання синтаксису XML не буде користі, а не лише HTML.

(Ви неправі, що HTML - це "нестандартний" синтаксис. Синтаксис HTML вказується в кропітких деталях у специфікації HTML5, тож це такий же стандарт, як і синтаксис XML.)

— ЖакБ
джерело