Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, c-smile, Вы писали:
MC>>>4) Или разница только в валидации? MC>>>5) Если только в валидации то как UA будет понимать по какому стандарту отображать страницу? Походу ответ на третий вопрос — да. А на 4-й — нет?
CS>>Что значит "по какому стандарту отображать страницу"? Отображение задается CSS который ортогонален HTML.
MC>Ну допустим, между HTML 4.01 Transitional & Strict в некоторых ситуациях будет большая разница в отображении, т.е. в зависимости от DOCTYPE браузер будет по разному отображать страницу.
А теперь забудь это все к ядреной фене ибо к реалиям это не имеет никакого отношения.
Вот тебе пример:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<body>
<table bgcolor="yellow"><tr><td>WooHoo!</td></tr></table>
</body>
</html>
Strict и в ём bgcolor видишь? Если загрузишь это дело в свой любимый броузер то увидишь желтый background у таблицы. Хотя на заборе написано что он как бы не должен поддерживаеться.
Еще короче, если в начале страницы написано
<!DOCTYPE HTML {фигня всяка или ничего} >
то это инструкция броузеру грузить стандартный default style sheet. Он один на все разные DOCTYPEs.
Если же <!DOCTYPE нет то грузится quirks style sheet. Высё.
Отличие только между no-doctype (quirks mode) и всем остальным (обрати внимание на размер шрифта в таблице).
В IE была бага когда TD не наследовал font style от контейнера — это оно.
Ставь в своих документах <!DOCTYPE html> и забудь про эту проблему.
Блин, какая-то религия уже вокруг этих doctypes возникла ... Какой-то кретин их придумал и народ "верую" затянул.
Ну чего бы атрибут какой не ввести типа <html standard>...</html> уж если сильно надо...
А еще Шириданы всяки с XHTML пламенем в глазах ... Жуть.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, c-smile, вы писали: c>> Медальки "W3C HTML Working Group, Invited Expert" достаточно тебе будет?
S>Недостаточно, раз ты с этой медалькой утверждаешь что XHTML помер, а также в качестве доказательств приводишь некий проект гугла, а не w3c.
Какие ещё доказательства с проектом от гугла? Давай изъясняйся толком.
HTML 3.2 например http://www.w3.org/TR/REC-html32
есть действующая рекомендация. Но сказать что HTML 3.2 жив наверное уже нельзя.
А XHTML помер в том смысле что народ признал что XML не может быть в принципе использован как средство доставки контента (страниц) с сервера на клиент.
Одна из проблем с XML состоит в том что XML processor обязан игнорировать не well-formed документы.
См. например: http://www.w3.org/TR/2008/REC-xml-20081126/#sec-well-formed .
Очевидное следствие: частично загруженная страница не есть well-formed документ. Т.е. XHTML по природе своей не допускает incremental rendering.
То же самое ограничение и с функцией document.write() — в XHTML она просто не доступна. Есть еще несколько ограничений.
В HTML например, элементы <html> и <body> как и другие optional. <html> может содержать другие <html>. В XHTML всё не так.
Ты в принципе можешь сериализовать свой stuff как XML (например использовать <br/> вместо <br>) но я рекомендую не указывать DOCTYPE как именно XHTML.
Будущего у XML как языка разметки Web страниц особого нет. По многим причинам. Скажем если твоя страница собирается как результат разных модулей то ты должен гарантирвать что все компоненты выдают именно XML. А если например там еще участвуют фрагменты введенные человеком то вообще все плохо.
Скажем у тебя вдруг проскочила конструкция: "<p>One<br>Two</p>". В случае XHTML весь твой сайт идет в /dev/null. Броузер не обязан показывать такую страницу т.к. ты сам его об этом попросил.
Польза от XMLности некоего markup состоит в тех случаях когда все 100% контента генерируются машиной. И потребляются оной
S>Пройди еще раз тест (или что там надо сделать кстати? мне тоже интересно. ) на эту медальку.
Нет там тестов Напиши свой HTML/CSS процессор с достаточным market share и тебя пригласят.
К слову h-smile core (то что внутри HTMLayout) по количеству копий на user machines уже перебил скажем Operу . Во всяком случае в практически любом компьютерном магазине в Штатах и Канады можно купить продукт/коробочку в которой есть мой код. Т.е. W3C использует школьную линейку в качестве критерия
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, c-smile, Вы писали:
CS>>...
MC>Я правильно понимаю, что на данный момент сайт лучше всего делать с HTML 4.01 Strict?
HTML5 он в себя включает в качестве базы HTML4 ( отличия )
Т.е. пиши в начале:
<!DOCTYPE html>
и будет достаточно. Тем самым ты говоришь что ты делаешь стандартный HTML и всякие quirks modes тебя не интересуют.
И твой сайт будет работать и для старых и для новых UAs.
On 16/03/2010 02:56, c-smile wrote:
> Стирать всю красоту с экрана и писать Error at line ... Not valid XML?
Хотя если подумать, так наверное даже правильно. Криворукие программисты будут сразу получать по голове. Ведь никого сейчас не удивляет, что при обращении по неправильному указателю программа тут же падает по access violation. И вроде никто не хочет, чтобы она пыталась работать дальше как получится.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, MozgC, Вы писали:
MC>Здравствуйте, c-smile, Вы писали:
MC>>>Я правильно понимаю, что на данный момент сайт лучше всего делать с HTML 4.01 Strict?
CS>>HTML5 он в себя включает в качестве базы HTML4 ( отличия ) CS>>и будет достаточно. Тем самым ты говоришь что ты делаешь стандартный HTML и всякие quirks modes тебя не интересуют. CS>>И твой сайт будет работать и для старых и для новых UAs.
MC>UA — это браузер?
User Agent это групповое имя приложений которые интерпретируют HTML, браузер в том числе.
MC>А разве такой доктайп поддерживается старыми браузерами? Как будут себя вести современные и новые браузеры с таким doctype? Я думал что этот doctype говорит об использовании HMTL5. MC>Раскрой, пожалуйста, этот вопрос чуть подробнее?
DOCTYPE is only needed to enable standards mode for documents written using the HTML syntax. Browsers already do this for <!DOCTYPE html>.
На самом деле (т.е. на практике) все свелось к тому что нужно различать IE content с его багами и "современный" контент.
Наличие <!DOCTYPE... говорит о том что контент "современный" и CSS отрабатывается стандартным образом.
Парсинг HTML во всех UA из большой пятерки делается одним и тем же кодом для всех <!DOCTYPE вариаций (насколько я знаю).
Т.е. даже XHTML парсится как HTML, во всяком случае использует те же правила error recovery.
Т.е. ты можешь написать мусор типа
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<body>
Argh!
</html>
(что явно не есть XML) и любой браузер его благополучно покажет. А те браузеры что это не покажут на рынке не задержатся.
Т.е. XHTML это фикция. HTML/XHTML имеет смысл толко когда ты сериализуешь живой DOM. В этом случае ты можешь попросить выдавать нечто что может быть обработанно XML парсером потом.
При чтение XMLость HTMLя до фени.
On 16/03/2010 00:22, c-smile wrote:
> .>Как это? А SAX-parser? > А какое отношение SAX-parser имеет к rendering?
Парсишь и тут же рендеришь. А каким же образом XHTML не допускает incremental rendering?
> Я тоже так считаю но тем не менее в HTML5 оно есть и будет. Как же еще > то тебя рекламу донести
Мда...
А чем DOM-фунцкии плохи для рекламы?
>> > причинам. Скажем если твоя страница собирается как результат разных >> > модулей то ты должен гарантирвать что все компоненты выдают именно XML. > .>Это явно лучше, чем просто "набор байт", который непонятно как собирать. > Что именно "явно лучше"?
Два куска текста "X<Y" и "A>B" как собрать? И что должно получиться?
И ещё интересно как там с кодировками...
> По поводу "непонятно как собирать". Собственно HTML5 он как раз об этом > — это первый стандарт в котором постулируются error recovery механизмы. > Т.е. фактически markup: > <body>Ку-ку!</html> > валиден в том смысле что язык допускает пропущенные тэги и специфицирует > способ их восстановления.
В общем я не понимаю накой. Специфицировать кривые руки программистов?
> .>И правильно. Хоть какая-то защита от XSS. > Это не защита. В смысле вообще.
Почему?
> .>А если придёт конструкция "<p>One<brTwo</p>" — что должно нарисоваться > и почему? > > If a user agent encounters an element it does not recognize, it > should try to render the element's content.
Так это было с рождения HTML,если элемент неизвестен, то игнорировать.
А тут другой случай. "<brTwo" это элемент такой? Как интерпретировать совершенный бред в разметке?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Приветствую, c-smile, вы писали:
c> S>Недостаточно, раз ты с этой медалькой утверждаешь что XHTML помер, а также в качестве доказательств приводишь некий проект гугла, а не w3c. c> Какие ещё доказательства с проектом от гугла? Давай изъясняйся толком. Тут
ты ссылался именно на какойто левый проект от гугла, а именно на матрицу совместимости.
c> HTML 3.2 например c> http://www.w3.org/TR/REC-html32 c> есть действующая рекомендация. Но сказать что HTML 3.2 жив наверное уже нельзя.
С этим согласен.
c> А XHTML помер в том смысле что народ признал что XML не может быть в принципе использован как средство доставки контента (страниц) с сервера на клиент. c> Одна из проблем с XML состоит в том что XML processor обязан игнорировать не well-formed документы.
Правильно, должен. Обязан.
c> См. например: http://www.w3.org/TR/2008/REC-xml-20081126/#sec-well-formed . c> Очевидное следствие: частично загруженная страница не есть well-formed документ. Т.е. XHTML по природе своей не допускает incremental rendering.
Тоже было бы неплохо — не было бы километровых страниц, так как все стремились бы максимально ужать страницу для быстрейшего отображения.
c> То же самое ограничение и с функцией document.write() — в XHTML она просто не доступна. Есть еще несколько ограничений.
С трудом представляю для чего оно нужно. Все готовим на сервере и отсылаем браузеру. Потом работаем с DOM
c> В HTML например, элементы <html> и <body> как и другие optional. <html> может содержать другие <html>. В XHTML всё не так.
Очень правильно, нефиг всякий бред в браузер пихать.
c> Ты в принципе можешь сериализовать свой stuff как XML (например использовать <br/> вместо <br>) но я рекомендую не указывать DOCTYPE как именно XHTML.
А я рекомендую указывать и стремиться к strict
c> Будущего у XML как языка разметки Web страниц особого нет. По многим причинам. Скажем если твоя страница собирается как результат разных модулей то ты должен гарантирвать что все компоненты выдают именно XML. А если например там еще участвуют фрагменты введенные человеком то вообще все плохо.
Да, плохо. Но вполне можно обработать и привести к правильному стилю.
c> Скажем у тебя вдруг проскочила конструкция: "<p>One<br>Two</p>". В случае XHTML весь твой сайт идет в /dev/null. Броузер не обязан показывать такую страницу т.к. ты сам его об этом попросил.
Было бы просто замечательно. Но к сожалению браузеры все показывают, даже явный бред...
c> Польза от XMLности некоего markup состоит в тех случаях когда все 100% контента генерируются машиной. И потребляются оной
Генерируется сервером и потребляется браузером. И там и там машины. Пользовательский введеный текст обрабатывать и еще раз обрабатывать, приводя к божескому виду.
c> S>Пройди еще раз тест (или что там надо сделать кстати? мне тоже интересно. ) на эту медальку. c> Нет там тестов Напиши свой HTML/CSS процессор с достаточным market share и тебя пригласят.
В смысле — рендер? Или что понимается под "процессор"?
c> К слову h-smile core (то что внутри HTMLayout) по количеству копий на user machines уже перебил скажем Operу . Во всяком случае в практически любом компьютерном магазине в Штатах и Канады можно купить продукт/коробочку в которой есть мой код. Т.е. W3C использует школьную линейку в качестве критерия
Это еще не значит что ты гуру в хтмл. Впрочем и я не гуру.
Здравствуйте, ., Вы писали:
.>On 16/03/2010 02:56, c-smile wrote:
>> Стирать всю красоту с экрана и писать Error at line ... Not valid XML? .>Хотя если подумать, так наверное даже правильно. Криворукие программисты будут сразу получать по голове.
Угу. А вместе с ними и юзера.
Тут всё просто. Пользователи для стандартов или стандарты для пользователей? Данные для xml или xml для данных? Если второе, то, естественно, отображение контента, пусть даже и несколько криво, первично. Значит надо пытаться показать что можно как можно.
Если первое — да, показываем ошибку, юзера матерятся, и все, кроме самых пряморуких программистов посылают такие стандарты на йух. В результате пряморукие программисты счастливы, всё пользователи предпочитают "менее правильные" броузеры, которые "бред интерпритируют бредово. Но интерпретируют".
.>Ведь никого сейчас не удивляет, что при обращении по неправильному указателю программа тут же падает по access violation.
А еще сейчас никого не удивляет, что после этого можно прогу просто прибить и работать дальше. А надо, чтоб такие ситуации систему валили, как раньше. Отвыкли получать по голове по полной программе!
Нет, не надо.
Впрочем твое решение не проходит Strict XHTML 1.1
Validation Output: 2 Errors
1. Error Line 9, Column 74: "disabled" is not a member of a group specified for any attribute
<link rel="stylesheet" href="style/light.css" type="text/css" disabled />
2. Error Line 9, Column 72: Specification mandate value for attribute disabled
<link rel="stylesheet" href="style/light.css" type="text/css" disabled />
Здравствуйте, Sheridan, Вы писали:
c>> S>Пройди еще раз тест (или что там надо сделать кстати? мне тоже интересно. ) на эту медальку. c>> Нет там тестов Напиши свой HTML/CSS процессор с достаточным market share и тебя пригласят. S>В смысле — рендер? Или что понимается под "процессор"?
c>> К слову h-smile core (то что внутри HTMLayout) по количеству копий на user machines уже перебил скажем Operу . Во всяком случае в практически любом компьютерном магазине в Штатах и Канады можно купить продукт/коробочку в которой есть мой код. Т.е. W3C использует школьную линейку в качестве критерия S>Это еще не значит что ты гуру в хтмл. Впрочем и я не гуру.
По идее чтобы поиметь какое-то представление о предмете нужно имплементирвать этот самый предмет. В той или иной степени.
Скажем когда ты вбиваешь руками таблицу поддерживаемых тэгов ты как минимум будешь знать состав HTML элементов на уровне моторных рефлексов.
А когда тебя будут бодать лет так пять тем что IE поддерживает <link disabled> и всякое такое прочее, а ты нет, то как-то поневоле в предмет вникаешь.
Короче, в нашем деле профи это тот человек который написал продукт (модуль,сайт,библиотеку) своими руками. Чего тебе и желаю. Ну доведи уже ты что-нибудь до конца может твои комплексы и уйдут, а то как-то тоскливо с тобой бодаться каждый раз. Кто-то тебе сказал что XHTML это типа круто, а ты и поверил.
XML он хорош в своей области. Но далеко не везде. В HTML5 кстати вообще не собирались сериализацию в XML делать. Там есть слова про XHTML но так — в виде отмазки.
On 15/03/2010 01:42, c-smile wrote: > Т.е. XHTML по природе своей не допускает incremental rendering.
Как это? А SAX-parser?
> То же самое ограничение и с функцией document.write() — в XHTML она > просто не доступна. Есть еще несколько ограничений.
А она просто и не нужна.
> причинам. Скажем если твоя страница собирается как результат разных > модулей то ты должен гарантирвать что все компоненты выдают именно XML.
Это явно лучше, чем просто "набор байт", который непонятно как собирать.
> А если например там еще участвуют фрагменты введенные человеком то > вообще все плохо. > Скажем у тебя вдруг проскочила конструкция: "<p>One<br>Two</p>". В > случае XHTML весь твой сайт идет в /dev/null. Броузер не обязан > показывать такую страницу т.к. ты сам его об этом попросил.
И правильно. Хоть какая-то защита от XSS.
А если придёт конструкция "<p>One<brTwo</p>" — что должно нарисоваться и почему?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
On 15/03/2010 14:46, kochetkov.vladimir wrote:
> <p>Foo:<?phpecho ($_GET['foo'] ? $_GET['foo'] :'undefined'); ?></p>
> получаем старый-добрый XSS
Это понятно. По большому счёту это не генерация xml, а обычный текст.
Я не то имел в виду, а client-side, всякий там javascript и document.write().
Если же работать с XML как c XML, а не с текстом, то таких проблем не будет.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, MozgC, Вы писали:
MC>Еще все-таки уточняющие вопросы: MC>1) Все ли браузеры (и как дела со старыми версиями, например IE6) понимают <!DOCTYPE HTML> ?
Они его не понимают, но незнакомый доктайп включает стандартный рендеринг, поэтому этот доктайп — то, что доктор прописал.
Здравствуйте, yoriсk.kiev.ua, Вы писали:
>>> Стирать всю красоту с экрана и писать Error at line ... Not valid XML? .>>Хотя если подумать, так наверное даже правильно. Криворукие программисты будут сразу получать по голове. YKU>Угу. А вместе с ними и юзера. YKU>Тут всё просто. Пользователи для стандартов или стандарты для пользователей? Данные для xml или xml для данных? Если второе, то, естественно, отображение контента, пусть даже и несколько криво, первично. Значит надо пытаться показать что можно как можно. YKU>Если первое — да, показываем ошибку, юзера матерятся, и все, кроме самых пряморуких программистов посылают такие стандарты на йух. В результате пряморукие программисты счастливы, всё пользователи предпочитают "менее правильные" броузеры, которые "бред интерпритируют бредово. Но интерпретируют".
Дело в том, что реализовать стандарт, который описывает возможные правильные конструкции — это ещё возможно. А однозначно интерпретировать все возможные ошибки — нельзя, имхо (если я что-то не знаю, разъясните, плз). В итоге мы никуда не уйдём от ситуации "а у меня в IE работает, ну а FF... да неохота возиться, мне за это не платят", "safari на ipod? а что такое safari?".
.>>Ведь никого сейчас не удивляет, что при обращении по неправильному указателю программа тут же падает по access violation. YKU>А еще сейчас никого не удивляет, что после этого можно прогу просто прибить и работать дальше. А надо, чтоб такие ситуации систему валили, как раньше. Отвыкли получать по голове по полной программе!
Эээ.. а это тут причём? Я не предлагаю, чтобы невалидный XML валил браузер. Работай дальше, но не с этим кривым сайтом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Приветствую, Mamut, вы писали:
M> c>> А еще Шириданы всяки с XHTML пламенем в глазах ... Жуть. M> S>Признаюсь я расстроился. Ожидал что html5 будет еще боле жесток, M> Зачем?
Чтобы заставлять программистов писать более ровный код, которыей
а) более быстро было бы можно обрабатывать изза исключения из браузера кода "а нука угадаю я, что тут хотят нарисовать"
б) одинаково бы отображался везде, от мобил до плейстейшн, во всяком случае это было бы проще реализовать.
Здравствуйте, Sheridan, Вы писали:
S>Чтобы заставлять программистов писать более ровный код, которыей S>а) более быстро было бы можно обрабатывать изза исключения из браузера кода "а нука угадаю я, что тут хотят нарисовать" S>б) одинаково бы отображался везде, от мобил до плейстейшн, во всяком случае это было бы проще реализовать.
S>А опять возвращаются к разброду и шатаниям...
Разработчики браузеров низачто такой "стандарт" реализовывать не станут. Они же не враги себе и своим пользователям.
Здравствуйте, Sheridan, Вы писали:
S>А опять возвращаются к разброду и шатаниям...
Дилемма заключенного получается. Если броузер A строже, чем броузер Б, то юзеры не станут лезть в XML. Они просто скажут «броузер А не работает со вконтакте-ру!», чем всё и кончится. Смысл будет, только если все броузеры разом ужесточат свои требования, что нереально. И то, в интернете гигабайты старых страничек, которые хорошо бы продолжать отображать несмотря на всю нестандартность.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, c-smile, Вы писали:
CS>>>>Представь себе, что ты пишешь RSS-интегратор. Там html идет из разных источников, тебе не подконтрольных. RO>>>libtidy CS>>Где libtidy? В browser или на сервере?
RO>Там, где несколько text/html склеиваются в один application/atom+xml. Формат же для машинной обработки, он должен быть действительным XML.
Ты не понял. Скажем есть google reader какой. Он показывает контент (в т.ч. html) поступющий из разных источников. На одной странице.
Ты можешь гарантировать что у тебя всегда валидный xhtml выхлоп будет?
Здравствуйте, hattab, Вы писали:
h>> Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги). H>Несмотря на то, что тема протухла, думаю будет интересно... Опера умеет отрисовывать SVG-картинки по мере их загрузки, а SVG это таки XML.
Интересно, а что происходит при обрыве связи?
Да как бы вообще странно считать что xml плох в этом отношении.
Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Приветствую, kochetkov.vladimir, вы писали:
k> *Шепотом* крайне рекомендую потратить минут 10 на изучения вопроса о роде деятельности твоего собеседника
Да знаю я что он пишет. Это не означает что он обязательно гуру в хтмл
Приветствую, c-smile, вы писали:
c> S>html тоже учить надо, как ни странно... c> Угу. Надо. Учи.
Угу. Учу.
c> Здесь вот есть compatibility matrix: c> http://code.google.com/p/doctype/wiki/LinkDisabledAttribute
Это ссылку на куда ты мне дал? Ты мне на w3c ссылку давай.
Doctype is a Google-sponsored open encyclopedia and reference library for developers of web applications. By web developers, for web developers.
Это что вообще за хрень и какое отношение оно имеет к стандартам?
c> Вот здесь он уже введен в HTML5 c> http://www.w3.org/TR/html5/semantics.html#the-link-element
Вот это другое дело. Но в моем случае управлять disabled у кучи подлинкованных стилей пожалуй на порядок сложнее, чем тупо заменить единственный подлинкованный стиль.
c> А с XHTML 1.1 ты отстал на 9 лет. Помер XHTML ужо.
А вот это ты вообще помоему ляпнул чушь. XHTML 1.1 это действующий стандарт. XHTML 2.0 недописан и над ним прекращена работа вообще в пользу html5. html5 также недописан, но драфт обновляется чуть ли не каждый день.
k>> *Шепотом* крайне рекомендую потратить минут 10 на изучения вопроса о роде деятельности твоего собеседника S>Да знаю я что он пишет. Это не означает что он обязательно гуру в хтмл
Не спорю, не спорю. Тихонько удаляюсь, ибо мешать объяснять c-smile'у на пальцах про стандарты HTML ни в коем разе не собирался
Приветствую, c-smile, вы писали: c> Медальки "W3C HTML Working Group, Invited Expert" достаточно тебе будет?
Недостаточно, раз ты с этой медалькой утверждаешь что XHTML помер, а также в качестве доказательств приводишь некий проект гугла, а не w3c.
Пройди еще раз тест (или что там надо сделать кстати? мне тоже интересно. ) на эту медальку.
Приветствую, MozgC, вы писали:
MC> Я правильно понимаю, что на данный момент сайт лучше всего делать с HTML 4.01 Strict?
Интересно, что ц-смайл ответит
Приветствую, kochetkov.vladimir, вы писали:
k> Не спорю, не спорю. Тихонько удаляюсь, ибо мешать объяснять c-smile'у на пальцах про стандарты HTML ни в коем разе не собирался
Хреново он объясняет... Его послушать, так все правила надо вообще убрать. Что после этого будет — объяснять?
Здравствуйте, c-smile, Вы писали:
CS>Скажем у тебя вдруг проскочила конструкция: "<p>One<br>Two</p>". В случае XHTML весь твой сайт идет в /dev/null. Броузер не обязан показывать такую страницу т.к. ты сам его об этом попросил.
Здравствуйте, c-smile, Вы писали:
MC>>Я правильно понимаю, что на данный момент сайт лучше всего делать с HTML 4.01 Strict?
CS>HTML5 он в себя включает в качестве базы HTML4 ( отличия ) CS>и будет достаточно. Тем самым ты говоришь что ты делаешь стандартный HTML и всякие quirks modes тебя не интересуют. CS>И твой сайт будет работать и для старых и для новых UAs.
UA — это браузер?
А разве такой доктайп поддерживается старыми браузерами? Как будут себя вести современные и новые браузеры с таким doctype? Я думал что этот doctype говорит об использовании HMTL5.
Раскрой, пожалуйста, этот вопрос чуть подробнее?
On 15/03/2010 11:38, kochetkov.vladimir wrote:
> Как правило, при эксплуатации XSS ничего не мешает "генерить" на выходе > strict-html.
При генерации xml такой функции как "вставить кусок текста введённый пользователем" просто нет. Приходится явно всё обрабатывать, иначе всё будет выводиться аккуратно заэскейпленное, как в SQL bind-параметры.
Т.е. этот strict-html нужно генерить явно, а не как сейчас: "упс, а тут мы забыли заэскейпить".
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
k>> Не спорю, не спорю. Тихонько удаляюсь, ибо мешать объяснять c-smile'у на пальцах про стандарты HTML ни в коем разе не собирался S>Хреново он объясняет... Его послушать, так все правила надо вообще убрать. Что после этого будет — объяснять?
c>> Медальки "W3C HTML Working Group, Invited Expert" достаточно тебе будет?
S>Недостаточно, раз ты с этой медалькой утверждаешь что XHTML помер, а также в качестве доказательств приводишь некий проект гугла, а не w3c. S>Пройди еще раз тест (или что там надо сделать кстати? мне тоже интересно. ) на эту медальку.
Перевожу специально для тупых:
«Рабочая группа HTML, пришлашенный эксперт».
Никакими тестами ты не станешь приглашенным экспертом в рабочую группу HTML.
А то, что показал тебе c-smile — 'то просто таблица совместимости, собранная добрыми дядями в одном месте, чтобы всякие идиоты могли, глядя на нее, сразу видеть, что к чему, а не лазить в поисках той же информации по десяткам других сайтов, и натыкаться на особенности реализации той или иной фичи в разных браузерах
Здравствуйте, ., Вы писали:
.>On 15/03/2010 11:38, kochetkov.vladimir wrote:
>> Как правило, при эксплуатации XSS ничего не мешает "генерить" на выходе >> strict-html. .>При генерации xml такой функции как "вставить кусок текста введённый пользователем" просто нет. Приходится явно всё обрабатывать, иначе всё будет выводиться аккуратно заэскейпленное, как в SQL bind-параметры.
Здравствуйте, ., Вы писали:
.>On 15/03/2010 14:46, kochetkov.vladimir wrote:
>> <p>Foo:<?phpecho ($_GET['foo'] ? $_GET['foo'] :'undefined'); ?></p>
>> получаем старый-добрый XSS .>Это понятно. По большому счёту это не генерация xml, а обычный текст. .>Я не то имел в виду, а client-side, всякий там javascript и document.write(). .>Если же работать с XML как c XML, а не с текстом, то таких проблем не будет.
Здравствуйте, ., Вы писали:
.>On 15/03/2010 01:42, c-smile wrote: >> Т.е. XHTML по природе своей не допускает incremental rendering. .>Как это? А SAX-parser?
А какое отношение SAX-parser имеет к rendering?
>> То же самое ограничение и с функцией document.write() — в XHTML она >> просто не доступна. Есть еще несколько ограничений. .>А она просто и не нужна.
Я тоже так считаю но тем не менее в HTML5 оно есть и будет. Как же еще то тебя рекламу донести
>> причинам. Скажем если твоя страница собирается как результат разных >> модулей то ты должен гарантирвать что все компоненты выдают именно XML. .>Это явно лучше, чем просто "набор байт", который непонятно как собирать.
Что именно "явно лучше"?
По поводу "непонятно как собирать". Собственно HTML5 он как раз об этом — это первый стандарт в котором постулируются error recovery механизмы.
Т.е. фактически markup:
<body>Ку-ку!</html>
валиден в том смысле что язык допускает пропущенные тэги и специфицирует способ их восстановления.
>> А если например там еще участвуют фрагменты введенные человеком то >> вообще все плохо. >> Скажем у тебя вдруг проскочила конструкция: "<p>One<br>Two</p>". В >> случае XHTML весь твой сайт идет в /dev/null. Броузер не обязан >> показывать такую страницу т.к. ты сам его об этом попросил. .>И правильно. Хоть какая-то защита от XSS.
Это не защита. В смысле вообще.
.>А если придёт конструкция "<p>One<brTwo</p>" — что должно нарисоваться и почему?
If a user agent encounters an element it does not recognize, it should try to render the element's content.
Здравствуйте, c-smile, Вы писали:
MC>>А разве такой доктайп поддерживается старыми браузерами? Как будут себя вести современные и новые браузеры с таким doctype? Я думал что этот doctype говорит об использовании HMTL5. MC>>Раскрой, пожалуйста, этот вопрос чуть подробнее?
CS>
CS>DOCTYPE is only needed to enable standards mode for documents written using the HTML syntax. Browsers already do this for <!DOCTYPE html>.
CS>http://www.w3.org/TR/html5-diff/#doctype
CS>На самом деле (т.е. на практике) все свелось к тому что нужно различать IE content с его багами и "современный" контент. CS>Наличие <!DOCTYPE... говорит о том что контент "современный" и CSS отрабатывается стандартным образом. CS>Парсинг HTML во всех UA из большой пятерки делается одним и тем же кодом для всех <!DOCTYPE вариаций (насколько я знаю). CS>Т.е. даже XHTML парсится как HTML, во всяком случае использует те же правила error recovery.
1) Я правильно понимаю, что и DOCTYPE HTML 4.01 Strict и DOCTYPE HTML просто сообщают UA что надо включить Standards mode и использовать соответствующий стандарт (HTML 4.01 для DOCTYPE HTML 4.01 Strict и HTML5 для DOCTYPE HTML) при отрисовке страницы?
2) А DOCTYPE HTML 4.01 Transitional сообщает что надо включать Almost standards mode?
3) Будет ли разница в отображении страницы при указании DOCTYPE HTML 4.01 Strict и при указании DOCTYPE HTML?
4) Или разница только в валидации?
5) Если только в валидации то как UA будет понимать по какому стандарту отображать страницу? Походу ответ на третий вопрос — да. А на 4-й — нет?
Сорри за столько вопросов. То ли я тупой, то ли тема какая-то заморочная..
CS>Т.е. ты можешь написать мусор типа CS>
CS><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
CS><body>
CS> Argh!
CS></html>
CS>
CS>(что явно не есть XML) и любой браузер его благополучно покажет. А те браузеры что это не покажут на рынке не задержатся. CS>Т.е. XHTML это фикция. HTML/XHTML имеет смысл толко когда ты сериализуешь живой DOM. В этом случае ты можешь попросить выдавать нечто что может быть обработанно XML парсером потом. CS>При чтение XMLость HTMLя до фени.
Здравствуйте, MozgC, Вы писали:
CS>>На самом деле (т.е. на практике) все свелось к тому что нужно различать IE content с его багами и "современный" контент. CS>>Наличие <!DOCTYPE... говорит о том что контент "современный" и CSS отрабатывается стандартным образом. CS>>Парсинг HTML во всех UA из большой пятерки делается одним и тем же кодом для всех <!DOCTYPE вариаций (насколько я знаю). CS>>Т.е. даже XHTML парсится как HTML, во всяком случае использует те же правила error recovery.
MC>1) Я правильно понимаю, что и DOCTYPE HTML 4.01 Strict и DOCTYPE HTML просто сообщают UA что надо включить Standards mode и использовать соответствующий стандарт (HTML 4.01 для DOCTYPE HTML 4.01 Strict и HTML5 для DOCTYPE HTML) при отрисовке страницы?
HTML 4.01 и HTML5 с точки зрения parsing идентичны. В HTML5 есть новые фичи.
Т.е. HTML5 броузер будет парсить HTML 4.01 как будто это HTML5. Какой бы там DOCTYPE не был.
MC>2) А DOCTYPE HTML 4.01 Transitional сообщает что надо включать Almost standards mode?
Проблема с Transitional в том что никто толком не знает что такое "Almost standards mode". У Мозиллы свое понятие о том а у IE другое.
И обрати внимание на дату документа: https://developer.mozilla.org/en/Gecko's_%22Almost_Standards%22_Mode
MC>3) Будет ли разница в отображении страницы при указании DOCTYPE HTML 4.01 Strict и при указании DOCTYPE HTML?
Не должно быть разницы если не используются новые фичи HTML5.
MC>4) Или разница только в валидации? MC>5) Если только в валидации то как UA будет понимать по какому стандарту отображать страницу? Походу ответ на третий вопрос — да. А на 4-й — нет?
Что значит "по какому стандарту отображать страницу"? Отображение задается CSS который ортогонален HTML.
MC>Сорри за столько вопросов. То ли я тупой, то ли тема какая-то заморочная..
Просто надо понимать разницу между HTML и CSS. HTML (как язык) отображения практически никак не касается.
<DOCTYPE> на самом деле это фактически директива указывающая какой default CSS набор использовать.
Типа вот этого: http://www.w3.org/TR/CSS2/sample.html А эта штука идентичная для HTML 4 и 5 (для общих элементов).
Т.е. DOCTYPE HTML 4.01 Strict и DOCTYPE HTML фактически это одно и то же для browser.
Здравствуйте, ., Вы писали:
.>On 16/03/2010 00:22, c-smile wrote:
>> .>Как это? А SAX-parser? >> А какое отношение SAX-parser имеет к rendering? .>Парсишь и тут же рендеришь. А каким же образом XHTML не допускает incremental rendering?
Чего рендеришь? Invalid XML? А если в конце тебе closing </html> не приедет? Или оно в какой-то момент окажется не well formed что я должен с твоим контентом делать?
Стирать всю красоту с экрана и писать Error at line ... Not valid XML?
Если у тебя какие-то данные идут в XML и тот XML вдруг станет не валиден, ты будешь те данные всё равно использовать? Или как?
>> Я тоже так считаю но тем не менее в HTML5 оно есть и будет. Как же еще >> то тебя рекламу донести .>Мда... .>А чем DOM-фунцкии плохи для рекламы?
Фиг его знает. У меня document.write() нет
>>> > причинам. Скажем если твоя страница собирается как результат разных >>> > модулей то ты должен гарантирвать что все компоненты выдают именно XML. >> .>Это явно лучше, чем просто "набор байт", который непонятно как собирать. >> Что именно "явно лучше"? .>Два куска текста "X<Y" и "A>B" как собрать? И что должно получиться? .>И ещё интересно как там с кодировками...
Как собрать? А как придется. Во всяком случае даже если оно не валидно (например частично загрузилось) ты должен что-то показать ибо там может быть life critical информация.
>> По поводу "непонятно как собирать". Собственно HTML5 он как раз об этом >> — это первый стандарт в котором постулируются error recovery механизмы. >> Т.е. фактически markup: >> <body>Ку-ку!</html> >> валиден в том смысле что язык допускает пропущенные тэги и специфицирует >> способ их восстановления. .>В общем я не понимаю накой. Специфицировать кривые руки программистов?
Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию.
Представь себе что ты пишешь RSS интегратор. Там html идет из разных источников тебе не подконтрольных.
Твои действия?
>> .>И правильно. Хоть какая-то защита от XSS. >> Это не защита. В смысле вообще. .>Почему?
Это к мессиру kochetkov.vlad, он тебе объяснит.
>> .>А если придёт конструкция "<p>One<brTwo</p>" — что должно нарисоваться >> и почему? >> >> If a user agent encounters an element it does not recognize, it >> should try to render the element's content. .>Так это было с рождения HTML,если элемент неизвестен, то игнорировать. .>А тут другой случай. "<brTwo" это элемент такой? Как интерпретировать совершенный бред в разметке?
совершенный бред в разметке интерпретировать совершенно бредово. Но интерпретировать.
Здравствуйте, c-smile, Вы писали:
MC>>4) Или разница только в валидации? MC>>5) Если только в валидации то как UA будет понимать по какому стандарту отображать страницу? Походу ответ на третий вопрос — да. А на 4-й — нет?
CS>Что значит "по какому стандарту отображать страницу"? Отображение задается CSS который ортогонален HTML.
Ну допустим, между HTML 4.01 Transitional & Strict в некоторых ситуациях будет большая разница в отображении, т.е. в зависимости от DOCTYPE браузер будет по разному отображать страницу.
А между HTML 4.01 Strict & HTML 5 ты сказал не будет разницы.
CS>Просто надо понимать разницу между HTML и CSS. HTML (как язык) отображения практически никак не касается. CS><DOCTYPE> на самом деле это фактически директива указывающая какой default CSS набор использовать.
Т.е. разница ТОЛЬКО в default CSS наборе? Вообще какая-то путаница получается: DOCTYPE указывает версию HTML, а разница в css наборе... как-то это не выглядит очевидно что ли. Или это только мне неочевидно?
Еще все-таки уточняющие вопросы:
1) Все ли браузеры (и как дела со старыми версиями, например IE6) понимают <!DOCTYPE HTML> ?
2) Страница написанная под HTML 4.01 Strict но с указанным <!DOCTYPE HTML> будет отображаться так же как если бы был указан DOCTYPE HTML 4.01 Strict?
3) Правильно ли я все-таки понимаю что <!DOCTYPE HTML> сообщает что страница написана по стандарту HTML5?
4) Default CSS наборы у HTML 4.01 Strict & HTML5 одинаковые?
5) Может ли Default CSS набор для HTML5 изменится в финальной версии HTML5?
6) Какие проблемы я могу поиметь если буду писать <!DOCTYPE HTML>?
On 16/03/2010 02:56, c-smile wrote:
> Чего рендеришь? Invalid XML? А если в конце тебе closing </html> не > приедет? Или оно в какой-то момент окажется не well formed что я должен > с твоим контентом делать? > Стирать всю красоту с экрана и писать Error at line ... Not valid XML? > Если у тебя какие-то данные идут в XML и тот XML вдруг станет не > валиден, ты будешь те данные всё равно использовать? Или как?
Ааа... понятно. Вот это можно было бы предусмотреть стандартом — оборвать парсинг и в конце написать ошибку.
> .>Два куска текста "X<Y" и "A>B" как собрать? И что должно получиться? > .>И ещё интересно как там с кодировками... > Как собрать? А как придется. Во всяком случае даже если оно не валидно > (например частично загрузилось) ты должен что-то показать ибо там может > быть life critical информация.
Я имею в виду, что в случае xml есть вполне "типа-безопасный" API, где понятно, что есть текст, что есть разметка.
> Представь себе что ты пишешь RSS интегратор. Там html идет из разных > источников тебе не подконтрольных. > Твои действия?
Парсить это г хоть как-нибудь, возможно настраиваясь под конкретные источники.
> .>Почему? > Это к мессиру kochetkov.vlad, он тебе объяснит.
Вроде он со мной согласился
.
>> > If a user agent encounters an element it does not recognize, it >> > should try to render the element's content. > .>Так это было с рождения HTML,если элемент неизвестен, то игнорировать. > .>А тут другой случай. "<brTwo" это элемент такой? Как интерпретировать совершенный бред в разметке? > совершенный бред в разметке интерпретировать совершенно бредово. Но > интерпретировать.
Так ведь опять получится та же история "а у нас под IE работает". Или бредовость будет оговорена стандартом?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Я согласился с тем, что если использовать определенный способ генерации XML, то это вполне сойдет за один из способов безопасного экранирования недоверенных данных (в чем я уже не очень уверен — поверил на слово, но было бы здорово увидеть пример такого генерирующего кода). Дело в том, что мест (в размечаемом документе), где может случиться XSS довольно много и мне кажется, что даже правильная генерация в ряде случаев не поможет.
А сам XHTML едва ли можно назвать более безопасным (с т.з. информационных угроз) языком разметки, нежели его, менее строгие собратья.
On 16/03/2010 10:48, kochetkov.vladimir wrote:
> Я согласился с тем, что *если* использовать определенный способ > генерации XML, то это вполне сойдет за один из способов безопасного > экранирования недоверенных данных (в чем я уже не очень уверен — поверил > на слово, но было бы здорово увидеть пример такого генерирующего кода).
Да любой способ генерации XML: SAX, DOM, XSLT.
Там явно приходится описывать что есть текст, а что есть имя тега.
> Дело в том, что мест (в размечаемом документе), где может случиться XSS > довольно много и мне кажется, что даже правильная генерация в ряде > случаев не поможет.
По идее, если всё сделать правильно, то HTML-injection будет так же сложен как, SQL-injection при использовании Linq.
> А сам XHTML едва ли можно назвать более безопасным (с т.з. > информационных угроз) языком разметки, нежели его, менее строгие собратья.
Просто HTML можно генерить только как обычный текст. Либо какие-то явные фунцкии print_escaped_text.
Но тут возникает вопрос — сейчас html популярен тем, что любой школьник может налабать хоумпагу и она кое-как кое-где, но нарисуется. Если же сделать это безопасно, то им станет пользоваться сложнее... Захотят ли это массы?..
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>А сам XHTML едва ли можно назвать более безопасным (с т.з. информационных угроз) языком разметки, нежели его, менее строгие собратья.
Ай опьять за рибу гроши...
Вот тебе как бы XHTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<body>
One<br>Two
</html>
Сохрани его как xhtml.htm и открой.
Ну где тут "строгость"?
Если же ты его сохранишь как xhtml.xml или твой сервер будет сконфигурирован на отдание html файлов как application/xml
тогда ты получишь ошибку. И то не всегда.
Короче делать какие-то security assumptions по <!DOCTYPE это тоже самое что верить тому что написано на заборе.
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, kochetkov.vladimir, Вы писали:
KV>>А сам XHTML едва ли можно назвать более безопасным (с т.з. информационных угроз) языком разметки, нежели его, менее строгие собратья.
CS>Короче делать какие-то security assumptions по <!DOCTYPE это тоже самое что верить тому что написано на заборе.
Здравствуйте, c-smile, Вы писали:
c> Если у тебя какие-то данные идут в XML и тот XML вдруг станет не валиден, ты будешь те данные всё равно использовать? Или как?
Зависит от ситуации. Если он стал невалидным по причине некорректной структуры (незакрыли тег, закрыли не там и др.) это одно. Если же он стал невалидным по причине невозможности получения полного документа (обрыв связи) это совсем другое. Во втором случае можно попробовать в автоматическом режиме "дозакрыть" открытые теги, чтоб была возможность получить хоть какие-то данные (при условии, что софт вообще к такой ситуации готов). Это может быть актуально для документов с большими регулярными структурами (очень полезно для SOAP, XML-RPC). Толерантность к входящей информации это хороший тон, при условии однозначной интерпретации разумеется.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Нужная, кстати, вещь. RO>
RO><script>
RO> document.write("<some ajaxy things that make no sense when scripts are not enabled>");
RO></script>
RO>
RO>Было бы хорошо, если был бы какой-то антоним <noscript>.
За такой код нужно делать предупредительный выстрел в голову.
[my.hml]
<div class="ajaxy">ajaxy things that make no sense when scripts are not enabled</div>
[my.js]
$(".ajaxy").show()
[my.css]
.ajaxy
{
display:none;
}
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, c-smile, Вы писали:
CS>А XHTML помер в том смысле что народ признал что XML не может быть в принципе использован как средство доставки контента (страниц) с сервера на клиент.
Что в XHTML чудесно, по крайней мере в теории, так это пространства имен. Например, HTML5 предполагает поддержку SVG и MathML. Чтобы это работало, надо из кожи вон лезть, избегая совпадений названий элементов. Вот почему в MathML идентификатор — <mi>, не <i>? Или новый элемент <article>, который вполне мог бы уже существовать в каком-нибудь RSS/Atom-подобном языке.
Здравствуйте, Roman Odaisky, Вы писали:
.>>За такой код нужно делать предупредительный выстрел в голову. RO>Lynx?
Мда... Забыл.
Но в общем если он так нужен, можно и через DOM всё вставить, через ajax тот же, без write.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
M>> c>> А еще Шириданы всяки с XHTML пламенем в глазах ... Жуть. M>> S>Признаюсь я расстроился. Ожидал что html5 будет еще боле жесток, M>> Зачем?
S>Чтобы заставлять программистов писать более ровный код, которыей S>а) более быстро было бы можно обрабатывать изза исключения из браузера кода "а нука угадаю я, что тут хотят нарисовать"
Зачем? Кому от этого станет лучше?
S>б) одинаково бы отображался везде, от мобил до плейстейшн, во всяком случае это было бы проще реализовать.
X/HTML и CSS спеки просто огромны с множеством неявных мест. Наличие там XML'я никак не влияет на возможности реализации чего-либо.
S>А опять возвращаются к разброду и шатаниям...
Тут всё просто. Пользователи для стандартов или стандарты для пользователей? Данные для xml или xml для данных?
Если второе, то, естественно, отображение контента, пусть даже и несколько криво, первично. Значит надо пытаться показать что можно как можно.
Если первое — да, показываем ошибку, юзера матерятся, и все, кроме самых пряморуких программистов посылают такие стандарты на йух. В результате пряморукие программисты счастливы, все пользователи предпочитают "менее правильные" броузеры, которые "бред интерпретируют бредово. Но интерпретируют".
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, Sheridan, Вы писали:
S>>А опять возвращаются к разброду и шатаниям...
RO>Дилемма заключенного получается. Если броузер A строже, чем броузер Б, то юзеры не станут лезть в XML. Они просто скажут «броузер А не работает со вконтакте-ру!», чем всё и кончится. Смысл будет, только если все броузеры разом ужесточат свои требования, что нереально. И то, в интернете гигабайты старых страничек, которые хорошо бы продолжать отображать несмотря на всю нестандартность.
Весь мир насилья мы разрушим
До основанья, а затем
Мы наш, мы новый мир построим
Здравствуйте, c-smile, Вы писали:
CS>Еще короче, если в начале страницы написано CS><!DOCTYPE HTML {фигня всяка или ничего} > CS>то это инструкция броузеру грузить стандартный default style sheet. Он один на все разные DOCTYPEs. CS>Если же <!DOCTYPE нет то грузится quirks style sheet. Высё.
Если поставить strict doctype, то страница будет отображаться по-другому, чем если бы стоял transitional doctype, а из твоих слов выше должно следовать что разницы не должно быть.
Приветствую, Roman Odaisky, вы писали:
RO> Дилемма заключенного получается. Если броузер A строже, чем броузер Б, то юзеры не станут лезть в XML. Они просто скажут «броузер А не работает со вконтакте-ру!», чем всё и кончится. Смысл будет, только если все броузеры разом ужесточат свои требования, что нереально. И то, в интернете гигабайты старых страничек, которые хорошо бы продолжать отображать несмотря на всю нестандартность.
Слушай, а ты где браузер то покупал, почем?
Приветствую, Antikrot, вы писали:
A> S>Слушай, а ты где браузер то покупал, почем? A> купил FF в составе линукса, цены на redhat.com
Ах... Ну да... Ну мне сказать нечего.... Хотите тратить деньги — мешать не буду.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, c-smile, Вы писали:
c>> Если у тебя какие-то данные идут в XML и тот XML вдруг станет не валиден, ты будешь те данные всё равно использовать? Или как?
H>Зависит от ситуации. Если он стал невалидным по причине некорректной структуры (незакрыли тег, закрыли не там и др.) это одно. Если же он стал невалидным по причине невозможности получения полного документа (обрыв связи) это совсем другое. Во втором случае можно попробовать в автоматическом режиме "дозакрыть" открытые теги, чтоб была возможность получить хоть какие-то данные (при условии, что софт вообще к такой ситуации готов). Это может быть актуально для документов с большими регулярными структурами (очень полезно для SOAP, XML-RPC). Толерантность к входящей информации это хороший тон, при условии однозначной интерпретации разумеется.
Если у тебя есть система в которая допускает "в автоматическом режиме "дозакрыть" открытые теги" то значит твоя система
оперирует языком в котором незакрытый тэг является валидной конструкцией. Т.е. это уже другой язык — не XML.
Собственно HTML и в частности HTML5 это как раз спецификация такого языка.
Для XML есть такое требование:
Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.
В случае web pages этото вот must не ясно куда пришить. Кому report? Автору сайта или юзеру? Если юзеру то он болезный как эти violation читать должен?
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, c-smile, Вы писали:
CS>>Представь себе, что ты пишешь RSS-интегратор. Там html идет из разных источников, тебе не подконтрольных.
RO>libtidy
Здравствуйте, c-smile, Вы писали:
CS>>>Представь себе, что ты пишешь RSS-интегратор. Там html идет из разных источников, тебе не подконтрольных. RO>>libtidy CS>Где libtidy? В browser или на сервере?
Там, где несколько text/html склеиваются в один application/atom+xml. Формат же для машинной обработки, он должен быть действительным XML.
Здравствуйте, c-smile, Вы писали:
c> H>Зависит от ситуации. Если он стал невалидным по причине некорректной структуры (незакрыли тег, закрыли не там и др.) это одно. Если же он стал невалидным по причине невозможности получения полного документа (обрыв связи) это совсем другое. Во втором случае можно попробовать в автоматическом режиме "дозакрыть" открытые теги, чтоб была возможность получить хоть какие-то данные (при условии, что софт вообще к такой ситуации готов). Это может быть актуально для документов с большими регулярными структурами (очень полезно для SOAP, XML-RPC). Толерантность к входящей информации это хороший тон, при условии однозначной интерпретации разумеется.
c> Если у тебя есть система в которая допускает "в автоматическом режиме "дозакрыть" открытые теги" то значит твоя система c> оперирует языком в котором незакрытый тэг является валидной конструкцией. Т.е. это уже другой язык — не XML.
Я говорю о "дозакрытии" тегов, которые являются не закрытыми по причине отсутствия полного документа. Пример для наглядности:
Это массив структур в формате XML-RPC. Вторым блоком я показал какую часть документа мы потеряли при обрыве связи. По идее, т.е. следуя спеке, я должен отрапортовать о невалидном пакете и умыть руки. Но, что мне (т.е. парсеру разумеется) мешает, имея информацию об открытых тегах, сгенерировать несколько событий (SAX модель) о закрытии тегов и получить тем самым вполне-себе валидный XML? Да, XML-RPC пакет будет невалиден т.к. последняя структура не будет иметь обязательного элемента, но в данной ситуации она будет отнесена к потерянным данным и вообще исключена из результата парсинга. Однозначность интерпретации при этом никак не страдает. В результате пользователь получит почти все данные и следующий запрос вернет ему только недостающую часть. Выгодно, и пользователю, и веб-сервису (У меня успешная синхронизация с rsdn удалась только с 6-7 попытки. Каждая попытка это ~600-800 килобайт из 1.4 мегабайта. Это GPRS от МТС).
c> Собственно HTML и в частности HTML5 это как раз спецификация такого языка.
c> Для XML есть такое требование:
c>
c> Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.
c> В случае web pages этото вот must не ясно куда пришить. Кому report? Автору сайта или юзеру? Если юзеру то он болезный как эти violation читать должен?
Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги). В случае ошибки сохранить распарсеную часть и оповестить пользователя.
c>> Если у тебя есть система в которая допускает "в автоматическом режиме "дозакрыть" открытые теги" то значит твоя система c>> оперирует языком в котором незакрытый тэг является валидной конструкцией. Т.е. это уже другой язык — не XML.
H>Я говорю о "дозакрытии" тегов, которые являются не закрытыми по причине отсутствия полного документа. Пример для наглядности:
[красота skipped]
H>Это массив структур в формате XML-RPC. Вторым блоком я показал какую часть документа мы потеряли при обрыве связи. По идее, т.е. следуя спеке, я должен отрапортовать о невалидном пакете и умыть руки. Но, что мне (т.е. парсеру разумеется) мешает, имея информацию об открытых тегах, сгенерировать несколько событий (SAX модель) о закрытии тегов и получить тем самым вполне-себе валидный XML? Да, XML-RPC пакет будет невалиден т.к. последняя структура не будет иметь обязательного элемента, но в данной ситуации она будет отнесена к потерянным данным и вообще исключена из результата парсинга. Однозначность интерпретации при этом никак не страдает. В результате пользователь получит почти все данные и следующий запрос вернет ему только недостающую часть. Выгодно, и пользователю, и веб-сервису (У меня успешная синхронизация с rsdn удалась только с 6-7 попытки. Каждая попытка это ~600-800 килобайт из 1.4 мегабайта. Это GPRS от МТС).
Попробуй "дозакрыть" открытые теги.
c>> Собственно HTML и в частности HTML5 это как раз спецификация такого языка.
c>> Для XML есть такое требование:
c>>
c>> Validating and non-validating processors alike must report violations of this specification's well-formedness constraints in the content of the document entity and any other parsed entities that they read.
c>> В случае web pages этото вот must не ясно куда пришить. Кому report? Автору сайта или юзеру? Если юзеру то он болезный как эти violation читать должен?
H>Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги). В случае ошибки сохранить распарсеную часть и оповестить пользователя.
Оповестить пользователя о чем? И как? И на каком языке?
Такие ситуации разруливаются еще на этапе проектирования интерфейсов, и кстати в XML-RPC она вообще невозможна т.к. там обязательный респонз должен присутствовать (в SOAP, как я понимаю, тоже). К тому же прикладной код в любом случае в курсе произошедшей ошибки и уже сам отвечает за принятие решения.
c> c>> Собственно HTML и в частности HTML5 это как раз спецификация такого языка.
c> H>Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги). В случае ошибки сохранить распарсеную часть и оповестить пользователя.
c> Оповестить пользователя о чем? И как? И на каком языке?
Об ошибке в разметке, о неполном документе. Каким угодно способом, это может быть всплывающая панелька над содержимым документа (как сделаны сообщения о небезопасном контенте в IE, или поиск в новой Опере), со ссылкой на более детальную информацию. На языке юзер-агента разумеется.
Здравствуйте, c-smile, Вы писали:
CS>Ты не понял. Скажем есть google reader какой. Он показывает контент (в т.ч. html) поступющий из разных источников. На одной странице. CS>Ты можешь гарантировать что у тебя всегда валидный xhtml выхлоп будет?
Если задействовать что-нибудь наподобие libtidy, то да. Но здесь вроде XHTML и не нужен.
Здравствуйте, hattab, Вы писали:
h> Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги).
Несмотря на то, что тема протухла, думаю будет интересно... Опера умеет отрисовывать SVG-картинки по мере их загрузки, а SVG это таки XML.
Здравствуйте, ., Вы писали:
.> h>> Рендерить то, что уже распарсилось предполагая, что оставшаяся часть будет так же валидной (типа "дозакрывая" теги).
.> H>Несмотря на то, что тема протухла, думаю будет интересно... Опера умеет отрисовывать SVG-картинки по мере их загрузки, а SVG это таки XML.
.> Интересно, а что происходит при обрыве связи?
Ругается на неполный XML (загруженую часть изображения не сохраняет). Предлагает показать его как HTML. А вообще в спеке XML есть:
fatal error
[Definition: An error which a conforming XML processor MUST detect and report to the application. After encountering a fatal error, the processor MAY continue processing the data to search for further errors and MAY report such errors to the application. In order to support correction of errors, the processor MAY make unprocessed data from the document (with intermingled character data and markup) available to the application. Once a fatal error is detected, however, the processor MUST NOT continue normal processing (i.e., it MUST NOT continue to pass character data and information about the document's logical structure to the application in the normal way).]
т.е. корректировка ошибок в общем-то допустима...
.> Да как бы вообще странно считать что xml плох в этом отношении. .> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.
Опера такие сайты сможет показать в виде HTML, я думаю
Здравствуйте, hattab, Вы писали:
H>т.е. корректировка ошибок в общем-то допустима...
В том-то и дело, что xml processor. Непонятно о чём говорил c-smile. Т.е. processor (парсер как я понимаю?) обязан упасть, а приложение (браузер), что хочет, то и делает. Стандарт это не ограничивает.
.>> Да как бы вообще странно считать что xml плох в этом отношении. .>> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать. H>Опера такие сайты сможет показать в виде HTML, я думаю
Вот какой браузер выберет пользователь — Opera, которая выдаёт какие-то непонятные ошибки, заставляет нажимать какие-то хитрые кнопки или IE который просто всё рисует?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>>> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать. H>>Опера такие сайты сможет показать в виде HTML, я думаю .>Вот какой браузер выберет пользователь — Opera, которая выдаёт какие-то непонятные ошибки, заставляет нажимать какие-то хитрые кнопки или IE который просто всё рисует?
Хм, т.е. вы тоже пришли наконец к выводу, что стандарты должны вводиться для удобства, а не наоборот, и если стандарт мешает удобству конечного пользователя, то такой стандарт естественным путём пойдёт лесом?
Здравствуйте, yoriсk.kiev.ua, Вы писали:
YKU>Хм, т.е. вы тоже пришли наконец к выводу, что стандарты должны вводиться для удобства, а не наоборот, и если стандарт мешает удобству конечного пользователя, то такой стандарт естественным путём пойдёт лесом?
Не совсем. Я пришел к выводу, что помимо правильных идей, существует реальный мир. Что браузеры попали в порочный круг, из которого выбираться дороже, чем клепать очередной костыль. Т.е. правильность HTML не настолько критична, чтобы прилагать к этому усилия.
Вот с access violation — это пришлось решать, даже железо специальное делают, защищённый режим и всё такое, потому что ущерб может быть серьёзным. А вот кривой html, утянутые пароли вконтакта из-за xss — мало кого беспокоит.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.> H>т.е. корректировка ошибок в общем-то допустима...
.> В том-то и дело, что xml processor. Непонятно о чём говорил c-smile. Т.е. processor (парсер как я понимаю?) обязан упасть, а приложение (браузер), что хочет, то и делает. Стандарт это не ограничивает.
Насколько я понимаю — да. Парсер должен обязательно оповестить об ошибке приложение, но при этом может дать возможность приложению обработать данные которые он считает ошибочными.
.> .>> Да как бы вообще странно считать что xml плох в этом отношении. .> .>> Единственная серьёзная причина, на мой взгляд, почему xml не приживётся — толпы криворуких программеров, которые не умеют нормально использовать xml. А следовательно — толпы кривых сайтов, и браузер, который делает всё правильно, не будут любить пользователи, т.к. их любимые сайты не будут работать.
.> H>Опера такие сайты сможет показать в виде HTML, я думаю
.> Вот какой браузер выберет пользователь — Opera, которая выдаёт какие-то непонятные ошибки, заставляет нажимать какие-то хитрые кнопки или IE который просто всё рисует?
Все же втихую ошибки глотать нельзя, это красной линией проходит по спеке XML, но и радикализм Оперы мне так же не понятен.
Здравствуйте, Sheridan, Вы писали:
S>а) более быстро было бы можно обрабатывать изза исключения из браузера кода "а нука угадаю я, что тут хотят нарисовать"
куда ж быстрей?
S>б) одинаково бы отображался везде, от мобил до плейстейшн, во всяком случае это было бы проще реализовать.
нафиг-нафиг. давайте радеть за css media types
Здравствуйте, c-smile, Вы писали:
CS>Ох ё моё... В каких еще ситуациях?
да еж твое.
Первый этап (1995—1998)
График популярности браузеров
Конкуренция между браузерами Microsoft Internet Explorer и Netscape Navigator (Communicator) в конце 90-х годов.
Домашние пользователи Netscape Navigator могли загрузить браузер бесплатно, но корпоративные заказчики платили за каждую лицензию 99 долларов. Доходы, получаемые Microsoft от продаж Windows и Office, позволили «распространить» Explorer бесплатно и для корпораций. Explorer распространялся путём намеренного привязывания браузера к рабочему столу пользователя (и затруднению деинсталяции) в новых версиях Windows.
Netscape не смогла противостоять демпингу, и в 1999 году корпоративный рынок браузеров перестал существовать, — полностью бесплатный Explorer захватил более 90 процентов рынка.
После уничтожения компании Марка Андрессена (Marc Andreessen) и Джима Кларка Netscape Communications Corporation были опубликованы исходные коды браузера, что позволило зародиться и развиваться таким проектам, как Mozilla и Mozilla Firefox.
И после этого говорят о стандартах. Был стандарт, но исторически сложилось... Дык выправляйте ситуацию. Давайте Yhtml, но что бы он никуда без Zcss.
