Хотелось бы увидеть код в контексте, чтобы попробовать в деле и что получится когда немного подправишь. Кое-что смущает(например this во вложенных функциях и многократная инициализация обработчиков, я просто не вкурсе как это js работает), но из того, что сразу бросается в глаза в этом кодея бы выделил вот такой момент
На сколько я понял из дальнейшего ell - это коллекция элементов, а не число, поэтому надо было писать вместо  i < ell всё-таки  i < ell.length. Ну это к вопросу о "запятых".

Это сообщение отредактировал(а) diadiavova - 15.12.2009, 00:32

ИМХО

Точно...пропёрся  

Вот так вроде работает

Это сообщение отредактировал(а) diadiavova - 15.12.2009, 01:37

мда, эта заморочка работает как надо.

будем иметь ввиду

вот конкретный локализованный пример:

вся загвоздка была в том, чтобы запихнуть в функцию и event и this. прописать их в хтмл - и получается без нагромождений, 
но надо же так, указав одним классом

Ну с this при использовании его в замыканиях вообще лучше дело не иметь, там вопрос мутный  , а вот через промежуточные параметры такие дела передаются без проблем. В принципе вот эта строчка могла выглядеть и так

Вот мне интересен другой вопрос(просто не в курсе как это в яваскрипте работает): когда ты в цикле объявляешь функцию это память не перегружает? Ведь по идее вот при вот таком коденовая функция создаётся при каждой итерации цикла. При чём эти все функции одинаковые. Мне почему-то кажется, что такой кодбудет работать более экономично по отношению к ресурсам. Или я чего-то не понимаю?

Это сообщение отредактировал(а) diadiavova - 15.12.2009, 16:36

Дак это ж совсем разные случаи.

В первом случае:

каждый раз в цикле создается индивидуальная функция и присваивается атрибуту meth элемента массива ar.

Во втором случае:

атрибуты math всех элементов массива ar указывают на одну и ту же единственную функцию myFunc.

Разумеется, второй вариант рациональнее.

-------------------------------------------------

И вообще, для наглядности сказанного выше кусочек демонстрационного кода  

Естественно разные. Результат один, а происходят разные вещи и расход ресурсов разный. Поэтому я и спрашиваю какие причины ля того, чтобы объявлять функцию в цикле?

согласен, уберу. но как тогда в неё засунуть эти параметры (event и this)?


как с mouseover поступить?

Ну event точно так же через параметр, а что до ссылки на элемент, то функцию ты в принципе можешь вывести в глобальную область и тогда слово this будет возвращать ссылку на объект.

Добавлено через 4 минуты и 54 секунды
А кроме того, объект события имеет ссылку на отправителя этого события. В ИЕ это свойство srcElement, а в файрфоксе точно не помню, кажется targetObject

образовалась новая проблема по этому вопросу

вот мы всё время говорили о textarea, но тут чёрт дёрнул меня подключить fckeditor. как знаете, эта штуковина заменяет текстарею на скрытое поле и фрейм. конечно, такой ползунок для такого эдитора ещё более полезен, но тут возникла естественная проблема - как только курсор оказывается над фреймом, то обработчик document.body.onmousemove конечно перестаёт действовать, ведь это не его документ

попытался в этом случае продублировать обработчики на фрейм, но там получилось такое нагромождение с этими parent и прочим, что пока снёс всё.

вооот, что хотел спросить: нет ли какого обходника простого или всё же придётся мучаться с линковкой?

Нет, я не в курсе. Но не вижу проблемы с обработкой событий фрейма, если он в том же домене, что и основной документ. Всё можно делать в одном документе, просто перенести в него все необходимые ссылки. Вот пример документа
А вот его фрейм
EditFrame.htm
Вся обработка производится в самом документе, просто в него надо добавить ссылки на нужные элементы фрейма.

так, я снова вернулся к этому вопросу.

значит, есть фрейм и надо приладить ползунок к нему. так как fckeditor вешает кучу своих событий, не хотелось бы ломать всё это дело.
придумалась мне вдруг такая схемка: мы жмём на ползунок, он расширяется (увеличивается высота и задаются отрицательные маргины вверх и низ) и получается поверх фрейма.

код такой:

в ИЕ7 работает отлично, в ФФ, опере и хроме проявляется странный эффект. слой не реагирует на изменение marginTop, но при этом, если назначить слою бордюр (тот закомментированный стиль), то работает нормально во всех браузерах.

какой-то тотальный дефект мозиллы или гекко, кто там у них в основе.
как бы с ним справится, чтоб без бордюра работало?

По очереди.
Тема интересная, но есть общие замечания в порядке критики.
Такой метод, конечно, удобен, как и аналог его, зашитый в браузер Safari3+ (активная область перетаскивания внизу справа). Но лучше, если бы его вообще не было. Т.е. реализовать автоматическое расширение textarea, как сделано в 
http://www.google.com/search?client=opera&...o-Grow+Textarea :
http://habrahabr.ru/blogs/habrahabr_ideas/11064/
http://habrahabr.ru/blogs/habrahabr_ideas/11064/
Общая проблема в реализации в том, что в Опере не хватает информации о содержимом (не возвращается высота текста), поэтому для полной кроссбраузерности требуется громоздкое решение с эмуляцией текстареи в невидимом Div. 

Если при этом надо ограничить максимальную высоту, вводим ещё один параметр максимальной высоты. Тогда и понадобится визуальная область перетаскивания. Тронули её - высота фиксируется.

В случае использования div designMode="on", думаю, все проблемы решаются нормальнее (хотя не пробовал), и более гибкая функциональность, чем обсуждаемая здесь, будет реализована легче, кратко и без костылей.

Короче, рекомендую сразу разрабатывать более продвинутую юзабельность.


По приведённому коду - что-то во всех этих примерах очень много лишнего. Уйти от глобальных переменных - как известно, это значит использовать замыкания. Или, как вариант, записать обработчик в оперируемый DOM-объект div class="area". Но на самом деле, хранить функцию в объекте не нужно, потому что курсор мыши всегда один . Как появится mouseup, так удаляем тот единственный  Listener("mousemove"), которому ничего не мешает быть единственным глобальным.

Есть баг в IE6 - не установлен .area div(font-size:4px} или сколько надо.
...
Этот последний метод с закрылками должен тоже нормально работать (только поставить прозрачный рисунок вместо заливки).