AndrewVK wrote: > C>У меня стоит IE7, я им пользуюсь для тестирования. Это такая $#%^$*#$# — > C>тормозит и глючит даже на простых страницах. Даже IE6 был лучше. > А у меня стоит IE7, и никакого ухудшения по сравнению с IE6 я не заметил.
Открой большое изображение и попробуй его прокрутить.
Меня это жутко ДОСТАЕТ — приходится работать с сайтом, где диаграммы
можно просматривать только через IE. Если размер диаграммы больше
размера окна — работать становится невозможно. IE6 и FF работают без
всяких проблем.
Ну и по мелочам — часто плывет по непонятным причинам разметка. Причем
даже в онлайновом MSDN. Лечится клавишей F5.
Еще вечные проблемы с выделением текста, что именно выделит IE — каждый
раз сюрприз.
>> Если в IE7 есть ошибка, и она будет напрягать хоть немного заметную долю >> аудитории, то глюк вычистят и выпустят патч. Тольк и всего. Так что я >> вообще не понимаю твоих "обличительных речей". C>У меня стоит IE7, я им пользуюсь для тестирования. Это такая $#%^$*#$# — C>тормозит и глючит даже на простых страницах. Даже IE6 был лучше.
Поддерживаю на 100%. Я тоже перелез на мозиллу только тогда, когда сдуру поставил себе IE7. Мне приходилось часто работать с простыми, но большими HTML-страницами (десяток метров и больше). Если IE6 на них просто подтормаживал, то работа с ними из IE7 уже очень сильно раздражает. Мозилла в этом плане выглядит куда приятнее.
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Mamut, Вы писали:
A>>>Ну а как ещё новые поведение и свойства добавлять элементам? M>>Например, вот так: M>>
A>Атрибут это не свойство (хотя в MS так не думают). Да и свойсво click ты не добавил, а изменил его значение.
Ну ладно
A>Теперь у нашей кнопки (здесь опитывается кнопка панели инструментов), есть свой конструктор, свои поля (в том числе и read only) и свои методы. А кроме того она ещё и реализует интерфейс nsIObserver, т. е. способна работать обсервером.
class myButton implements nsIObserver
{
function myButton()
{
var name = Components
.classes['@mozilla.org/network/io-service;1']
.getService(Components.interfaces.nsIIOService)
.getProtocolHandler("file")
.QueryInterface(Components.interfaces.nsIFileProtocolHandler)
.getURLSpecFromFile(this.dataFile);
this.dataSource = this.rdfService.GetDataSourceBlocking(name);
// Initialize current search engine.
setTimeout(function(aThis) { aThis.searchEngine = aThis.searchBar.currentEngine; }, 0, this);
// Add "browser-search-engine-modified" notification observer.
Components
.classes["@mozilla.org/observer-service;1"]
.getService(Components.interfaces.nsIObserverService)
.addObserver(this, "browser-search-engine-modified", false);
}
...
}
единственное, енльзя, наверное, реализовать readOnly поля. Но их можно сделать private и определить к ним getters.
В том яваскрипте, что имеем сейчас реализовать интерфейс nsIObserver можно и так, просто определив необходимые функции. Ну что-то в стиле
var myButton = function() {
// это наш конструктор
};
myButton.prototype = {
observe = function(aEngine, aTopic, aVerb){
if (aTopic == "browser-search-engine-modified" && aVerb == "engine-current")
this.searchEngine = aEngine;
};
// и так далее...
}
Да. У нас нет read-only аттрибутов. А в данном контексте они нам настолько нужны, чтобы создавать практически худший из возможных вариантов XML-языка со смесью XML и CData с Яваскриптом внутри:
Кстати. Для добавления новых полей к существующим объетам умные люди же придумали функцию extend:
extend = function() {
// copy reference to target objectvar target = arguments[0],
a = 1;
var prop;
while (prop = arguments[a++])
// Extend the base objectfor ( var i in prop ) target[i] = prop[i];
// Return the modified objectreturn target;
Здравствуйте, Mamut, Вы писали:
A>>Теперь у нашей кнопки (здесь опитывается кнопка панели инструментов), есть свой конструктор, свои поля (в том числе и read only) и свои методы. А кроме того она ещё и реализует интерфейс nsIObserver, т. е. способна работать обсервером. M>Ну например, тогда так (на основе http://developer.mozilla.org/es4/spec/spec.html, которого, правда, еще нет):
Вот именно, что нет. )
M>В том яваскрипте, что имеем сейчас реализовать интерфейс nsIObserver можно и так, просто определив необходимые функции. Ну что-то в стиле M>
M>var myButton = function() {
M> // это наш конструктор
M>};
M>myButton.prototype = {
M> observe = function(aEngine, aTopic, aVerb){
M> if (aTopic == "browser-search-engine-modified" && aVerb == "engine-current")
M> this.searchEngine = aEngine;
M> };
M> // и так далее...
M>}
M>
А заставить тепрь это работать? С XBL это будет выглядеть так:
Т. е. в разметке у нас обычный <toolbutton>, а вот после присоединения CSS уже нечто другое.
M>Да. У нас нет read-only аттрибутов. А в данном контексте они нам настолько нужны, чтобы создавать практически худший из возможных вариантов XML-языка со смесью XML и CData с Яваскриптом внутри:
Ну не хуже чем HTC.
M>Кстати. Для добавления новых полей к существующим объетам умные люди же придумали функцию
К существующим да. А чтобы новые создавались с дополнительными свойствами?
Здравствуйте, Sinclair, Вы писали:
A>>Так опубликуй этот набор. S>Ну вот например, многие ли знают об атрибутах accept и size для <input type=file>? А они между прочим стандартизованы еще десять лет назад в HTML 3.2. Я был бы не против поддержки этой возможности.
Вот что думает Тим Бернерс-Ли по этому поводу:
> From: Tim Berners-Lee <timbl@w3.org>
> Date: Fri, 31 Mar 2000 16:37:02 -0500
>
>... you can write:
>
> <INPUT name="audiofile1" type="file" accept="audio/*">
>
> and be prompted for various means of audio input (a recorder,
> a mixing desk, a file icon drag and drop receptor, etc).
> Here "file" does not mean "from a disk" but "large body of
> data with a MIME type".
>
> As someone who used the NeXT machine's "lip service" many
> years ago I see no reason why browsers should not implement
> both audio and video and still capture in this way. There
> are many occasions that voice input is valuable. We have speech
> recognition systems in the lab, for example, and of course this
> is very much needed.... So you don't need to convince me of
> the usefulness.
>
> However, browser writers have not implemented this!
>
> One needs to encourage this feature to be implemented, and
> implemented well.
>
> I hope this helps.
>
> Tim Berners-Lee
AndrewVK wrote: > C>Открой большое изображение и попробуй его прокрутить. > Делал это неоднократно. Все в порядке.
Не верю.
У меня вот на этом изображении просто глазами видно как оно
прорисовывается при прокрутке по горизонтали.
http://rsdn.ru/File/37054/newrings_cassini_big.jpg
> C>Ну и по мелочам — часто плывет по непонятным причинам разметка. > Тоже не замечал. http://rsdn.ru/File/37054/iebug.png — через минуту браузинга. Причем
проявляется не всегда.
> C> Причем даже в онлайновом MSDN. > С MSDN все хорошо.
Плохо. Сейчас лень искать проблему.
> C>Еще вечные проблемы с выделением текста, что именно выделит IE — каждый > C>раз сюрприз. > Ну это и в IE6 было.
Не до такой степени.
У меня такого не было ни разу.
>> C>Еще вечные проблемы с выделением текста, что именно выделит IE — каждый >> C>раз сюрприз. >> Ну это и в IE6 было. C>Не до такой степени.
Надеюсь, JavaScript 2 позволит им полностью отказаться от XML...
Единственный явный минус текущего Яваскрипта — невозможность сокрытия полей (private/read-only). Что может быть единственным аргументом в пользу использования такого XML. Но, имхо, для внутренних нужд легче было слегка расширить Javascript необходимыми модификаторами до появления стандларта... Но это только имхо
M>>Кстати. Для добавления новых полей к существующим объетам умные люди же придумали функцию
A>К существующим да. А чтобы новые создавались с дополнительными свойствами?
У тебя на компьютере сколько процессоров стоит? ИМХО, то что AndrewVK не видит этих проблем может быть связано с тем что у него многоядерный или гипертредный проц.
Здравствуйте, Left2, Вы писали:
L>Мне приходилось часто работать с простыми, но большими HTML-страницами (десяток метров и больше). /.../ Мозилла в этом плане выглядит куда приятнее.
У FF проблема с большими таблицами. Например, страница на 15Мб у которой 95% это одна большая таблица. IE6 открывает за пару минут. А FF намного дольше.
Здравствуйте, Mamut, Вы писали:
A>>А заставить тепрь это работать? С XBL это будет выглядеть так: M>Ну так я не виноват, что Мозилла не позволяет
Так ведь никто не позволяет. А использовать хочется уже сейчас.
M>Просто я не понимаю, где разница между, например:
Разница в "описательности". ) XML болле наглядно (и для человека, и для машины) описывает, в данном случае, метод, название, аргументы. Тело метода, естественно, ни кого на этом этапе не интересует, поэтому оно в CData. Но это моё видение. Кроме того, второй вариант сейчас не рализуем. )
M>The devil, как говорится, is in the details Единственное, что не позволит приведенный пример кода перевести на существующий Javascript, это: M>
Почему? Это ж просто наследование.
M>>>Кстати. Для добавления новых полей к существующим объетам умные люди же придумали функцию A>>К существующим да. А чтобы новые создавались с дополнительными свойствами? M>В смысле? Ну, например:
мы получим, что все <toolbarbutton class="my-button"> будут обладать нужными свойствами и поведением. А в твоём случае придётся сначала найти все нужные элементы, а потом уже их изменить.
Здравствуйте, AndrewVK, Вы писали: AVK>Нет. А тебе что, этот survey не приходил?
Какой именно сюрвей? AVK>А вобще, Ложечкин обещал познакомить с русскими товарищами из IE team, так что у тебя будет возможность рассказать о своих пожеланиях лично.
cool! S>>Я бы кстати с удовольствием пообсуждал с народом (типа c-smile) вопросы существующих браузеров, чтобы сформировать свое мнение. AVK>Типа c-smile бессмысленно, бо там речь шла не о фичах движка, а о пользовательских фичах.
А-а. Всё равно интересно .
S>>Даже неумение IE работать с альфаканалом в PNG и то было заборото. AVK>Так починили же в IE7.
Ну, если честно, то нам уже даже и это не так важно. Да, приятно, но в целом воркэраунд и в 6.0 работает практически удовлетворительно. Убитые на него человеко-часы все равно не вернешь. А, во, кстати вспомнил: есть там проблема в бехавиорах, что в них все пути считаются относительно базы документа. У нас из-за этого были проблемы. Ну то есть вот если в .css сослаться на url (в атрибуте background там или еще где), то этот url резолвится относительно .css. И это правильно. А вот если я в этом .css прикрутил bahavior, то в нем нет способа сослаться на url "относительно CSS". Из-за этого иногда приходится маяться дурью и генерировать лишнюю динамику.
1.2.0 alpha rev. 655
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
A>>>А заставить тепрь это работать? С XBL это будет выглядеть так: M>>Ну так я не виноват, что Мозилла не позволяет
A>Так ведь никто не позволяет. А использовать хочется уже сейчас.
Гады
M>>Просто я не понимаю, где разница между, например:
A>Разница в "описательности". ) XML болле наглядно (и для человека, и для машины) описывает, в данном случае, метод, название, аргументы. Тело метода, естественно, ни кого на этом этапе не интересует, поэтому оно в CData. Но это моё видение. Кроме того, второй вариант сейчас не рализуем. )
Тут промолчу, потому что грозит большой флейм по поводу читаемости XML
M>>The devil, как говорится, is in the details Единственное, что не позволит приведенный пример кода перевести на существующий Javascript, это: M>>
Просто наследования в Яваскрипте как бы нет.
M>>>>Кстати. Для добавления новых полей к существующим объетам умные люди же придумали функцию A>>>К существующим да. А чтобы новые создавались с дополнительными свойствами? M>>В смысле? Ну, например:
A>В смысле, написав: A>
A>.my-button {
A> -moz-binding: url("chrome://my-extension/content/my-button.xml#my-button");
A>}
A>
A>мы получим, что все <toolbarbutton class="my-button"> будут обладать нужными свойствами и поведением. А в твоём случае придётся сначала найти все нужные элементы, а потом уже их изменить.
А. Ну это уже косяки конкретной реализации Они бы могли позволить, например, писать следующее
myButton = function()
{
// описываем конструктор
}
myButton.prototype = {
id : "myButton", // хотя стоит ли? можно вычислить из имени класса/функции...extends : nsIObserver,
// дальше описываем реализацию...
someMethod : function(param1, param2) {
// ...
}
}
Здравствуйте, Mamut, Вы писали:
M>Тут промолчу, потому что грозит большой флейм по поводу читаемости XML
Не будем. )
A>>Почему? Это ж просто наследование. M>Просто наследования в Яваскрипте как бы нет.
Оно как бы есть, но как бы не простое. ) Всё ж таки прототипный язык.
M>А. Ну это уже косяки конкретной реализации Они бы могли позволить, например, писать следующее M>
M>myButton = function()
M>{
M> // описываем конструктор
M>}
M>myButton.prototype = {
M> id : "myButton", // хотя стоит ли? можно вычислить из имени класса/функции...
M> extends : nsIObserver,
M> // дальше описываем реализацию...
M> someMethod : function(param1, param2) {
M> // ...
M> }
M>}
M>
Здравствуйте, Left2, Вы писали:
L>У тебя на компьютере сколько процессоров стоит? ИМХО, то что AndrewVK не видит этих проблем может быть связано с тем что у него многоядерный или гипертредный проц.
Не угадал. У меня вполне себе одноядерный Athlon 3500+.
Здравствуйте, Sinclair, Вы писали:
AVK>>Нет. А тебе что, этот survey не приходил? S>Какой именно сюрвей?
По IE8. Он один, собственно, был. Месяца полтора назад.
S>>>Даже неумение IE работать с альфаканалом в PNG и то было заборото. AVK>>Так починили же в IE7. S>Ну, если честно, то нам уже даже и это не так важно. Да, приятно, но в целом воркэраунд и в 6.0 работает практически удовлетворительно.
Это который через DirectX?
S>А, во, кстати вспомнил: есть там проблема в бехавиорах, что в них все пути считаются относительно базы документа. У нас из-за этого были проблемы. Ну то есть вот если в .css сослаться на url (в атрибуте background там или еще где), то этот url резолвится относительно .css. И это правильно. А вот если я в этом .css прикрутил bahavior, то в нем нет способа сослаться на url "относительно CSS". Из-за этого иногда приходится маяться дурью и генерировать лишнюю динамику.
Ну ХЗ. Я вобще довольно отдаленное отношение имею к Web-программированию.
anonymous wrote:
> Вот поэтому на мой взгляд и нужен XML. Машине будет трудно понять, что > ты написал в этом JS-файле, а валидный XML она всегда разберёт.
Теоретически сложностей с этим тоже нет, например, просто требовать, чтобы подключаемый .js содержал ф-цию getBinding с
аргуметом id, выдающую объект с нужными свойствами.
Однако, как сделано, так сделано. Каких-то особых преимуществ ни у того, ни у другого подхода — нет.
Единственное — xml позволяет не привязываться к языку программирования, если написано
то можно смело ожидать там xml-ку со строго определённой структурой xbl, не важно какой язык (конкретный язык можно в
самой xml-ке указать). А если ожидать всё время js, то нет возможности прикрутить другой язык. Либо придётся mime-type
смотреть, либо расширение файла, либо ещё как, короче только проблемы.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, anonymous, Вы писали:
A>Здравствуйте, Mamut, Вы писали:
A>>>Ну а как ещё новые поведение и свойства добавлять элементам? M>>Например, вот так: M>>
A>Атрибут это не свойство (хотя в MS так не думают). Да и свойсво click ты не добавил, а изменил его значение.
A>А как тебе такое? Правда это не HTML, а XUL. (Извиняюсь, за большой кусок кода, посто это один рально работающий binding.)
.поскипано.
A>Теперь у нашей кнопки (здесь опитывается кнопка панели инструментов), есть свой конструктор, свои поля (в том числе и read only) и свои методы. А кроме того она ещё и реализует интерфейс nsIObserver, т. е. способна работать обсервером.
Ну это мрак если честно. Это просто *не может быть* так сложно.
Примерно так надо:
CSS:
div.Foo
{
prototype: Foo; // все <div class="Foo"> будут иметь этот behavior
}
Script:
type Foo: Behavior
{
function onMouse(evt) {}
function onKey(evt) {}
property something(v) { get return this.tag; }
function doSomething() { ... }
}
$("div.Foo").doSomething();
Я похоже додолбил w3c что они решили реинкарнировать BECSS. Во всяком случае уже начали
говорить о binding атрибуте.
И вообще я буду вельми признателен если мне кто-нибудь объяснит
почему связывание DOM элемента с набором функций (классом)
нужно делать через XML — т.е. еще один язык?
Здравствуйте, ., Вы писали:
.>anonymous wrote:
>> Вот поэтому на мой взгляд и нужен XML. Машине будет трудно понять, что >> ты написал в этом JS-файле, а валидный XML она всегда разберёт. .>Теоретически сложностей с этим тоже нет, например, просто требовать, чтобы подключаемый .js содержал ф-цию getBinding с .>аргуметом id, выдающую объект с нужными свойствами. .>Однако, как сделано, так сделано. Каких-то особых преимуществ ни у того, ни у другого подхода — нет. .>Единственное — xml позволяет не привязываться к языку программирования, если написано .>
.>то можно смело ожидать там xml-ку со строго определённой структурой xbl, не важно какой язык (конкретный язык можно в .>самой xml-ке указать). А если ожидать всё время js, то нет возможности прикрутить другой язык. Либо придётся mime-type .>смотреть, либо расширение файла, либо ещё как, короче только проблемы.
Можно я еще раз повторю вопрос? Зачем там XM[b]L ?
<style>
div.myclass
{
binding: url(http://mysite/generate-binding.cgi#my-button);
}
</style>
<script type="text/something">
var myhandlers = { onClick:...; onDblClick:... }
for el in $("div.myclass") do el.assignHandlers = myhandlers;
</script>
Зачем для задачи связки языка A с HTML нужен еще язык B?