Какую проблему решает строгий XHTML? - PullRequest
21 голосов
/ 10 ноября 2008

Я действительно не понимаю обаяние со строгим XHTML. Встроенный JavaScript, как правило, требует крысиных гнезд, чтобы сделать его совместимым с XHTML и полу-обратно совместимым с MSIE 5 и 6. Тогда возникает проблема нехватки OCD при вводе пользователем, чтобы убедиться, что вы не пропустили никаких недопустимых символов. , Это просто кажется больше усилий, чем стоит. Не говоря уже о том, что почти каждый разработчик, с которым я работал, постоянно забывает о том, что тип содержимого, возвращаемый с сервера, сбрасывается для страниц XHTML с text / html на application / xhtml + xml.

Хотелось бы, чтобы я знал имя блоггера, но кто-то еще отметил, что большинство предположительно XHTML-совместимых сайтов и пакетов с открытым исходным кодом на самом деле не из-за этой последней проблемы, забыв правильно установить заголовок типа контента.

Я хочу понять, почему XHTML полезен, или создать достаточно арсенала аргументов, чтобы он никогда не использовался в будущих проектах, на которые я влияю.

Ответы [ 13 ]

23 голосов
/ 10 ноября 2008

XHTML1 против HTML4 и Строгий против Переходного - полностью ортогональные проблемы.

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

Ограничение себя [X] HTML Strict само по себе ничего не дает, кроме простого отказа от использования старых, менее удобных в использовании техник, которые не следует использовать в любом случае.

Встроенный javascript, как правило, требует крысиных гнезд, чтобы сделать его совместимым с XHTML

