Mamut wrote:
> Чем хуже XBL? Ничем. Ничего не парсит, работает с готовым DOM документа > и AJAX'ом. Что еще надо-то?
Погляди в firefox в районе chrome\toolkit.jar!content\global\bindings\tabbrowser.xml
Не, ну можно вместо xml использовать javascript, конечно... вообще говоря, некое подмножество xml легко укладывается в
javascript. Но некоторые вещи не очень. Например кодировка, namespaces (не забываем, что помимо html существуют и другие
замечательные вещи — mathml, svg, xul...), возможность генерации/обработки xml-based документов с помощью того же
xml-парсера (и related технологий, типа xslt).
И если так рассуждать, то зачем вообще нужен css и html? Можно же полностью описать весь html с помощью javascript плюс
раскрасить вместо использования css.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Mamut wrote:
> Чем хуже XBL? Ничем. Ничего не парсит, работает с готовым DOM документа > и AJAX'ом. Что еще надо-то?
Погляди в firefox в районе chrome\toolkit.jar!content\global\bindings\tabbrowser.xml
Не, ну можно вместо xml использовать javascript, конечно... вообще говоря, некое подмножество xml легко укладывается в
javascript. Но некоторые вещи не очень. Например кодировка, namespaces (не забываем, что помимо html существуют и другие
замечательные вещи — mathml, svg, xul...), возможность генерации/обработки xml-based документов с помощью того же
xml-парсера (и related технологий, типа xslt).
И если так рассуждать, то зачем вообще нужен css и html? Можно же полностью описать весь html с помощью javascript плюс
раскрасить вместо использования css.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
>> Чем хуже XBL? Ничем. Ничего не парсит, работает с готовым DOM документа >> и AJAX'ом. Что еще надо-то? .>Погляди в firefox в районе chrome\toolkit.jar!content\global\bindings\tabbrowser.xml
Смотрю и ужасаюсь вот этому:
<field name="mCurrentBrowser">
null
</field>
<field name="mProgressListeners">
[]
</field>
<field name="mTabListeners">
new Array()
</field>
<field name="mTabFilters">
new Array()
</field>
.>Не, ну можно вместо xml использовать javascript, конечно... вообще говоря, некое подмножество xml легко укладывается в .>javascript. Но некоторые вещи не очень. Например кодировка,
В эпоху utf-8? Нет, я согласен, что кодировки иногда нужны реально левые. Другой вопрос, насколько часто они нужны?
.>namespaces
Ага. Это те самые, что Javascript 2 хотят вводить. Что это такое, кстати, и зачем оно нужно?
.>(не забываем, что помимо html существуют и другие .>замечательные вещи — mathml, svg, xul...),
И что? Причем тут XUL и необходимость иметь его в виде такой каши?
.>возможность генерации/обработки xml-based документов с помощью того же .>xml-парсера (и related технологий, типа xslt).
И? Причем тут XUL?
.>И если так рассуждать, то зачем вообще нужен css и html? Можно же полностью описать весь html с помощью javascript плюс .>раскрасить вместо использования css.
A>>О, да. Парсим HTML и потом вставляем его посредством DOM — мощь технологии. M>Мы не парсим HTML. Мы работаем с уже готовым и преподнесенным нам на блюдечке DOM HTML документа.
Где тут DOM HTML?
<input class=\"search-go-button\">
M>Зато ниже я привел другой пример с search box'ами. Никаким CSS от него не отвертишься. У меня еще есть примеров. M>Я, кстати, так и не получил ответа на вопрос, чем, например, вот это отличается от предлагаемого байндинга. M>Я, правда, могу сказать, чем. Это уже есть, существует, и вполне себе кроссбраузерно. Зачем мне нужен XBL, которого еще нет (кроме как в Мозилле) и который не предлагает мне никаких преимуществ по сравнению с существующей связкой HTML + CSS + JavaScript (под HTML я понимаю и HTML DOM тоже)? M>О. Кстати. Байндинг, хм... M>Предлагаю посмотреть на такой пример: http://www.yui-ext.com/deploy/yui-ext/docs/#../examples/view/chooser.html M>Чем хуже XBL? Ничем. Ничего не парсит, работает с готовым DOM документа и AJAX'ом. Что еще надо-то?
Да ничем, они просто разные. С использованием XBL это было бы что-то вроде:
<yui:image-chooser label="Insert Image"/>
И всё, пользуй кто хочешь, в XBL лезть не обязательно. А можно еще атрибутов добавить для тонкой настройки.
Понимаешь, с помощью XBL ты можешь описать свой собственный язык описания UI и выдать пользователю просто набор тегов: <checkbox>, <radiobutton>, <treeview> и т. п. Пользователь из них как из кубиков соберёт всё, что ему надо и как он привык.
Mamut wrote:
> Чем хуже XBL? Ничем. Ничего не парсит, работает с готовым DOM документа > и AJAX'ом. Что еще надо-то?
Погляди в firefox в районе chrome\toolkit.jar!content\global\bindings\tabbrowser.xml
Не, ну можно вместо xml использовать javascript, конечно... вообще говоря, некое подмножество xml легко укладывается в
javascript. Но некоторые вещи не очень. Например кодировка, namespaces (не забываем, что помимо html существуют и другие
замечательные вещи — mathml, svg, xul...), возможность генерации/обработки xml-based документов с помощью того же
xml-парсера (и related технологий, типа xslt).
И если так рассуждать, то зачем вообще нужен css и html? Можно же полностью описать весь html с помощью javascript плюс
раскрасить вместо использования css.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
A>>>О, да. Парсим HTML и потом вставляем его посредством DOM — мощь технологии. M>>Мы не парсим HTML. Мы работаем с уже готовым и преподнесенным нам на блюдечке DOM HTML документа.
A>Где тут DOM HTML? A>
A>Да ничем, они просто разные. С использованием XBL это было бы что-то вроде: A>
A><yui:image-chooser label="Insert Image"/>
A>
A>И всё, пользуй кто хочешь, в XBL лезть не обязательно. А можно еще атрибутов добавить для тонкой настройки.
A>Понимаешь, с помощью XBL ты можешь описать свой собственный язык описания UI и выдать пользователю просто набор тегов: <checkbox>, <radiobutton>, <treeview> и т. п. Пользователь из них как из кубиков соберёт всё, что ему надо и как он привык.
Не верю (с)
Не верю, что я смогу на питоне/ассемблере/эрланге написать на XBL приблудину, котору браузер сможет распарсить и показать мне. Все равно это останется кашей из XML+Javascript. Которую еще и никто поддерживать/реализовывать не будет.
А из кубиков я и сейчас собрать могу. Не менее быстро. С не менее тонкой настройкой.
В общем, я так и не понял, какие широкие горизонты открывает мне XBL
Здравствуйте, Left2, Вы писали:
L>Что даст JavaScript статическая типизация? Скорость? Так ведь всё равно как ни крути эта скорость не сможет приблизиться даже к скорости Java/.Net приложений, не говоря уже о скорости "битовыжималок" типа С и С++.
Не понял, какая разница, из чего компилировать в байт-код, из файлов в кодировке "C#.Net" или из файлов в кодировке "JScript.Net"?
Нету разницы в скорости...
N>Не понял, какая разница, из чего компилировать в байт-код, из файлов в кодировке "C#.Net" или из файлов в кодировке "JScript.Net"? N>Нету разницы в скорости..
Ничего не понял из этого сообщения При чём тут JScript.Net ?
Mamut wrote:
> Но когда файл из-за этого — дикая смесь XML и Javascript'a... > Когда там вот такое: > <xul:hbox class="tabbrowser-strip" collapsed="true" tooltip="_child" context="_child" > anonid="strip" > ondraggesture="nsDragAndDrop.startDrag(event, this.parentNode.parentNode); event.stopPropagation();" > ondragover="nsDragAndDrop.dragOver(event, this.parentNode.parentNode); event.stopPropagation();" > ondragdrop="nsDragAndDrop.drop(event, this.parentNode.parentNode); event.stopPropagation();" > ondragexit="nsDragAndDrop.dragExit(event, this.parentNode.parentNode); event.stopPropagation();">
А как иначе? Ну будет что-то в духе
var hbox = document.createElement("hbox", "there.is.only.xul")
hbox.class="tabbrowser-strip"
hbox.collapsed = true
....
Ничем не лучше.
> .>Не, ну можно вместо xml использовать javascript, конечно... вообще > говоря, некое подмножество xml легко укладывается в > .>javascript. Но некоторые вещи не очень. Например кодировка, > В эпоху utf-8? Нет, я согласен, что кодировки иногда нужны реально > левые. Другой вопрос, насколько часто они нужны?
Часто нужно, чтобы не было проблем с кодировками. xml их решает, javascript (и json в том числе) — не решает.
> .>namespaces > Ага. Это те самые, что Javascript 2 хотят вводить. Что это такое, > кстати, и зачем оно нужно?
Для того, чтобы можно было смешивать несколько документов в один документ. Что-то в духе:
> .>(не забываем, что помимо html существуют и другие > .>замечательные вещи — mathml, svg, xul...), > И что? Причем тут XUL и необходимость иметь его в виде такой каши?
Вопрос не понял. Ты, случаем, XUL и XBL не путаешь?
> .>возможность генерации/обработки xml-based документов с помощью того же > .>xml-парсера (и related технологий, типа xslt). > И? Причем тут XUL?
Это объяснение почему XBL, и в чём выгода XML-based форматов.
> .>И если так рассуждать, то зачем вообще нужен css и html? Можно же > полностью описать весь html с помощью javascript плюс > .>раскрасить вместо использования css. > Я не о том немного. Я, скорее, об этом
Вот и примени свои четыре вопроса по отношению к css:
а) не дает ничего нового
б) не облегчает решение описанных мной выше задач ни на йоту
с) будет по-разному реализована в разных браузерах (если будет) и все равно будет вызывать кучу проблем для разработчиков
d) ничем не отличается от существующей связки JavaScript + HTML + DOM?
А потом по отношению и к html
а) не дает ничего нового
б) не облегчает решение описанных мной выше задач ни на йоту
с) будет по-разному реализована в разных браузерах (если будет) и все равно будет вызывать кучу проблем для разработчиков
d) ничем не отличается от существующей связки JavaScript + DOM?
В итоге останется, что реально писать ВСЁ используя только JavaScript + DOM. Что-то вроде:
var html = document.createElement("html")
document.setDocumentRoot(html)
var head = document.createElement("head")
html.appendChild(head)
var title = document.createElement("title")
head.appendChild(title)
title.appendChild(document.createTextNode("Hello, world!")
var body = document.createElement("body")
html.appendChild(body)
body.style.marginTop="1px"
body.style.color = "red"
И т.п.
Можно удобные библиотеки написать, чтобы не приходилось каждый раз писать document.createElement/appendChild, а
описывать структуру в виде json-оида.
А теперь подумай — нафига тебе этот минимализм?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Mamut wrote:
>> Но когда файл из-за этого — дикая смесь XML и Javascript'a... >> Когда там вот такое: >> <xul:hbox class="tabbrowser-strip" collapsed="true" tooltip="_child" context="_child" >> anonid="strip" >> ondraggesture="nsDragAndDrop.startDrag(event, this.parentNode.parentNode); event.stopPropagation();" >> ondragover="nsDragAndDrop.dragOver(event, this.parentNode.parentNode); event.stopPropagation();" >> ondragdrop="nsDragAndDrop.drop(event, this.parentNode.parentNode); event.stopPropagation();" >> ondragexit="nsDragAndDrop.dragExit(event, this.parentNode.parentNode); event.stopPropagation();"> .>А как иначе? Ну будет что-то в духе .>
Первое хоть еще дебагить можно. А второе?
>> В эпоху utf-8? Нет, я согласен, что кодировки иногда нужны реально >> левые. Другой вопрос, насколько часто они нужны? .>Часто нужно, чтобы не было проблем с кодировками. xml их решает, javascript (и json в том числе) — не решает.
Что-то мне говорит, что XML — это тоже не панацея от кодировок
>> .>namespaces >> Ага. Это те самые, что Javascript 2 хотят вводить. Что это такое, >> кстати, и зачем оно нужно? .>Для того, чтобы можно было смешивать несколько документов в один документ. Что-то в духе: .>
Я все равно не понял, зачем это нужно (особенно в свете предлагаемых packages)
>> .>(не забываем, что помимо html существуют и другие >> .>замечательные вещи — mathml, svg, xul...), >> И что? Причем тут XUL и необходимость иметь его в виде такой каши? .>Вопрос не понял. Ты, случаем, XUL и XBL не путаешь?
Быть может Но пока XBL только в XUL ведь применяется И здесь приводили примеры из XUL...
>> .>возможность генерации/обработки xml-based документов с помощью того же >> .>xml-парсера (и related технологий, типа xslt). >> И? Причем тут XUL? .>Это объяснение почему XBL, и в чём выгода XML-based форматов.
Так в чем эта выгода?
Смесь технологий?
Потеря читаемости?
Дубликация уже существующих технологий?
>> .>И если так рассуждать, то зачем вообще нужен css и html? Можно же >> полностью описать весь html с помощью javascript плюс >> .>раскрасить вместо использования css. >> Я не о том немного. Я, скорее, об этом .>Вот и примени свои четыре вопроса по отношению к css: .>А потом по отношению и к html
"Вот валит, гад" (с)
Я ж не призываю отказываться от существующей связки JavaScript + CSS + HTML.
Я предлагаю.
а) От них не отказываться
б) Добавить в уже существующие технологии те 2-3 вещи, которые им недостают:
б.1) В Javascript — getElementsByCSS, getElementByXPath (чтобы нативно поддерживалась функциональность наподобие этой
б.2) В CSS — %% и flow
б.3) В HTML — не знаю
Просто вопрос у меня следующий:
XBL не дает _ничего_ нового. Вообще. Абсолютно. Мне еще никто не смог внятно объяснить, в чем его преимущества, и какие проблемы, стоящие перед веб-разработчиками, он позволяет решить. Это просто новая технология? Технология ради технологии? Так зачем мне она такая нужна?
Так _что_ же такого предоставляет XBL, чтобы было необходимо вводить новую технологию, а не "допилить" существующие?
Mamut wrote:
> .>Ничем не лучше. > Лучше. Нет смеси несмесимых технологий. Да еще с такой убогой (никакой)
Просто вы не умеете их смешивать.
> читаемостью. Сравним:
Единственная разница — " вместо { и function() нет.
> Первое хоть еще дебагить можно. А второе?
Да, venkmann дебаггит (афаир). Сформулирую тезис — в данном случае разница чисто в чуть-чуть других символах!
>> > В эпоху utf-8? Нет, я согласен, что кодировки иногда нужны реально >> > левые. Другой вопрос, насколько часто они нужны? > .>Часто нужно, чтобы не было проблем с кодировками. xml их решает, > javascript (и json в том числе) — не решает. > Что-то мне говорит, что XML — это тоже не панацея от кодировок
Ну просто там нет проблемы с кодировками.
> Я все равно не понял, зачем это нужно (особенно в свете предлагаемых > packages)
Неужели непонятно зачем нужна возможность в html-ную страницу помещать математическую формулу mathml или векторный
рисунок svg?
(кто такие packages и какое отношение они имеют к xml или xbl я не понял)
>> > .>(не забываем, что помимо html существуют и другие >> > .>замечательные вещи — mathml, svg, xul...), >> > И что? Причем тут XUL и необходимость иметь его в виде такой каши? > .>Вопрос не понял. Ты, случаем, XUL и XBL не путаешь? > Быть может Но пока XBL только в XUL ведь применяется И здесь приводили > примеры из XUL...
XBL также легко прикручивается и к HTML-элементам. Оно даже давно работает.
>> > .>возможность генерации/обработки xml-based документов с помощью того же >> > .>xml-парсера (и related технологий, типа xslt). >> > И? Причем тут XUL? > .>Это объяснение почему XBL, и в чём выгода XML-based форматов. > Так в чем эта выгода?
возможность генерации/обработки xml-based документов с помощью того же xml-парсера (и related технологий, типа xslt).
>> > .>И если так рассуждать, то зачем вообще нужен css и html? Можно же >> > полностью описать весь html с помощью javascript плюс >> > .>раскрасить вместо использования css. >> > Я не о том немного. Я, скорее, об этом > .>Вот и примени свои четыре вопроса по отношению к css: > .>А потом по отношению и к html > "Вот валит, гад" (с) > Я ж не призываю отказываться от существующей связки JavaScript + CSS + HTML. > Я предлагаю.
Ты приводишь против XBL технологии некие аргументы, которые легко переносятся на HTML и CSS. Так собственно если уж
отказываться, то от всего, а если не от всего, то в чём XBL провинился? Чем он хуже HTML и CSS? Почему он не имеет права
на существование?
> Так _что_ же такого предоставляет XBL, чтобы было необходимо вводить > новую технологию, а не "допилить" существующие?
Он превносит формальное описание понятия "компонента" и "байдинга", закрепляет это понятие стандартом.
Стандарт описывает, как можно аттачить события, свойства, методы к элементу-компоненту, как наследовать поведение
компонента, определяет алгоритм процесса байдинга/анбайдинга, определяет как компонент маппит его использование в
документе на реально отображаемые объекты.
Да, ты можешь написать библиотеку на js, которая будет делать тоже самое. Но тебе всё равно придётся продумывать все эти
детали, которые будут интерфейсом библиотеки и создавать "xbl-библиотеку не использующую xml". Но в итоге ты получишь
тоже самое, что и XBL, но чуть-чуть с другим синтаксисом — вместо xml-based будет js-based.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Mamut wrote:
>> .>Ничем не лучше. >> Лучше. Нет смеси несмесимых технологий. Да еще с такой убогой (никакой) .>Просто вы не умеете их смешивать.
.>Единственная разница — " вместо { и function() нет.
Если разницы нет, то зачем это нужно?
>> Первое хоть еще дебагить можно. А второе? .>Да, venkmann дебаггит (афаир). Сформулирую тезис — в данном случае разница чисто в чуть-чуть других символах!
Если разницы нет, то зачем это нужно?
>> Что-то мне говорит, что XML — это тоже не панацея от кодировок .>Ну просто там нет проблемы с кодировками.
Решил погуглить на тему XML Encoding Problems...
Например:
What's needed is to look at the input and output files of the transformation
directly (with a hex editor) to see:
(a) what the declared encoding is (what's in the XML declaration)
(b) what the actual encoding is
То есть, если у меня в XML указан один енкодинг, а сохранен он в другом енкодинге, то проблемы будут, я так понимаю
>> Я все равно не понял, зачем это нужно (особенно в свете предлагаемых >> packages) .>Неужели непонятно зачем нужна возможность в html-ную страницу помещать математическую формулу mathml или векторный .>рисунок svg?
И как xbl позволит это сделать? Магическим байндингом? Можно пример? Чтоб там был и HTML и XBL. Чтобы я четко увидел и понял, что
#mysvg {
binding: "mysvg.xml#test";
}
вставит на место <div id="mysvg"> рисунок, сгенерированный из SVG. И еще объяснение, почему он туда вставится
.>(кто такие packages и какое отношение они имеют к xml или xbl я не понял)
эээ. это я уже сам не помню
>> Быть может Но пока XBL только в XUL ведь применяется И здесь приводили >> примеры из XUL... .>XBL также легко прикручивается и к HTML-элементам. Оно даже давно работает.
Где? Не вижу
>> Так в чем эта выгода? .>возможность генерации/обработки xml-based документов с помощью того же xml-парсера (и related технологий, типа xslt).
Хм. У меня возможность обработки xml-based документов была и до этого? Как это применимо к XBL?
.>Ты приводишь против XBL технологии некие аргументы, которые легко переносятся на HTML и CSS. Так собственно если уж .>отказываться, то от всего, а если не от всего, то в чём XBL провинился? Чем он хуже HTML и CSS? Почему он не имеет права .>на существование?
Потому что они решают определенные задачи. Зачем нужна еще одна технология, решающая те же задачи, я не понимаю
Я пока не увидел ни одного довода _за_ XBL. Конкретного, не сферовакуумного довода
>> Так _что_ же такого предоставляет XBL, чтобы было необходимо вводить >> новую технологию, а не "допилить" существующие? .>Он превносит формальное описание понятия "компонента" и "байдинга", закрепляет это понятие стандартом. .>Стандарт описывает, как можно аттачить события, свойства, методы к элементу-компоненту, как наследовать поведение .>компонента, определяет алгоритм процесса байдинга/анбайдинга, определяет как компонент маппит его использование в .>документе на реально отображаемые объекты.
Зачем для этого нужна еще одна технология? Все это также можно закрепить и описать двумя-тремя изменениями в уже существующих технологиях.
.>Да, ты можешь написать библиотеку на js, которая будет делать тоже самое. Но тебе всё равно придётся продумывать все эти .>детали, которые будут интерфейсом библиотеки и создавать "xbl-библиотеку не использующую xml". Но в итоге ты получишь .>тоже самое, что и XBL, но чуть-чуть с другим синтаксисом — вместо xml-based будет js-based.
Для того, чтобы получить те "бенифиты" XBL, что мне пока показывали, нужно, чтобы браузер нативно поддерживал всего две вещи — getElementsByCSS и getElementsByXPath. Зачем мне XBL?
ЫЫЫ. Прошу еще раз.
Приведите мне конкретный пример использования XBL, который покажет, насколько XBL облегчит мне жизнь. Пусть даже этот пример не будет работать нигде, ни в одном браузере. Просто покажите мне, какие, невиданные доселе и нерешаемые или решаемые, но с трудом, задачи позволит мне решить XBL.
То есть, покажите мне доказательства того, что XBL нужен.
Mamut wrote:
> .>Единственная разница — " вместо { и function() нет. > Если разницы нет, то зачем это нужно?
В синтаксисе нет, семантика отличается.
> То есть, если у меня в XML указан один енкодинг, а сохранен он в другом > енкодинге, то проблемы будут, я так понимаю
Ну значит это невалидный XML. Ни один уважающий себя XML-writer не позволит себе такое сгенерить, ни один уважающий себя
XML-parser не позволит себе такое распарсить. А если у кого-то кривые руки, то ничего не поможет. Несоответствие
енкодинга содержимому может возникнуть только если XML-ку редактируют как обычный текстовый файл.
Вот я могу написать js программу и не закрыть где-нибудь скобку. Значит ли это, что в js проблема со скобками?
>> > Я все равно не понял, зачем это нужно (особенно в свете предлагаемых >> > packages) > .>Неужели непонятно зачем нужна возможность в html-ную страницу помещать > математическую формулу mathml или векторный > .>рисунок svg? > И как xbl позволит это сделать? Магическим байндингом? Можно пример? > Чтоб там был и HTML и XBL. Чтобы я четко увидел и понял, что > #mysvg { > binding: "mysvg.xml#test"; > } > вставит на место <div id="mysvg"> рисунок, сгенерированный из SVG. И еще > объяснение, почему он туда вставится
Насчёт svg у меня не получилось заставить работать, как я понимаю ещё не доделано, а вот mathml заработал. Пример ниже.
> .>XBL также легко прикручивается и к HTML-элементам. Оно даже давно > работает. > Где? Не вижу
На гугле забанили?
>> > Так в чем эта выгода? > .>возможность генерации/обработки xml-based документов с помощью того же > xml-парсера (и related технологий, типа xslt). > Хм. У меня возможность обработки xml-based документов была и до этого? > Как это применимо к XBL?
XBL это xml-based документ...
> Приведите мне конкретный пример использования XBL, который покажет, > насколько XBL облегчит мне жизнь. Пусть даже этот пример не будет > работать нигде, ни в одном браузере. Просто покажите мне, какие, > невиданные доселе и нерешаемые или решаемые, но с трудом, задачи > позволит мне решить XBL. > То есть, покажите мне доказательства того, что XBL нужен.
Под моим FF 2.0.0.2 работает. Заметь, ни строчки javascript! Для описания того, что как должно рисоваться
используются только языки описания. Язык программирования javascript понадобится только для программирования поведения.
>> То есть, если у меня в XML указан один енкодинг, а сохранен он в другом >> енкодинге, то проблемы будут, я так понимаю .>Ну значит это невалидный XML. Ни один уважающий себя XML-writer не позволит себе такое сгенерить, ни один уважающий себя .>XML-parser не позволит себе такое распарсить. А если у кого-то кривые руки, то ничего не поможет. Несоответствие .>енкодинга содержимому может возникнуть только если XML-ку редактируют как обычный текстовый файл. .>Вот я могу написать js программу и не закрыть где-нибудь скобку. Значит ли это, что в js проблема со скобками?
Хм. Разве XML документ не просто текстовый документ?
На этот вопрос не надо отвечать Он был провокационный Но! Утверждать, что в XML нет проблем с кодировками тоже неверно. Вот настрою я апач так, чтобы он мне все только в cp-1251 будет выдавать...
>> .>XBL также легко прикручивается и к HTML-элементам. Оно даже давно >> работает. >> Где? Не вижу .>На гугле забанили?
Лень искать
>>> > Так в чем эта выгода? >> .>возможность генерации/обработки xml-based документов с помощью того же >> xml-парсера (и related технологий, типа xslt). >> Хм. У меня возможность обработки xml-based документов была и до этого? >> Как это применимо к XBL? .>XBL это xml-based документ...
На самом деле фраза
>> .>возможность генерации/обработки xml-based документов с помощью того же
>> xml-парсера (и related технологий, типа xslt).
это сфероконь И, имхо, все это понимают Применимо к XBL этим будут заниматься единицы (если вообще будут заниматься)
>> Приведите мне конкретный пример использования XBL, который покажет, >> насколько XBL облегчит мне жизнь. Пусть даже этот пример не будет >> работать нигде, ни в одном браузере. Просто покажите мне, какие, >> невиданные доселе и нерешаемые или решаемые, но с трудом, задачи >> позволит мне решить XBL. >> То есть, покажите мне доказательства того, что XBL нужен. .>Под моим FF 2.0.0.2 работает. Заметь, ни строчки javascript! Для описания того, что как должно рисоваться .>используются только языки описания. Язык программирования javascript понадобится только для .>программирования поведения. .>
code skip
.>
О. Вот в таком варианте уже понятно Спасибо. Такое применение мне более-менее нравится
Осталось определить временные рамки, в течение которых равнозначная реализация MathML и SVG появится в других браузерах
Здравствуйте, Mamut, Вы писали:
.>>Вопрос не понял. Ты, случаем, XUL и XBL не путаешь? M>Быть может Но пока XBL только в XUL ведь применяется И здесь приводили примеры из XUL...
Я же тебе приводил пример использования XBL c XHTML. В Mozilla XBL работает везде.
.>>>Вопрос не понял. Ты, случаем, XUL и XBL не путаешь? M>>Быть может Но пока XBL только в XUL ведь применяется И здесь приводили примеры из XUL...
A>Я же тебе приводил пример использования XBL c XHTML. В Mozilla XBL работает везде.
Во я тогда и не понял, что ж внем такого суперского, что надо было выдумывать новую технологию. Мне, правда, уже показали пример
.>ни один уважающий себя XML-parser не позволит себе такое распарсить.
Ну это по разному бывает. Есть три способа определить систему применяемого типа unicode. Кто-то сравнивает их, кто-то нет. Вобщем по разному бывает.
Здравствуйте, Mamut, Вы писали:
.>>>>Вопрос не понял. Ты, случаем, XUL и XBL не путаешь? M>>>Быть может Но пока XBL только в XUL ведь применяется И здесь приводили примеры из XUL... A>>Я же тебе приводил пример использования XBL c XHTML. В Mozilla XBL работает везде. M>Во я тогда и не понял, что ж внем такого суперского, что надо было выдумывать новую технологию. Мне, правда, уже показали пример
Здравствуйте, GlebZ, Вы писали:
.>>ни один уважающий себя XML-parser не позволит себе такое распарсить. GZ>Ну это по разному бывает. Есть три способа определить систему применяемого типа unicode. Кто-то сравнивает их, кто-то нет. Вобщем по разному бывает.
Есть стандарт на это дело: http://www.w3.org/TR/2006/REC-xml-20060816/#sec-guessing
Значит вопрос упирается в то, насколько верно поддерживается стандарт.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>Есть стандарт на это дело: http://www.w3.org/TR/2006/REC-xml-20060816/#sec-guessing .>Значит вопрос упирается в то, насколько верно поддерживается стандарт.
Заметь. — Non Normarive. Там практически ничто и не утверждается. Там только описано варианты как можно определить, но нет требований. И по жизни пишет кто как хочет. Многие пропускают декларацию.