Разница между html и xhtml можно охарактеризовать следющим фактом:
<html> элемент optional в html а в xhtml нет ибо по определинию xml
невалидный markup XMLом не является т.е. не может быть использован
на стороне приемника. Т.е. в условиях public сетей xml как средство
представления информации признан несостоятельным что ли.
.
Здравствуйте, c-smile, Вы писали:
CS>Разница между html и xhtml можно охарактеризовать следющим фактом: CS><html> элемент optional в html а в xhtml нет ибо по определинию xml CS>невалидный markup XMLом не является т.е. не может быть использован CS>на стороне приемника. Т.е. в условиях public сетей xml как средство CS>представления информации признан несостоятельным что ли. CS>.
But due to the significant legacy of Web content that is some variant of HTML, traditional browser vendors moved slowly to adopt XHTML. This, in turn, has meant little motivation for content developers to adopt XHTML for the traditional desktop environment. Leaders in the Web developer and design communities therefore urged W3C to renew its commitment to HTML by adding new features (starting with the HTML 4 standard) in a manner that is consistent with community practice and backward compatible.
Все броузеры поддерживают сейчас xhtml 1.1. Никто не поддерживает xhtml 2.0 вообще.
Вообще с xml больше вопросов чем ответов. Скажем partial rendering.
По определению пока я не получил завершающий </html> я не могу сказать что я вижу: xhtml это или нет?
Т.е. все что я могу сделать для progressive rendering это отображать в мере поступления в quirks mode и
по завершению переключиться на doctype xhtml с другими правилами отображения. Это не реально.
В реале все движки используют один и тот-же парсер для парсинга. Т.е. даже xhtml парсится по правилам
html. Основное отличие html parsing от xhtml это то что в html определено понятие error handling.
Т.е. незакрыитые тэги закрываются и пр. Ну т.е. мне лично как разработчику html parser этот самый
xhtml нужен как собаке пятая нога. С точки зрения парсера xhtml есть подмножество html, но так как
я все равно обязан поддерживать html то xhtml получается излишним.
Т.е. достоинство xhtml — строгость markup. Но первый же броузер который на незакрытый тэг в xhtml покажет юзеру
"Cannot show this document as it is not an XML" тут же уйдет с рынка.
Т.е. про xhtml as a valid xml можно просто забыть. web content пока пишут люди которым свойственно ошибаться.
Таким образом xhtml не для людей. Да, Word например может продуцировать и гарантировать валидный xhtml но
web руками-то сделан в основном.
Здравствуйте, c-smile, Вы писали: CS>Т.е. про xhtml as a valid xml можно просто забыть. web content пока пишут люди которым свойственно ошибаться.
Почему пока? Имхо далеко не предвидется полной автоматизации это деятельности
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, c-smile, Вы писали: CS>>Т.е. про xhtml as a valid xml можно просто забыть. web content пока пишут люди которым свойственно ошибаться. К>Почему пока? Имхо далеко не предвидется полной автоматизации это деятельности
Автоматизации — нет. Но ходят слухи что w3c создает комитет по созданию имплантируемого чипа со встроенными XML validator и HTML Tidy.
Здравствуйте, c-smile, Вы писали:
CS>Чего "Ничего подобного"? CS>Все броузеры поддерживают сейчас xhtml 1.1. Никто не поддерживает xhtml 2.0 вообще.
Ну значит будут поддерживать и XHTML5 (или как там его назовут) с обратной совместимостью, XHTML2 — отныне другой язык.
CS>Вообще с xml больше вопросов чем ответов. Скажем partial rendering. CS>По определению пока я не получил завершающий </html> я не могу сказать что я вижу: xhtml это или нет? CS>Т.е. все что я могу сделать для progressive rendering это отображать в мере поступления в quirks mode и CS>по завершению переключиться на doctype xhtml с другими правилами отображения. Это не реально.
Ты про это: https://bugzilla.mozilla.org/show_bug.cgi?id=18333 ?
CS>В реале все движки используют один и тот-же парсер для парсинга. Т.е. даже xhtml парсится по правилам CS>html. Основное отличие html parsing от xhtml это то что в html определено понятие error handling. CS>Т.е. незакрыитые тэги закрываются и пр. Ну т.е. мне лично как разработчику html parser этот самый CS>xhtml нужен как собаке пятая нога. С точки зрения парсера xhtml есть подмножество html, но так как CS>я все равно обязан поддерживать html то xhtml получается излишним.
Насколько я знаю, Mozilla использует разные парсеры: для HTML — прасер HTML, для XHTML — парсер XML.
CS>Т.е. достоинство xhtml — строгость markup. Но первый же броузер который на незакрытый тэг в xhtml покажет юзеру CS>"Cannot show this document as it is not an XML" тут же уйдет с рынка.
Firefox часто такое выдаёт и ничего. Просто не надо выдавать свой tag soup за валидный XHTML.
CS>Т.е. про xhtml as a valid xml можно просто забыть. web content пока пишут люди которым свойственно ошибаться. CS>Таким образом xhtml не для людей. Да, Word например может продуцировать и гарантировать валидный xhtml но CS>web руками-то сделан в основном.
А валидаторами этим людям религия пользоваться не позволяет?
Здравствуйте, anonymous, Вы писали:
A> ... XHTML2 — отныне другой язык.
Это значит что гуппа товарищей со скорбными лицами уже поет "Sic transit gloria mundi..."
Не больше и не меньше. Забуть про него.
CS>>Вообще с xml больше вопросов чем ответов. Скажем partial rendering. CS>>По определению пока я не получил завершающий </html> я не могу сказать что я вижу: xhtml это или нет? CS>>Т.е. все что я могу сделать для progressive rendering это отображать в мере поступления в quirks mode и CS>>по завершению переключиться на doctype xhtml с другими правилами отображения. Это не реально.
A>Ты про это: https://bugzilla.mozilla.org/show_bug.cgi?id=18333 ?
Это только фрагмент проблемы. скажем броузер получил половину текста который обозначен как xhtml.
Как мне его отображать? Как html или как xhtml? Фрагмент xml собственно xml-ом не является. По определению.
Т.е. пока ты не получил завершающий </html> ты не можешь сказать что ты видишь.
И вообще какой придурок придумал что xhtml должен начинаться с <html> а не с <xhtml>?...
CS>>В реале все движки используют один и тот-же парсер для парсинга. Т.е. даже xhtml парсится по правилам CS>>html. Основное отличие html parsing от xhtml это то что в html определено понятие error handling. CS>>Т.е. незакрыитые тэги закрываются и пр. Ну т.е. мне лично как разработчику html parser этот самый CS>>xhtml нужен как собаке пятая нога. С точки зрения парсера xhtml есть подмножество html, но так как CS>>я все равно обязан поддерживать html то xhtml получается излишним.
A>Насколько я знаю, Mozilla использует разные парсеры: для HTML — прасер HTML, для XHTML — парсер XML.
Ну и зря.
CS>>Т.е. достоинство xhtml — строгость markup. Но первый же броузер который на незакрытый тэг в xhtml покажет юзеру CS>>"Cannot show this document as it is not an XML" тут же уйдет с рынка.
A>Firefox часто такое выдаёт и ничего. Просто не надо выдавать свой tag soup за валидный XHTML.
Ни разу не видел.
"Просто не надо выдавать свой tag soup за валидный XHTML." это из серии благих пожеланий.
Скажем я пишу нечто аналогичное WordPress. Я не контролирую весь контент.
Т.е. wordpress уже не будет использовать xhtml.
А кто тогда будет? Обрати внимание что как правило на сайтах отмеченных значком valid xhtml меньше
всего полезной информации.
CS>>Т.е. про xhtml as a valid xml можно просто забыть. web content пока пишут люди которым свойственно ошибаться. CS>>Таким образом xhtml не для людей. Да, Word например может продуцировать и гарантировать валидный xhtml но CS>>web руками-то сделан в основном.
A>А валидаторами этим людям религия пользоваться не позволяет?
Позволяет. Вот попрошу свою жену чтобы она себе XML валидатор имплантировала.
Хошь запишу на voice recorder и дам тебе послушать её ответ?
Здравствуйте, c-smile, Вы писали:
CS>Т.е. достоинство xhtml — строгость markup. Но первый же броузер который на незакрытый тэг в xhtml покажет юзеру CS>"Cannot show this document as it is not an XML" тут же уйдет с рынка.
CS>Т.е. про xhtml as a valid xml можно просто забыть. web content пока пишут люди которым свойственно ошибаться. CS>Таким образом xhtml не для людей. Да, Word например может продуцировать и гарантировать валидный xhtml но CS>web руками-то сделан в основном.
Я вообще не понимаю, какой смысл имеют имена в закрывающих тагах XML. Они имеют смысл в SGML и HTML — там, где закрывающих тагов можно вообще не писать. Вот пример валидного SGML:
<anthology>
<poem><title>The SICK ROSE
<stanza>
<line>O Rose thou art sick.
<line>The invisible worm,
<line>That flies in the night
<line>In the howling storm:
<stanza>
<line>Has found out thy bed
<line>Of crimson joy:
<line>And his dark secret love
<line>Does thy life destroy.
<poem>
<!-- more poems go here -->
</anthology>
Здесь принцип таков, что открывающий таг автоматически закрывает все таги, вплоть до открытого тага с таким же именем. Ну просто вверх по стэку — последний <poem> закрывает <line>, <stanza> и первый <poem>. При таком подходе совершенно необходимо указывать имя в закрывающем таге, если мы что-то хотим закрыть явно. Например, если бы вместо последнего <poem> была бы <novel>, то перед ней мы должны были бы явно закрыть предыдущий </poem>, с автоматическим закрытием <line> и <stanza> — по этому имени определяется, что же именно мы закрываем. А в XML, поскольку абсолютно все закрывающие таги обязательны, то и необходимость в повторении имени полностью отпадает. Единственное оправдание XML — полная синтаксическая совместимость с SGML. То есть, XML является так же валидным SGML. Но я не могу придумать ни единого резона — зачем это нужно.
Получается такая парадоксальная ситуация:
XML (как и XHTML) — не для людей по причине железобетонной "строгости" (в отличие от SGML и HTML, которые именно что для людей из за их "вольностей"). Они — для автогенерации. Но тогда, зачем, зачем нужно повторять имена в закрывающих тагах?! Эти имена являются синтаксическим мусором и не несут ни малейшей полезной нагрузки.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Получается такая парадоксальная ситуация: MS>XML (как и XHTML) — не для людей по причине железобетонной "строгости" (в отличие от SGML и HTML, которые именно что для людей из за их "вольностей"). Они — для автогенерации. Но тогда, зачем, зачем нужно повторять имена в закрывающих тагах?! Эти имена являются синтаксическим мусором и не несут ни малейшей полезной нагрузки.
Я вот сейчас работаю с JSON, где вообще часто имен тэгов нет. Так вот, со вложенными структурами на несколько экранов очень неудобно работать — непонятно какая скобка что закрывает.
В языках программирования то же самое, но обычно циклы и другие вложенные структуры (кроме процедур/классов верхнего уровня, где вложенность не важна) не бывают очень большими. А вот при описании данных — элементарно получается.
ИМХО, XML достаточно удачно сбаллансирован. Все YAML и прочие JSONы обычно от него отличаются лишь закрывающими скобками, а тем не менее, считают это новым революционным изобретением и лучшей вещью since sliced bread.
Меня уже это достает — вот сегодня на собеседовании человек вещал о суперкрутости JSON и о том, что XML уже устарел и его пора выкидывать.
Здравствуйте, Cyberax, Вы писали:
C>Я вот сейчас работаю с JSON, где вообще часто имен тэгов нет. Так вот, со вложенными структурами на несколько экранов очень неудобно работать — непонятно какая скобка что закрывает.
А в той системе что вы строите предполагается ли что человек будет в эти данные заглядывать вообще?
Кстати №1:
В Sciter есть простой визуализатор JSON
см. sdk\samples\communications\jahoo-rpc\yahoo-image-search.htm
— показывает структуру в виде дерева.
Кстати №2:
И вообще функция parseData(string | Stream);
в sciter (и в tiscript кстати) парсит именно JSON т.е. safe for code injections.
Ну до кучи: String.printf("%V", obj); сериализует obj в JSON строку. Sstream.printf соответсвенно в файл.
Имея object написать сериализатор в XML несложно я думаю если тебе удобнее с ним работать.
Здравствуйте, Cyberax, Вы писали:
C>Меня уже это достает — вот сегодня на собеседовании человек вещал о суперкрутости JSON и о том, что XML уже устарел и его пора выкидывать.
MS>Здесь принцип таков, что открывающий таг автоматически закрывает все таги, вплоть до открытого тага с таким же именем. Ну просто вверх по стэку — последний <poem> закрывает <line>, <stanza> и первый <poem>. При таком подходе совершенно необходимо указывать имя в закрывающем таге, если мы что-то хотим закрыть явно. Например, если бы вместо последнего <poem> была бы <novel>, то перед ней мы должны были бы явно закрыть предыдущий </poem>, с автоматическим закрытием <line> и <stanza> — по этому имени определяется, что же именно мы закрываем. А в XML, поскольку абсолютно все закрывающие таги обязательны, то и необходимость в повторении имени полностью отпадает. Единственное оправдание XML — полная синтаксическая совместимость с SGML. То есть, XML является так же валидным SGML. Но я не могу придумать ни единого резона — зачем это нужно.
Такую грамматику трудно назвать контекстно-свободной. Со всеми вытекающими из этого последствиями.
Здравствуйте, McSeem2, Вы писали:
MS>Получается такая парадоксальная ситуация: MS>XML (как и XHTML) — не для людей по причине железобетонной "строгости" (в отличие от SGML и HTML, которые именно что для людей из за их "вольностей"). Они — для автогенерации. Но тогда, зачем, зачем нужно повторять имена в закрывающих тагах?! Эти имена являются синтаксическим мусором и не несут ни малейшей полезной нагрузки.
Кстати, похоже ты сам неявно ответил на поставленный вопрос. XML — это контекстно-свободный язык совместимый с SGML. Если бы в use case не было бы записано совместимость с SGML — язык был бы другим. Может быть и лучше. Но пока — он единственный общепринятый(всемиподдерживаемый) язык для обмена данными.
c-smile wrote: > C>Я вот сейчас работаю с JSON, где вообще часто имен тэгов нет. Так вот, > со вложенными структурами на несколько экранов очень неудобно работать — > непонятно какая скобка что закрывает. > А в той системе что вы строите предполагается ли что человек будет в эти > данные заглядывать вообще?
Там с помощью JSON задаются правила обработки, которые пишут программисты.
> Кстати №1: > В Sciter есть простой визуализатор JSON > см. sdk\samples\communications\jahoo-rpc\yahoo-image-search.htm > — показывает структуру в виде дерева.
Ой, спасибо. Вроде все уже договорились, что внешние графические
редакторы для данных/кода — это suxxx. Все должно быть в plain text с
удобными способами его редактирования.
> Кстати №2: > И вообще функция parseData(string | Stream); > в sciter (и в tiscript кстати) парсит именно JSON т.е. safe for code > injections.
XML парсер тоже парсит код без всяких injections.
> Ну до кучи: String.printf("%V", obj); сериализует obj в JSON строку. > Sstream.printf соответсвенно в файл.
И?
> Имея object написать сериализатор в XML несложно я думаю если тебе > удобнее с ним работать.
Проблема с десериализатором. В этом приложении на PHP правила
обрабатываются на сервере и _частично_ передаются на клиентскую сторону.
Курилка wrote: > C>Меня уже это достает — вот сегодня на собеседовании человек вещал о > суперкрутости JSON и о том, что XML уже устарел и его пора выкидывать. > И как взяли?
Взял. Чтобы он боролся с этим приложением на PHP+JSON. Посмотрим, что он
скажет через неделю
