Какую проблему решает XHTML strict?

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

XHTML делает HTML ортогональным со всеми другими структурами на основе xml в нашей вселенной, что дает два основных преимущества.

Шаблоны проектирования, которые мы используем при работе с xml, могут быть применены к html.

Программные инструменты тоже самое.

XHTML - это по определению XML, в отличие от HTML.

Это означает, что вы можете делать с ним забавные полезные вещи, например, легко проверять и анализировать его (поскольку вы знаете, что это XML, и, следовательно, можете использовать множество доступных инструментов).

Также гикам нравится делать вещи «более правильными» ;-)

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

Надеюсь, это поможет, Бруно Фигейредо

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

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

XHTML имеет преимущества xml. Но почему тогда строгий вариант?

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

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

Это проблема глобального стандарта

Речь идет не только о xHTML, но и обо всех мировых стандартах. От версии к версии нужно делать все яснее.

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

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

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

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

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

XHTML1 против HTML4 и Strict vs Transitional - это полностью ортогональные проблемы.

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

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

Inline javascript typically requires a rats nest of escapes to make it compatible with XHTML

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

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

Then there is the issue of not being OCD enough on user input to make sure you don't miss any illegal characters.

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

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

forgetting to ensure the content-type returned from the server is reset for XHTML pages from text/html to application/html+xml.

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

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

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

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

Для получения дополнительной информации о SVG на http://en.wikipedia.org/wiki/Svg

Единственная вещь, которую я видел решенной с помощью 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&arg2=val2

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

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

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

Лично мне понравилась концепция 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.

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

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

2. Строгий стремится быть более теоретически чистым, чем Transitional, когда дело касается презентационализма. Но это не проблема 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.