Comments 18
с ИЕ к сожалению порой бывает сложно, как и в этом примере :)
если кто подскажет, как реализовать (учитывая, что ие не поддерживает css свойство opacity) — буду рад добавить во фреймворк
если кто подскажет, как реализовать (учитывая, что ие не поддерживает css свойство opacity) — буду рад добавить во фреймворк
ну а как во всех других фреймворках сделано? пока не увидел ничего уникального, а раз это есть у других, значит возможно к реализации
>если кто подскажет, как реализовать (учитывая, что ие не поддерживает css свойство opacity)
www.tigir.com/opacity.htm
М.б. все-таки стоит отказаться от фреймворка, у которого «разногласия с IE7» и как выяснилось с ie6? и в prototype и в jquery эти вещи давно решены.
www.tigir.com/opacity.htm
М.б. все-таки стоит отказаться от фреймворка, у которого «разногласия с IE7» и как выяснилось с ie6? и в prototype и в jquery эти вещи давно решены.
Честно говоря, я слабо понимаю условие на IE в функции getOpacity, разве что для того, чтобы фреймворк был совсем универсален.
Я давно уже не встречал верстки только под IE, кроссбраузерно же все устанавливают 2 свойства и opacity и filter:alpha. Поэтому в большинстве случаев this.style.opacity более чем достаточно.
Если же хотите абсолютной универсальности, то как минимум стоит использовать функцию getStyle, т.к. далеко не всегда стили прописываются inline, а для IE не вижу сложности, вам просто нужно разобрать строку.
Или я что-то не понимаю?
Я давно уже не встречал верстки только под IE, кроссбраузерно же все устанавливают 2 свойства и opacity и filter:alpha. Поэтому в большинстве случаев this.style.opacity более чем достаточно.
Если же хотите абсолютной универсальности, то как минимум стоит использовать функцию getStyle, т.к. далеко не всегда стили прописываются inline, а для IE не вижу сложности, вам просто нужно разобрать строку.
Или я что-то не понимаю?
Странно, что все сразу бросились на getOpacity, хотя эта функция применяется очень редко, а критикуют ее, как будто это основа всего фреймворка :)
В общем, функция понадобилась для получение прозрачности элемента. Применяется она пока в единственном случае: при плавном изменении прозрачности элемента в эффектах (к примеру исчезновение или появление элемента). Тут и нужна функция — перед использованием эффекта нужно запомнить изначальное значение прозрачности, чтобы потом его можно было восстановить.
В браузерах, поддерживающих CSS свойство это сделать просто. В ИЕ я подозреваю, придется парсить свойство filter. Но в большинстве случаев, элементы не являются прозрачными (т.е. opacity = 1), поэтому workaround был — просто вернуть элемент в непрозрачное состояние, а дописание функции было отложено до того момента, когда она действительно понадобится. Пока что такого момента не наступило.
В общем, функция понадобилась для получение прозрачности элемента. Применяется она пока в единственном случае: при плавном изменении прозрачности элемента в эффектах (к примеру исчезновение или появление элемента). Тут и нужна функция — перед использованием эффекта нужно запомнить изначальное значение прозрачности, чтобы потом его можно было восстановить.
В браузерах, поддерживающих CSS свойство это сделать просто. В ИЕ я подозреваю, придется парсить свойство filter. Но в большинстве случаев, элементы не являются прозрачными (т.е. opacity = 1), поэтому workaround был — просто вернуть элемент в непрозрачное состояние, а дописание функции было отложено до того момента, когда она действительно понадобится. Пока что такого момента не наступило.
странно реализована функция toHex, почему не просто:
number.toString(16).toUpperCase()
Вечно программисты, пришедшие с PHP, начинают подобие статической классовой модели лепить в Javascript. Потом еще и идеи MVC в элементы интерфейса будете внедрять наверное :-)
Зачем лепить из одного языка, другой, ну удобно вам наследование организовывать, как в классах, так сделайте простенький конструктор, зачем эти всякие singleton, static и private в Javascript, где вы их будете применять? Да и вообще в большинстве случаев достаточно одной, максимум двух, функции-конструкторов с наследованием по прототипу для создания любого интерфейса в Javascript. Все остальное лишь добавляет в фреймворк лишний код, неоправданные межкомпонентные связи и, как следствие, снижает производительность, которой Javascript и так похвастаться не может, особенно в старых браузерах.
Зачем лепить из одного языка, другой, ну удобно вам наследование организовывать, как в классах, так сделайте простенький конструктор, зачем эти всякие singleton, static и private в Javascript, где вы их будете применять? Да и вообще в большинстве случаев достаточно одной, максимум двух, функции-конструкторов с наследованием по прототипу для создания любого интерфейса в Javascript. Все остальное лишь добавляет в фреймворк лишний код, неоправданные межкомпонентные связи и, как следствие, снижает производительность, которой Javascript и так похвастаться не может, особенно в старых браузерах.
Ну, если честно, я это применяю в повседневной разработке.
Наследование особенно удобно в UI интерфейсах. К примеру, у нас есть список, который мы можем расширить до дерева, до списка с перетаскиваемыми элементами или с сортируемыми.
На скорости, я бы не сказал, что это пагубно влияет, к тому же современные браузеры ускоряют выполнение javascript (взять тот же гугл хром с V8 и новый сафари, который его даже опережает по скорости). При том, что скорость разработки это существенно увеличивает.
Singletone и static — это просто синтаксический сахар. На скорость это абсолютно не влияет, зато радует глаз при написании кода, да и просто удобно.
PS: ну и не совсем понял причем тут PHP :) я бы сказал, программисты на яве были бы более склонны к объектной модели для javascript
Наследование особенно удобно в UI интерфейсах. К примеру, у нас есть список, который мы можем расширить до дерева, до списка с перетаскиваемыми элементами или с сортируемыми.
На скорости, я бы не сказал, что это пагубно влияет, к тому же современные браузеры ускоряют выполнение javascript (взять тот же гугл хром с V8 и новый сафари, который его даже опережает по скорости). При том, что скорость разработки это существенно увеличивает.
Singletone и static — это просто синтаксический сахар. На скорость это абсолютно не влияет, зато радует глаз при написании кода, да и просто удобно.
PS: ну и не совсем понял причем тут PHP :) я бы сказал, программисты на яве были бы более склонны к объектной модели для javascript
Полностью поддерживаю…
JS любить и понимать надо, а не переделывать визуально синтаксис под что-то.
Это мне напоминает… подмену для C, чтобы было похоже на Pascal.
#define begin {
#define end }
JS любить и понимать надо, а не переделывать визуально синтаксис под что-то.
Это мне напоминает… подмену для C, чтобы было похоже на Pascal.
#define begin {
#define end }
а почему не mootools-то? судя по всему, у вас получится почти копия, какой в этом смысл? чем ваш фреймворк лучше/отличается от мутулс?
да не было тогда еще mootools :)
кстати, в mootools меня не совсем устраивает синтаксис при создании классов
кстати, в mootools меня не совсем устраивает синтаксис при создании классов
тогда не было, а щас есть ) это как раз тот случай, когда лучше не увеличивать энтропию. если вы хотите сделать полноценный фреймворк, обойти мутулс будет очень сложно, там все уже вылизано и отточено.
имхо было бы несравнимо полезнее, если бы вы поучаствовали в популяризации мутулс, у них как раз не хватает евангелистов, да и плагинов еще можно много сделать, хоть и есть www.clientcide.com/js и т.п.
и ведь вам придется тратить лишнее время на поддержку вашего фреймворка, которое вы могли бы потратить на вашу цмс, например. цмс это все таки платформа, а js-библиотека это всего лишь один из компонентов.
>кстати, в mootools меня не совсем устраивает синтаксис при создании классов
а чем? я что-то не вижу различий. плюс там есть options/events-сахар, implement и т.д.
имхо было бы несравнимо полезнее, если бы вы поучаствовали в популяризации мутулс, у них как раз не хватает евангелистов, да и плагинов еще можно много сделать, хоть и есть www.clientcide.com/js и т.п.
и ведь вам придется тратить лишнее время на поддержку вашего фреймворка, которое вы могли бы потратить на вашу цмс, например. цмс это все таки платформа, а js-библиотека это всего лишь один из компонентов.
>кстати, в mootools меня не совсем устраивает синтаксис при создании классов
а чем? я что-то не вижу различий. плюс там есть options/events-сахар, implement и т.д.
...Prototype был больше популярен в RoR сообществе, поэтому я его не особо хотел использовать :)
конструктив. ога
Sign up to leave a comment.
Mohawk / Объектная модель