Должен ли я писать документы Polyglot HTML5?

Question

Я рассматривал возможность конвертации моих текущих документов HTML5 в полиглот HTML5. Я полагаю, что даже если их только когда-нибудь получат как text/html, дополнительные проверки написания XML помогут сохранить мои привычки кодирования аккуратными и действительными.

Есть ли что-то особенно захватывающее в пространстве HTML5, которое сделало бы это неразумным выбором?

Во-вторых, спецификации немного туманны, как проверить документ полиглота. Я предполагаю, что основы являются:

1. Отсутствие ошибок при запуске через W3C Validator, как HTML5
2. Нет ошибок при не запускать через XML-парсер

Но есть какие-либо другие правила, я пропавшими без вести?

В-третьих, видя, как это является полиглот, знает ли кто-либо предостережений в обслуживании как application/xhtml+xml к поддержке браузеров и text/html к не-поддержки тех?

Редактировать: После небольшого эксперимента я обнаружил, что объекты, подобные  , разбиваются на XHTML5 (без DTD). Этот парсер XML - это немного обоюдоострый меч, я, наверное, уже ответил на мой третий вопрос.

Answer 1

Работа над определением того, как создавать документы многоугольника HTML5, в настоящее время продолжается, но см. http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html для раннего черновика. Это, безусловно, возможно, но для этого требуется очень много дисциплины кодирования, и вам нужно будет решить, стоит ли это делать. Хотя я создаю документы polyglot HTML4.01/XHTML1.0, я создаю их с помощью цепочки инструментов XML, которая гарантирует корректность XML и имеет специализированный код для обеспечения совместимости с HTML-не-void элементами и действительными символами XML. Прямое кодирование будет очень сложным.

Одной из известных текущих проблем в HTML5 является атрибут srcdoc для элемента iframe. Поскольку значение атрибута содержит разметку, некоторые символы должны быть экранированы. Спецификация проекта HTML5 описывает, как это сделать для сериализации HTML, но не (в последний раз, когда я смотрел), как это сделать в сериализации XHTML.

Answer 2

Это звучит очень сложно. Одним из недостатков XHTML было то, что не удалось успешно справиться между конкурирующими требованиями XML и винтажным HTML.

Я думаю, что если вы напишете HTML5 и подтвердите его успешно, у вас будет такой же аккуратный и действительный документ, как и любой другой.

Answer 3

Учитывая, что документация W3C о различиях между HTML и XHTML еще не завершена, вероятно, не стоит тратить время на выполнение полиглота. Пока еще нет ... дайте ему еще пару лет.

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

Answer 4

Этой вики имеют некоторую информацию, не присутствующую в документе W3C: http://wiki.whatwg.org/wiki/HTML_vs._XHTML

Answer 5

Я опоздал на вечеринку, но через 5 лет этот вопрос все еще актуален. С одной стороны, все мои теги сильно обращаются ко мне. Для людей, читающих это, для облегчения редактирования, для Великой справедливости. OTOH, глядя на детали gogy из полиглота spec - http://www.sitepoint.com/have-you-considered-polyglot-markup/ имеет удобное резюме в конце - мне ясно, что я не могу получить его все прямо из рук.

также проливает интересный свет на то, почему XHTML не удалось: выбор для использования типа XML mime имеет различные побочные эффекты при время выполнения. К настоящему времени это должно быть рутиной для хорошего JS-кода для обработки этих (например, всегда нижних регистров тегов перед сравнением), но я не хочу все это. Большое количество проблем с кросс-браузерами, которые нужно проверить, так как есть, спасибо.

Так что я думаю, что есть полезный средний путь:

1. В настоящее время служат только text/html. Не стоит беспокоиться о том, что на самом деле он будет анализировать как точно такую ​​же DOM с таким же временем выполнения в режимах HTML и XML.

2. Только стремиться, что он разбирает как некоторые хорошо сформированные XML. Это помогает читателям, помогает редакторам, позволяет использовать XML-парсер в моих собственных документах.

   К сожалению, многоязычные инструментов редко несуществующему - это трудно даже сериализовать обратно XML таким образом, что также передает требования HTML ...

   • ежу понятно: всегда самостоятельно закрыть недействительные тег (<hr/>) и отдельно закрывать недействительные теги (<script ...></script>).

   • Нет Brainers: используйте строчные тег и Attr (за исключением некоторого SVG, но иностранный контент использует правила XML в любом случае), всегда котировка значения атрибутов, всегда обеспечивает значение атрибутов (selected="selected" более многословен, чем stanalone selected, но я могу жить с этим) ,

   • Inline <script> и <style> являются наиболее раздражающими. Я не могу использовать & или <, не нарушая синтаксический анализ XML. Мне нужно:

     <script>/*<![CDATA[*/ 
         foo < bar && bar < baz; 
     /*]]>*/</script> 
     

   ... и именно об этом! Не заботясь о пространствах имен XML или о предполагаемой DOM для таблиц DAM для таблиц, опускается около половины правил :-)

3. Подождите некоторое будущее, когда я могу напрямую перейти к созданию XHTML, пропуская полиглотность. Выгода в том, что я смогу забыть ограничения закрытия тегов, сможет напрямую потреблять и производить с помощью XML-инструментов. Несомненно, пренебрегая пространствами имен xml и другими вещами, теперь будет сложнее переключиться, но я думаю, что в будущем буду создавать больше документов, чем конвертировать существующие.

   На самом деле я не совсем уверен, что мешает мне жить в этом будущем прямо сейчас. Это только IE 8? Я также немного обеспокоен обработкой ошибок «все или ничего». Я очень надеюсь, что будущая спецификация HTML найдет способ сгладить пробелы HTML и XML, например. делают браузеры <hr></hr> и <script .../> в HTML-коде, сохраняя при этом обработку ошибок HTML.

   Также, инструменты.Наличие библиотек на многих языках, которые могут быть сериализованы для разметки полиглота, сделало бы возможным создание программ для их создания. Имеются инструменты для проверки и преобразования HTML5 < -> polyglot < -> XHTML5 поможет. В противном случае, это в значительной степени обречено.

Answer 6

Должны ли вы? Да. Но сначала некоторые разъяснения по парам.

Отправка заголовка Content-Type: application/xhtml+xml означает, что он должен проходить через синтаксический анализатор XML, он по-прежнему имеет все преимущества HTML5, насколько я могу судить.
О  , который не определен в XML, единственными символами, которые ссылаются на XML, являются lt, gt, apos, quot и amp, вам нужно будет использовать числовые ссылки символов для чего-либо еще. Код для nbsp -   или  . Я лично предпочитаю hex, потому что коды Юникод-кода представлены таким образом (U + 00A0).

Отправка заголовка полезна для тестирования, так как вы можете быстро найти проблемы с вашей разметкой, такие как незамкнутые теги, теги штрихового конца, текст, который может быть интерпретирован как тег и т. Д., В основном вещи, которые могут нарушить внешний вид или даже функциональность вашего сайта.
Наиболее значительным, на мой взгляд, является то, что вы разрешаете пользователю вводить данные и не разбираетесь в этом, что обычно означает, что вы не избежали их данных и оставляете себя уязвимыми. Если вы считаете HTML-кодом, вы можете не заметить проблемы до тех пор, пока кто-то не начнет вводить скрипты, чтобы беспокоить ваших пользователей или красть данные.

Эта страница довольно хорошо о объясняя, что полиглот разметка: (! Теперь HTML5 является рекомендация) https://blog.whatwg.org/xhtml5-in-a-nutshell