Вы можете уйти без каких-либо побегов, если вы не используете символы <или &. И «<<CDATA [» на самом деле не намного хуже, чем «<! -» в прежние времена. </p>

В любом случае, сохранение сценариев во внешнем виде гораздо более управляемым; Вы не хотите делать что-либо существенное в строке.

Тогда возникает проблема нехватки OCD при вводе пользователем, чтобы не пропустить ни одного недопустимого символа.

Внеполосные символы в HTML4 Transitional точно такие же, как и в XHTML1 Strict.

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

забывая, что тип содержимого, возвращаемый сервером, сбрасывается для страниц XHTML с text / html на application / html + xml.

Это не «забывание», это преднамеренно: сегодня нет особого смысла в обслуживании приложения / xhtml + xml. Чтобы учесть IE, вам нужно понюхать UA, а затем убедиться, что вы понимаете различия CSS и JavaScript, которые появляются в обоих режимах синтаксического анализа ... вы можете сделать это, чтобы доказать свое техническое мастерство, но на самом деле ничего вам не дается. .

Работа с XHTML как унаследованным HTML может быть не идеальной, но она позволяет сохранить более простой и технологичный синтаксис XML (и потенциальную совместимость с другими языками XML, такими как SVG), при этом оставаясь дружественным к браузеру.

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

7 голосов
/ 10 ноября 2008

есть отличный пост об использовании XHTML @ Остерегайтесь XHTML .

Надеюсь, это поможет, Bruno Figueiredo

5 голосов
/ 11 ноября 2008

XHTML 1.0 Strict пытается решить четыре проблемы:

  1. XML - это технология W3C, а HTML4 не использует ее. Не твоя проблема.

  2. Строгий стремится быть более теоретически чистым, чем переходный, когда дело доходит до презентационализма. Но это не проблема XHTML против HTML .

  3. XML-парсер предположительно проще. (Не совсем верно; код для работы с частью DTD довольно сложный.) В наши дни вы получаете в комплекте как XML, так и HTML-парсеры , поэтому это не ваша проблема. (За исключением: мобильный аргумент совершенно фальшивый .)

  4. application / xhtml + xml (хотя и не действительный XHTML 1.0 Strict!) Позволяет смешивать другие словари. Если вы хотите использовать встроенный MathML или SVG сегодня, это основная причина использовать application / xhtml + xml сегодня. Однако направление работы HTML5 позволяет использовать MathML и SVG в text / html.

4 голосов
/ 10 ноября 2008

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

3 голосов
/ 10 ноября 2008

Вам нужно проанализировать ваш HTML с помощью программы, o для некоторых тестов? Затем используйте XHTML.

Для всего остального HTML 4.01 (строгий, свободный, переходный, что угодно) совершенно «стандартный» и менее «хлопотный».

2 голосов
/ 10 ноября 2008

XHTML позволяет вам выполнять расширенный рендеринг, такой как SVG (масштабируемая векторная графика), который сам по себе является XML, но его можно легко встроить в XHTML через расширение пространства имен XML без или . К сожалению, только Firefox и Safari поддерживают его. Извините, пользователи IE6.

Подробнее о SVG на http://en.wikipedia.org/wiki/Svg

0 голосов
/ 11 ноября 2008

Лично мне понравилась концепция XHTML: она намного чище, чем большая часть HTML, которую мы видим, легче анализировать и проверять. Как и все, я начал кодировать страницы XHTML. Кстати, я не вижу проблемы со встроенным JavaScript, нет необходимости в экранировании, если вы поместите код в CDATA. И, к счастью, IE5 немного отошел от браузера, как Netscape 4, который заставил нас писать / > вместо />, что я до сих пор вижу в чистом XML ...

Теперь я прочитал несколько статей, например, статью Бруно, в которой есть много веских аргументов против его использования в большинстве случаев . По сути, в нем говорится, что большинство браузеров не просто готовы к строгому XHTML (используется как XML), не имеет особого смысла использовать XHTML в качестве HTML, и в любом случае это не так полезно на большинстве сайтов.

Посмотрите на рассмотренные выше аргументы: они совершенно верны, и очень здорово иметь возможность помещать MathML или SVG непосредственно на страницу, преобразовывать XML с помощью синтаксического анализатора XSLT, обрабатывать страницу с помощью синтаксического анализатора XML.

Но как часто вы это делаете? Синтаксический анализ страницы чаще всего является проблемой конечных пользователей, которые могут использовать хороший HTML-парсер. А учитывая количество браузеров, способных управлять MathML, SVG или XSLT, в большей степени требуется интрасеть, чем обширный Интернет.

У вас может быть электронная коммерция, блог или форум, на котором есть хорошие страницы XHTML. И люди, пишущие описания, статьи или сообщения, вставляют <p><p><p>, чтобы пропустить некоторые строки, когда это не <p/> или какая-то другая экзотическая конструкция ...

Я верю в XHTML, но думаю, что больше не буду использовать его для маленьких страниц, которые я делаю для своего сайта. Я буду использовать HTML 4 с хорошо написанным кодом (атрибуты в кавычках, закрывающие теги, даже если необязательные и т. Д.).
И в конце концов, если W3C работает в HTML 5, это происходит по причине: у HTML все еще впереди, иначе он был бы убит в пользу XHTML 2.

0 голосов
/ 11 ноября 2008

Единственная вещь, которую я видел, решенная с помощью XHTML, это «проблема» пользователей, использующих Safari: я не знаю, есть ли ошибка, но когда нас в последний раз просили написать на XHTML, мы столкнулись ошибка, из-за которой XHTML не работал в Safari. В XHTML следующий URL не разрешен в тегах привязки, поскольку амперсанд не экранирован:

http://www.example.com/page.php?arg1=val1&arg2=val2

так что вам нужно заменить его на & amp; как это:

http://www.example.com/page.php?arg1=val1&amp;arg2=val2

но Safari конвертирует & amp; и вы получите этот URL:

http://www.example.com/page.php?arg1=val1&#38;arg2=val2

... и символ хеша завершает URL, если речь идет о PHP. Я знаю, что есть уродливые хаки, которые позволяют вам передавать две переменные другими способами, но если XHTML заставит вас использовать уродливые хаки, то вам лучше без них.

0 голосов
/ 10 ноября 2008

Это глобальный стандартный выпуск

Это касается не только xHTML, но и всех стандартов в мире. Вам нужно прояснить ситуацию от версии к версии.

xHTML имеет квадратную форму и подталкивает кодеров для добавления семантической ценности в код. Он полностью совместим с XML и поэтому более легко разбирается, стилизуется и т. Д.

Помните, что код предназначен не только для программистов, но и для машин. Через 10 лет люди, создающие браузеры или библиотеки, не захотят применять одни и те же комплексные правила для старой обработки HTML, а скорее будут ожидать чего-то максимально чистого.

Поисковому движку нужно что-то, на что можно полагаться для построения семантических связей между значениями, поэтому лучше, если есть только один простой способ сделать это.

И я не говорю о средствах чтения с экрана ...

Стандарт, прежде всего, касается перехода к одному уникальному открытому решению, которое соответствует потребностям каждого. Не только о добавлении новых блестящих функций.

0 голосов
/ 10 ноября 2008

Строгий предназначен для того, чтобы формализовать разделение между контентом и стилем, усложняя их объединение. Эллиот Расти Гарольд написал хорошую статью о XHTML в одной из своих книг, вот соответствующий отрывок из « Why XHTML ».

...