Разница между 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. Посмотрим, что он
скажет через неделю
Здравствуйте, GlebZ, Вы писали:
GZ>Кстати, похоже ты сам неявно ответил на поставленный вопрос. XML — это контекстно-свободный язык совместимый с SGML. Если бы в use case не было бы записано совместимость с SGML — язык был бы другим. Может быть и лучше.
Вопрос не в этом, вопрос в том, почему и откуда возникло такое требование — совместимость с SGML? Кто был тот "чудак" со странным чувством юмора?
И второе. "Контекстно-свободный" — это уродская калька с английского "context free". По-русски правильно говорить "контекстно-независимый". Я конечно не специалист по грамматикам, но сдается мне, что возможность опускать закрывающие таги в SGML не сильно влияет на контекстную зависимость.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Вопрос не в этом, вопрос в том, почему и откуда возникло такое требование — совместимость с SGML? Кто был тот "чудак" со странным чувством юмора?
Могу только догадываться. SGML, даже по твоему описанию, большое и неудобное уродство. XML — это его упрощение. Известно, что XML проектировали специалисты по SGML. И в их интересах было сделать язык совместимый с SGML и который бы прозрачно обрабатывался инструментами SGML существующими на то время. SGML на тот момент был стандартизован, проработан, все его недостатки известны и имелся комитет стандартизации. К тому же не стоит забывать, что HTML — это тоже SGML, только без DTO.
MS>И второе. "Контекстно-свободный" — это уродская калька с английского "context free". По-русски правильно говорить "контекстно-независимый".
Однофигственно. Мы здесь не книги пишем, а смысловая часть вполне понятна.
MS> Я конечно не специалист по грамматикам, но сдается мне, что возможность опускать закрывающие таги в SGML не сильно влияет на контекстную зависимость.
В том-то и дело что сильно. В случае, если мы получаем открывающийся тег, то нам придется решать какое дерево создавать на основе имени тега, и имен тегов открытых до этого (что уже является контекстом). Вобщем введение опциональности закрывающего тега сделало язык чрезвычайно сложным в обработке. Читать его тоже думаю не очень приятно если нет табуляции. Придется долго выискивать и догадываться а что там было до этого открытия, и чей это child.
Название тега в закрывающемся теге — мусор. Важен сам факт неопционального закрытия. Даже если бы можно было ввести типа "<a>aaa</>", или "<a>aaa;" — простота обработки и понимания не уменьшились бы. Но в SGML (который развивался с 60-ых годов) нужно было указывать имя тега что досталось по наследству.
Здравствуйте, c-smile, Вы писали:
A>> ... XHTML2 — отныне другой язык. CS>Это значит что гуппа товарищей со скорбными лицами уже поет "Sic transit gloria mundi..." CS>Не больше и не меньше. Забуть про него.
А где эта группа товарищей раньше со своей песенкой была?
XHTML 2.0 is a markup language intended for rich, portable web-based
applications. While the ancestry of XHTML 2.0 comes from HTML 4, XHTML 1.0,
and XHTML 1.1, it is not intended to be backward compatible with its
earlier versions.
http://www.w3.org/MarkUp/
CS>Это только фрагмент проблемы. скажем броузер получил половину текста который обозначен как xhtml. CS>Как мне его отображать? Как html или как xhtml? Фрагмент xml собственно xml-ом не является. По определению. CS>Т.е. пока ты не получил завершающий </html> ты не можешь сказать что ты видишь.
Если сказали, что это XHTML, значит и обрабатывать его нужно соотвествующим образом. Обманули — сами себе злобные буратины — выдать ошибку.
CS>И вообще какой придурок придумал что xhtml должен начинаться с <html> а не с <xhtml>?...
Придурка (вернее дуру) зовут — Обратная Совместимость.
A>>Насколько я знаю, Mozilla использует разные парсеры: для HTML — прасер HTML, для XHTML — парсер XML. CS>Ну и зря.
А вот и нет. )
CS>>>Т.е. достоинство xhtml — строгость markup. Но первый же броузер который на незакрытый тэг в xhtml покажет юзеру CS>>>"Cannot show this document as it is not an XML" тут же уйдет с рынка. A>>Firefox часто такое выдаёт и ничего. Просто не надо выдавать свой tag soup за валидный XHTML. CS>Ни разу не видел.
А я часто. Причём в большинстве случаев это не человеческий фактор, которым ты пугаешь. XHTML чаще ломают банерорезалки, которые вставляют в страницу свой код.
CS>"Просто не надо выдавать свой tag soup за валидный XHTML." это из серии благих пожеланий. CS>Скажем я пишу нечто аналогичное WordPress. Я не контролирую весь контент.
Почему ты его не контролируешь? Кстати в WordPress вроде была фича, которая пыталась исправлять XHTML до валидного.
CS>Т.е. wordpress уже не будет использовать xhtml.
Использует.
CS>А кто тогда будет? Обрати внимание что как правило на сайтах отмеченных значком valid xhtml меньше CS>всего полезной информации.
Не заметил корреляции, разве что порнокартинок и анекдотов меньше, это да.
A>>А валидаторами этим людям религия пользоваться не позволяет? CS>Позволяет. Вот попрошу свою жену чтобы она себе XML валидатор имплантировала. CS>Хошь запишу на voice recorder и дам тебе послушать её ответ?
Не надо, всё, что нужно, я о себе и своих родственниках знаю. ) А если серьёзно, то валидаторов полно, есть даже встроенные в редакторы, можно пока без имплантантов обойтись.
Re[2]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, c-smile, Вы писали:
CS>Рекомендую глянуть всем кто следит за интригой:
CS>http://video.yahoo.com/video/play?vid=cccd4aa02a3993ab06e56af731346f78.2006940&fr
CS>встреча в Yahoo "Browser Wars Episode II: Attack of the DOMs"
CS>Участвуют CS>Mike Shaver from Mozilla, CS>Chris Wilson from Microsoft's IE team, CS>Hakon Wium Lie ("Howcome") from Opera (отец CSS)
Две вещи понравилось:
Committes aren't really suitable for solving problems and putting forth innovations. But they are good at specifiying general areas of problems
Цитата неточная
И предложение от оперы о нативной поддержке звука и аудио (Флэш умрет, но никто на такое не пойдет, имхо)
Здравствуйте, GlebZ, Вы писали:
GZ>Могу только догадываться. SGML, даже по твоему описанию, большое и неудобное уродство.
Он явлется таковым по совершенно другой причине — там много прочего мусора.
GZ>В том-то и дело что сильно. В случае, если мы получаем открывающийся тег, то нам придется решать какое дерево создавать на основе имени тега, и имен тегов открытых до этого (что уже является контекстом). Вобщем введение опциональности закрывающего тега сделало язык чрезвычайно сложным в обработке.
В какой обработке? Человеком или парсером? Для парсера нужен только стэк и тривиальная логика. Это настолько тривиально, что и обсуждать не стоит.
GZ>Читать его тоже думаю не очень приятно если нет табуляции. Придется долго выискивать и догадываться а что там было до этого открытия, и чей это child.
Точно так же, как и в HTML. Но зато допускает вольности. Именно поэтому XHTML и продвигается с таким скрипом — никто не любит железобетонной необходимости. Как было справедливо замечено, если браузер будет капризничать от малейшей синтаксической некорректности, то его просто задавят более либеральные браузеры. Идея что SGML, что HTML в том, что какую бы белиберду я ни написал, должно отобразиться чоть что-то. А уж неявная необходимость зачитать все до конца перед отображением — вообще идиотизм. А если мне срочно надо прочитать нужную информацию, и она уже загрузилась, но соединение отвалилось на последнем </HTML>, то я в принципе ничего не смогу увидеть! Получается как с тупой логикой защиты батарейки в мобиле — он просто вырубается, чтобы не переразрядить священную блин батарейку! Да фиг бы с ней, с батарейкой, покуда она физически способра дать ток — пусть хоть издохнет вся, я потом новую куплю. Сам звонок может быть в миллион раз важнее и батарейки и мобилы. Точно так же и информация, пусть даже неправильно отформатированная может быть в миллион раз важнее этой дурацкой прихоти — ждать весь файл до конца.
Другой аспект. Если весь длиннющий XML написан в одну строчку, то имена в закрывающих тэгах тебе никак не помогут распознать что к чему. Все равно нужен некий beautificator, чтобы прочесть. Но это же в равной степени относится и к SGML — форматтер для него получается нисколько не сложнее форматтера XML. Получается, что если все нормально отформатировано с отступами, то имена в закрывающих тэгах не влияют на читаемость. А если не отформатировано, то они никак не способствуют читаемости. Опять же получается, что смысла в них нет никакого.
GZ>Название тега в закрывающемся теге — мусор. Важен сам факт неопционального закрытия. Даже если бы можно было ввести типа "<a>aaa</>", или "<a>aaa;" — простота обработки и понимания не уменьшились бы. Но в SGML (который развивался с 60-ых годов) нужно было указывать имя тега что досталось по наследству.
Вот я и говорю, что получается парадокс — для чего придуманы XML и XHTML? Для написания людьми? — нет, поскольку в отличие от HTML и SGML не допускают вольностей. Для автогенерации? — тоже нет, поскольку повторение имен является совершенно излишним и дает ужасный перерасход. А главное — приводит к идиотским ситуациям, типа описанной выше.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[3]: Browser Wars Episode II: Attack of the DOMs
M>Committes aren't really suitable for solving problems and putting forth innovations. But they are good at specifiying general areas of problems
M>Цитата неточная M>И предложение от оперы о нативной поддержке звука и аудио (Флэш умрет, но никто на такое не пойдет, имхо)
Я сейчас участвую в одном комитете — Khronos, группа OpenVG. Тоска зеленая и абсолютный waste of time. "Смелые люди, но всего боятся" (цитата из "Убить Дракона"). Cборище каких-то старперов, хотя многие моложе меня. Даже очевидно полезные и проверенные на практике предложения, которые требуют минимальных усилий и никак не противоречат существующей концепции обсуждаются годами и могут заканчиваться ничем. Мыло-мочало, начинай сначала.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Re[4]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, McSeem2, Вы писали:
MS>Я сейчас участвую в одном комитете — Khronos, группа OpenVG. Тоска зеленая и абсолютный waste of time. "Смелые люди, но всего боятся" (цитата из "Убить Дракона"). Cборище каких-то старперов, хотя многие моложе меня. Даже очевидно полезные и проверенные на практике предложения, которые требуют минимальных усилий и никак не противоречат существующей концепции обсуждаются годами и могут заканчиваться ничем. Мыло-мочало, начинай сначала.
Угу.
Вот буквально сейчас на WHATWG листе обсуждаем:
Мы c Daniel Glazman ( делал NVU ) (т.е. практики) предлагаем разрешить href атрибут
для всех элемнетов в HTML, ну т.е. чтобы можно было написать <td href="my-cell-wise-link.htm">...</td>
но теоретики настаивают что линк это только <a href="">...</a> — это семантически корректно.
От слова "семантика" меня уже тошнит если честно. Оченно теоретики это слово любят.
Им можно много чего прикрыть ибо точного значения этого термина в контектсе HTML не существует.
Здравствуйте, McSeem2, Вы писали:
MS>И второе. "Контекстно-свободный" — это уродская калька с английского "context free". По-русски правильно говорить "контекстно-независимый".
Да ну? Разве "контекстно-независимый" это не уродская калька с английского "context-independent"?
Совсем забыл, что еще понравилось, хоть это и прозвучало в самом начале.
Ошибки в Вебе не исправляются.
Если какой-то браузер обрабатывает хоть какую-то ситуацию неправильно, то следующая его версия ситуацию не исправит никак. Потому что люди не бросят старый браузер в одночасье и не перейдут на новый.
Период стагнации с 2001-го года (когда Нетскейп ушел, а МС не выпускала новые версии ИЕ), благотворно повлиял на Веб. Этот период позволил Веб-технологиям стабилизироваться. Веб-разработчики смогли наконец-то создавать/использовать технологии, не боясь, что через 2 месяца новая версия какого-либо браузера сведет их все старания к нулю.
Теперь любые инновации/изменения в браузерах будут минимально разрушающими.
В 2005-м в МС провели исследование. Из 200 наиболее посещаемых сайтов только один был в standarts-compliant mode. За день до конференции таких сайтов уже было 98 из 200.
Пользователей Интернета — пол-миллиарда (500 000 000, 500 миллионов). И если предположить, что 48-49% сайтов — standarts-compliant, то МС просто не может себе теперь позволить внести изменения, которые приведут к неправильному отображению сайтов.
Таким образом производители браузеров стали своего рода заложниками существующих технологий и социума, которым стал Web.
Именно поэтому ни одной новой технологии не грозит скорое появление в браузерах — потому что оно is going to break a lot of things for a lot of people.
Ну и естественно понравилось, как CTO Оперы "уделал" IE Тест Acid2 одинаково отображается в ИЕ (год 2007) и в Opera 3.2 (год 1998)
КЛ>[]
КЛ>а мне на большинство английского не хватило
Там сложнее всего понять парня из ФайрФокса. Представитель МС предоставил самую насыщенную фактами информацию (в общем, то, что я процитировал, хотя часть из вступления "модератора" была). "Оперативник" говорил про acid2, про то, как их Opera Mobile, которая используется в Nintendo Wii, также проходит этот текст, и что у них появились новые пользователи благодаря Wii.
И в конце он предложил нативную поддержку звука и видео, показав внутренний билд Опреы, который использует OGG для показа видео. Они реализовали тэг video и несколько байндингов в Яваскрипт, позволяющие манипулировать видео и аудио на странице. ogg бл предложен, как кроссбраузерный вариант айдио/видео кодека из-за того, что с ним не возникнут патентные проблемы(об этом было сказано, обращаясь к парню из МС, у которой, видать, были проблемы с mp3).
В конце было сказано, что, несмотря на то, что народ из Apple был также приглашен, они постоянно отказываясь, мотивируя это тем, что "им надо писать код"
В общем, все Реально инфы было очень мало. Почти полноценная выжимка здесь
Вступление: Браузеры создают неудаляемые из веба баги
IE: мы не можем вводить серьезные изменения в существующие технологии, потому что от них зависит слишком много людей
Mozilla: комитеты не могут эффективно решать практические проблемы, хотя могут определить области этих проблем
Opera: все бразеры должны полноценно реализовать CSS и ввести нативную поддержку аудио и видео
Заключение: Ребята из Safari прийти отказались
Здравствуйте, McSeem2, Вы писали:
MS>Он явлется таковым по совершенно другой причине — там много прочего мусора.
Да нет. Судя по описанию на w3c — то основное различие между XML и SGML.
MS>В какой обработке? Человеком или парсером? Для парсера нужен только стэк и тривиальная логика. Это настолько тривиально, что и обсуждать не стоит.
Тривиальная логика? Ну-ну. В современном мире, при нынешнем развитии алгоритмов парсинга — иметь большой стек большая роскошь. Алгоритмы для парсинга построены чтобы мгновенно обрабатывать огромные массивы данных. А тут у нас даже со стеком совсем плохо получается. Например, получили два тега:
<a>
<b>
<c>
Это мы уже получили стек в два элемента и для третего элемента будет как минимум 2 сравнения имен. Как результат, количество сравнений в худшем случае можно округлить до m^(m-1). До линейного сложность снизить здесь нельзя. А большинство современных граматик парсятся в дерево вывода именно с линейной сложностью или близ того.
Кстати, в BNF такой язык хрен опишешь.
MS>Точно так же, как и в HTML. Но зато допускает вольности. Именно поэтому XHTML и продвигается с таким скрипом — никто не любит железобетонной необходимости. Как было справедливо замечено, если браузер будет капризничать от малейшей синтаксической некорректности, то его просто задавят более либеральные браузеры. Идея что SGML, что HTML в том, что какую бы белиберду я ни написал, должно отобразиться чоть что-то. А уж неявная необходимость зачитать все до конца перед отображением — вообще идиотизм. А если мне срочно надо прочитать нужную информацию, и она уже загрузилась, но соединение отвалилось на последнем </HTML>, то я в принципе ничего не смогу увидеть! Получается как с тупой логикой защиты батарейки в мобиле — он просто вырубается, чтобы не переразрядить священную блин батарейку! Да фиг бы с ней, с батарейкой, покуда она физически способра дать ток — пусть хоть издохнет вся, я потом новую куплю. Сам звонок может быть в миллион раз важнее и батарейки и мобилы. Точно так же и информация, пусть даже неправильно отформатированная может быть в миллион раз важнее этой дурацкой прихоти — ждать весь файл до конца.
Ты по моему делаешь некоторую ошибку. Ты подходишь к вопросу трансляции HTML как к вопросу трансляции XML. А они разные. Для XML — это структуры данных с неизвестной семантикой которую и не надо учитывать. Повторю что имя в закл. теге для XML — мусор который был важен только для SGML и при трансляции его можно не анализировать. Для построения дерева вывода, имя тега это всего лишь аттрибут. Важна только структура. При HTML (если я не прав, c-smile может меня поправить) мы можем при парсинге сделать имена тегов частью языка. И правила парсинга именно для данного тега. Будут некоторые фичи, типа расширения синтаксиса, но они могут быть легко описаны доп. правилами. И фактически, введя в синтаксис имена каждого конкретного тега мы получим алгоритм с линейной сложностью.
MS>Другой аспект. Если весь длиннющий XML написан в одну строчку, то имена в закрывающих тэгах тебе никак не помогут распознать что к чему. Все равно нужен некий beautificator, чтобы прочесть. Но это же в равной степени относится и к SGML — форматтер для него получается нисколько не сложнее форматтера XML. Получается, что если все нормально отформатировано с отступами, то имена в закрывающих тэгах не влияют на читаемость. А если не отформатировано, то они никак не способствуют читаемости. Опять же получается, что смысла в них нет никакого.
С одной стороны, любая неотформатированная (без табуляция) иерархическая структура хреново понимается. С другой стороны повторюсь, насчет сложности форматера — уже описал.
MS>Вот я и говорю, что получается парадокс — для чего придуманы XML и XHTML? Для написания людьми? — нет, поскольку в отличие от HTML и SGML не допускают вольностей. Для автогенерации? — тоже нет, поскольку повторение имен является совершенно излишним и дает ужасный перерасход. А главное — приводит к идиотским ситуациям, типа описанной выше.
Почему XML лучше чем SGML я вроде написал. Почему и кто лучше — HTML или XHTML — не знаю. С одной стороны мы можем интерпретировать XHTML как данные с помощью средств для XML. Но это бывает редко. С другой стороны — html редактируешь в нотепаде значительно чаще. И html в данном случае удобнее. Поэтому IMHO по сравнению с XHTML, HTML выглядит предпочтительнее.
Здравствуйте, Mamut, Вы писали:
КЛ>>>>[]
КЛ>>дальше парня из ff я не залазил ms'овский говорил наиболее понятно (для меня). Дядька из вступления тоже ничего так, улавливал суть.
M>Понятнее всех как раз говорил CTO Оперы
Здравствуйте, GlebZ, Вы писали:
GZ>Это мы уже получили стек в два элемента и для третего элемента будет как минимум 2 сравнения имен. Как результат, количество сравнений в худшем случае можно округлить до m^(m-1). До линейного сложность снизить здесь нельзя.
Можно.
hint: Хеш таблица.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
GZ>>Это мы уже получили стек в два элемента и для третего элемента будет как минимум 2 сравнения имен. Как результат, количество сравнений в худшем случае можно округлить до m^(m-1). До линейного сложность снизить здесь нельзя. WH>Можно. WH>hint: Хеш таблица.
Как было написана — вместе с хешем — худший случай будет m^(m-1) (поскольку для хеш таблицы — худший случай это O(n) )
Здравствуйте, GlebZ, Вы писали:
WH>>Можно. WH>>hint: Хеш таблица. GZ>Как было написана — вместе с хешем — худший случай будет m^(m-1) (поскольку для хеш таблицы — худший случай это O(n) )
Это смотря какой хеш.
hint: Сбалансированное дерево.
А если список ключей известен зарание то... perfect hash...
Короче в подавляющем большинстве случаев SGML парсится за линейное время. Ну в крайнем случае за n*log(n) и никаким квадратичнам временем тут и не пахнет.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>А если список ключей известен зарание то... perfect hash...
Если список ключей известен, то мы можем все это реализовать в лексере. Начинаешь подбивать исходную задачу под удобную тебе?
WH>Короче в подавляющем большинстве случаев SGML парсится за линейное время. Ну в крайнем случае за n*log(n) и никаким квадратичнам временем тут и не пахнет.
Между умножением и степенью — очень кардинальная разница. Для дерева — здесь степень. И соответвенно — оно нелинейно. Насчет квадратичности, тоже неверно. Для бинарного дерева, если средняя глубина вложения равна четырем (что немного и часто встречается) уже будет n^2.
Здравствуйте, GlebZ, Вы писали:
WH>>А если список ключей известен зарание то... perfect hash... GZ>Если список ключей известен, то мы можем все это реализовать в лексере. Начинаешь подбивать исходную задачу под удобную тебе?
Нет. Просто говорю о вариантах.
Болие того как правило набор тегов для конкретной задачи известен зарание.
WH>>Короче в подавляющем большинстве случаев SGML парсится за линейное время. Ну в крайнем случае за n*log(n) и никаким квадратичнам временем тут и не пахнет. GZ>Между умножением и степенью — очень кардинальная разница.
Это очевидно. Только не понятно к чему? GZ>Для дерева — здесь степень.
Какая степень? Ты о чем? GZ>И соответвенно — оно нелинейно.
Поиск в бинарном дереве да не линеен. Он log(n).
Но до этого у нас еще хеш есть.
И я честно говоря не знаю случаев когда значения хеш функции сильно пересекаются. Про заведомо плохие хеш функции не надо.
Единственный случай о котором я слышал это атака на стек IP в какойто ОС. Но там значения IP адресов специально подбирали. GZ>Насчет квадратичности, тоже неверно.
Где ты ее нашол? GZ>Для бинарного дерева, если средняя глубина вложения равна четырем (что немного и часто встречается) уже будет n^2.
Этого я совсем не понял.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Там сложнее всего понять парня из ФайрФокса. Представитель МС предоставил самую насыщенную фактами информацию (в общем, то, что я процитировал, хотя часть из вступления "модератора" была). "Оперативник" говорил про acid2, про то, как их Opera Mobile, которая используется в Nintendo Wii, также проходит этот текст, и что у них появились новые пользователи благодаря Wii.
Из FF вооюще какой-то левый чел пришел.
По идее должен быть Дэйвид Байрон — это человек уровня Криса Вилсона или Хаукама.
M>Вступление: Браузеры создают неудаляемые из веба баги M>IE: мы не можем вводить серьезные изменения в существующие технологии, потому что от них зависит слишком много людей
На самом деле самое интересное это то что "мы сейчас собрали опять всех бойцов в команду IE"
т.е. я так понимаю IE7 делался на коленках.
M>Mozilla: комитеты не могут эффективно решать практические проблемы, хотя могут определить области этих проблем
И даже этого оно не сказал толком.
M>Opera: все бразеры должны полноценно реализовать CSS и ввести нативную поддержку аудио и видео
Everbody knows what AJAX is — asynchronous javascript and xml — but there are now XML there anymore so ...
он предолжил несколько вариантов нового имени для этого безобразия, and we will see how it will evolve.
Я только не понял к чему у него был тот пассаж про компутер с зелеными рогами за 100 USD. Типа вот клевый компутер
но нас там нет потому как там только OpenSource, а мы не OpenSource.
M>Заключение: Ребята из Safari прийти отказались
c-smile wrote: > Я только не понял к чему у него был тот пассаж про компутер с зелеными > рогами за 100 USD. Типа вот клевый компутер > но нас там нет потому как там только OpenSource, а мы не OpenSource.
Это OLPC (http://en.wikipedia.org/wiki/OLPC), он вскоре может стать
очень популярной платформой (десятки миллионов штук).
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[5]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, c-smile, Вы писали:
CS>Вот буквально сейчас на WHATWG листе обсуждаем: CS>Мы c Daniel Glazman ( делал NVU ) (т.е. практики) предлагаем разрешить href атрибут CS>для всех элемнетов в HTML, ну т.е. чтобы можно было написать <td href="my-cell-wise-link.htm">...</td>
А что это будет значить? что всё содержимое тега есть ссылка на my-cell-wise-link.htm? Мне вот при первом, и даже втором прочтении показалось, что содержимое тега будет грузиться из ссылки
... << RSDN@Home 1.2.0 alpha rev. 675>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, WolfHound, Вы писали:
GZ>>Для дерева — здесь степень. WH>Какая степень? Ты о чем?
Точно. Прогнал я по поводу степени. Если учитывать именно сравнение строк, то будет умножение. Но все равно алгоритм достаточно тормозной по сравнению с большинством существующих синтаксических анализаторов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Re[6]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, _FRED_, Вы писали:
_FR>Здравствуйте, c-smile, Вы писали:
CS>>Вот буквально сейчас на WHATWG листе обсуждаем: CS>>Мы c Daniel Glazman ( делал NVU ) (т.е. практики) предлагаем разрешить href атрибут CS>>для всех элемнетов в HTML, ну т.е. чтобы можно было написать <td href="my-cell-wise-link.htm">...</td>
_FR>А что это будет значить? что всё содержимое тега есть ссылка на my-cell-wise-link.htm? Мне вот при первом, и даже втором прочтении показалось, что содержимое тега будет грузиться из ссылки
1-ое
Re[7]: Browser Wars Episode II: Attack of the DOMs
CS>>>Вот буквально сейчас на WHATWG листе обсуждаем: CS>>>Мы c Daniel Glazman ( делал NVU ) (т.е. практики) предлагаем разрешить href атрибут CS>>>для всех элемнетов в HTML, ну т.е. чтобы можно было написать <td href="my-cell-wise-link.htm">...</td>
_FR>>А что это будет значить? что всё содержимое тега есть ссылка на my-cell-wise-link.htm? Мне вот при первом, и даже втором прочтении показалось, что содержимое тега будет грузиться из ссылки
КЛ>1-ое
Хм. Жалко. Лучше бы второе... Было бы очегь удобно разбивать сайт на такие вот модули...
Зачем фреймов? Нечто вроде iframe, но выдающее только контент. И без проблем с размерами (я до сих пор, кстати, не знаю, как сделать, чтобы iframe растягивался на весь размер содерживого... )
<table>
<tr>
<td>какой-то там контент</td>
</tr>
<tr>
<td>какой-то там контент 2</td>
</tr>
<tr>
<td src="poll.php"></td>
</tr>
</table>
и подгружается оттудова опрос И вместо всякой шаблонной гадости получаем симпатичные модульные сайты без проблем...
В примере таблицы, но можно было бы забубенить и какой-нибудь CSS Zen Garden так же.
Здравствуйте, Mamut, Вы писали:
A>>Повторное открытие фреймов? M>Зачем фреймов? Нечто вроде iframe, но выдающее только контент. И без проблем с размерами (я до сих пор, кстати, не знаю, как сделать, чтобы iframe растягивался на весь размер содерживого... )
То, что ты предлагаешь — те же фреймы (пусть плавающие), что есть сейчас, только слегка доведённые до ума.
Re[5]: Browser Wars Episode II: Attack of the DOMs
c-smile wrote:
> Мы c Daniel Glazman ( делал NVU ) (т.е. практики) предлагаем разрешить > href атрибут > для всех элемнетов в HTML, ну т.е. чтобы можно было написать <td
Это делается с помощью xlink, и даже уже работает в FF (как минимум в svg).
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
>> Кстати №1: >> В Sciter есть простой визуализатор JSON >> см. sdk\samples\communications\jahoo-rpc\yahoo-image-search.htm >> — показывает структуру в виде дерева. C>Ой, спасибо. Вроде все уже договорились, что внешние графические C>редакторы для данных/кода — это suxxx. Все должно быть в plain text с C>удобными способами его редактирования.
Скорее гибрид plain-text с чем-то более навороченным. Как в Visual Studio — вроде текст,
но можно сворачивать блоки + подсветка неверных кусков сразу.
В принципе единственные преимущества plain-text — простота copy-paste и полнотекстового поиска.
Но это все хорошо когда все же большая часть информации по сути текстовая.
Я думаю что все же специализированные редакторы теоретически лучше, т.к. по определению не дадут сделать нехорошее .
Здравствуйте, Cyberax, Вы писали:
C>Я вот сейчас работаю с JSON, где вообще часто имен тэгов нет. Так вот, со вложенными структурами на несколько экранов очень неудобно работать — непонятно какая скобка что закрывает.
А что редактор это не показывает?
C>В языках программирования то же самое, но обычно циклы и другие вложенные структуры (кроме процедур/классов верхнего уровня, где вложенность не важна) не бывают очень большими. А вот при описании данных — элементарно получается.
Даже в языках программирования полезно бывает именовать параметры при вызове, даже где это и не обязательно. Просто улучшает читабельность. Пока вроде только в Python и Nemerle встречал.
C>ИМХО, XML достаточно удачно сбаллансирован. Все YAML и прочие JSONы обычно от него отличаются лишь закрывающими скобками, а тем не менее, считают это новым революционным изобретением и лучшей вещью since sliced bread.
Но это никакое не изобретение конечно, а вариация все тех же Лисповских S- и M-выражений.
C>Меня уже это достает — вот сегодня на собеседовании человек вещал о суперкрутости JSON и о том, что XML уже устарел и его пора выкидывать.
Андрей Хропов wrote: > C>Ой, спасибо. Вроде все уже договорились, что внешние графические > C>редакторы для данных/кода — это suxxx. Все должно быть в plain text с > C>удобными способами его редактирования. > Скорее гибрид plain-text с чем-то более навороченным. Как в Visual > Studio — вроде текст, > но можно сворачивать блоки + подсветка неверных кусков сразу.
Ну да. Но это уже относится к удобным средствам редактирования Как и
IDE, понимающие семантику этого текста.
> Я думаю что все же специализированные редакторы теоретически лучше, т.к. > по определению не дадут сделать нехорошее .
Графические? Да ни за что. Разве что в некоторых узких областях.
Posted via RSDN NNTP Server 2.1 beta
Sapienti sat!
Re[11]: Browser Wars Episode II: Attack of the DOMs
A>>>Повторное открытие фреймов? M>>Зачем фреймов? Нечто вроде iframe, но выдающее только контент. И без проблем с размерами (я до сих пор, кстати, не знаю, как сделать, чтобы iframe растягивался на весь размер содерживого... )
A>То, что ты предлагаешь — те же фреймы (пусть плавающие), что есть сейчас, только слегка доведённые до ума.
Ну, в принципе, да Но что плохого в плавающих, доведенных до ума фреймах? Да еще желательно unobtrusive. Чтобы не приходилось писать frame src="", а в (почти?) каждом элементе можно было написать <div src=""> или <trd src="">...
Здравствуйте, Mamut, Вы писали:
A>>>>Повторное открытие фреймов? M>>>Зачем фреймов? Нечто вроде iframe, но выдающее только контент. И без проблем с размерами (я до сих пор, кстати, не знаю, как сделать, чтобы iframe растягивался на весь размер содерживого... )
A>>То, что ты предлагаешь — те же фреймы (пусть плавающие), что есть сейчас, только слегка доведённые до ума.
M>Ну, в принципе, да Но что плохого в плавающих, доведенных до ума фреймах? Да еще желательно unobtrusive. Чтобы не приходилось писать frame src="", а в (почти?) каждом элементе можно было написать <div src=""> или <trd src="">...
Дим, помнишь про проблемы фреймов с навигацией и индексацией?
То, что ты может быть имеешь в виду можно решить с помощью SSI или типа того. Но наружу это должно выглядеть цельной страницей, а то иметь странички являющиеся "оборвышами" сайта — не очень хорошее дело.
Re[12]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, Mamut, Вы писали:
A>>То, что ты предлагаешь — те же фреймы (пусть плавающие), что есть сейчас, только слегка доведённые до ума. M>Ну, в принципе, да Но что плохого в плавающих, доведенных до ума фреймах? Да еще желательно unobtrusive. Чтобы не приходилось писать frame src="", а в (почти?) каждом элементе можно было написать <div src=""> или <trd src="">...
Может они и будут "правильно" отображаться, но ты получишь впридачу все остальные проблемы нынешних фреймов.
Re[10]: Browser Wars Episode II: Attack of the DOMs
Здравствуйте, Mamut, Вы писали:
M>Зачем фреймов? Нечто вроде iframe, но выдающее только контент. И без проблем с размерами (я до сих пор, кстати, не знаю, как сделать, чтобы iframe растягивался на весь размер содерживого... ) M>и подгружается оттудова опрос
В общем-то ты и сейчас можешь подобное сделать. Написать
<td src="poll.php"></td>
а и скрипт впридачу. который эти src обрабатывает и грузит, что надо.
Тест Acid2 одинаково отображается в ИЕ (год 2007) и в Opera 3.2 (год 1998) 
