Mootools плагин для анимации AJAX-запросов без gif'ов

Захотелось как-то сделать анимацию выполнения ajax-запросов на чистом html+css и совсем без gif'ов. И сделал плагин для Mootools, который позволяет при добавлении одного файла Javascript получить различные по размеру, фону и типу анимированные иконки.

Плюсы:
  • Легкие. Отдельно взятый элемент весит не больше gif'а, а использовать его можно многократно стилизируя под разные фрагменты сайта/приложения.
  • Легко подключаются (см. пример ниже)
  • Кроссбраузерные. В отличие от суперкрасивых но CSS3 подобных элементов эти тестировались на IE 7+, Firefos 3+, Opera 11, Safari, Chrome, Mobile Safari 4+ и Android 2.2. Скорее всего будут работать и на IE6, Opera 10 и старших версиях Safari и Chrome, но не тестировалось.
  • Один файл для всех анимированных иконок сайта, а не отдельный gif на каждую ситуацию.
  • Базовый класс можно расширять дописывая свои анимации.
  • Это не связанно непосредственно с технологией, но тоже редко встречал, поэтому добавлю — некоторые анимации имеют режим in и out, что удобно для визуализации POST и GET запросов соответственно.
  • Я почему-то с детства не люблю анимированные gif'ы

И минусы:
  • В IE 9 элементы все равно оставлены квадратными. Хоть border-radius в нем и поддерживается, но имеет место баг (или фича) связанный с заливкой, который сходу обойти не удалось. Может кто подскажет как это можно сделать.
  • Теоретически может притормаживать на слабых машинах на старом браузере под нагрузкой. В тестах это не проявилось, но жизнь, как известно, от тестов отличается. Тестировалось на слабеньком нетбуке в IE 8 в режиме IE 7 и на моей виртуальной машине — слабее ничего не нашлось для тестов.
  • Наверняка в комментариях еще наберется...

А все остальное, как говорится, лучше один раз увидеть.
Демо здесь: http://lavmax.github.com/MUX.Loaders
Исходники и документация здесь: https://github.com/lavmax/MUX.Loaders

Пример использования:
// Создаем простейший элемент без параметров
var loader = new MUX.Loader.Bar();
loader.start(); // Запускает анимацию и показывает элемент
loader.stop(); // Останавливает анимацию и скрывает элемент

// Можно так же применять start() и stop() непосредственно к html-элементу
$('my-loaders-id').start();
$('my-loaders-id').stop();

// Можно получить html-элемент с помощью $
$(loader).inject(document.body);
// это тоже самое, что
loader.elem.inject(document.body);


Кому понравилось пользуйтесь, кому не понравилось ругайте конструктивно пожалуйста.
Поделиться публикацией

Похожие публикации

Комментарии 20
    0
    Круто. Серьезно, очень нравится.
      0
      Визуализация отправки/приема — отличная идея!
        0
        прикольно! а порт для jQuery планируеться?
          –1
          Полностью поддерживаю, очень бы хотелось видеть реализацию под jQuery!
            0
            К сожалению, пока не планируется. Там на самом деле небольшое семейство плагинов MUX на подходе, и если переводить то всю братию, а это несколько трудоемко.
            0
            Я так понял, небольшой баг. ФФ 3.6.11
              0
              С in все нормально при этом
                +1
                Спасибо, отловил. Занятный оказался баг. Проявлялся только в 3.6 (ни в 3.0, ни в 4.0 его нету) и только в одном этом варианте.
                0
                Очень здорово! Спасибо!
                  0
                  В IE 9 элементы все равно оставлены квадратными. Хоть border-radius в нем и поддерживается, но имеет место баг (или фича) связанный с заливкой, который сходу обойти не удалось. Может кто подскажет как это можно сделать.

                  Не используйте фильтры в IE, это не является решением, базирующимся на стандартах. Для IE10 используйте -ms-linear-gradient.
                    +1
                    Как-то не совсем понятно, о каком следовании стандартам может идти речь, если для разных версий предлагается использовать разные подходы. Либо уж следовать стандартам, либо пользоваться всеми доступными средствами, которые работают. А выбирать по читаемости и простоте поддержки в таком случае.
                      0
                      Фильтры IE не являются стандартным решением и, скорее всего, не будут дальше развиваться именно в таком виде. Они также не всегда совместимы с новыми возможностями CSS: в данном случае они мешают использовать border-radius.

                      Отсюда вопрос: зачем использовать нестандартный механизм? Только для достижения визуального эффекта и все средства хороши?

                      Тогда не надо говорить (это к автору топика), что в IE9 почему-то не работает border-radius, надо прямо сказать, что используется нестандартный механизм для градиентов, перекрывающий стандартный для border-radius.
                      +1
                      это не является решением, базирующимся на стандартах

                      Так другого решения для IE9 вроде и нету. Под IE10 я пока даже не тестировал, пусть он сначала до RC дорастет, а то они там еще десять раз все поменяют.
                        +1
                        А в Firefox <3.6, Opera < 11.10 нет ни стандартного, ни нестандартного механизма для градиентов — и что? А в старых версиях Webkit был другой (кастомный) синтаксис — и что?

                        Не поддерживаются градиенты? Может быть всунуть SVG|Flash|Silverlight или вставить картинкой через JS? Тоже ведь варианты, хотя и нестандартные.

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

                        Другими словами, используя
                        background-color: #7db9e8;
                        background-image: -moz-linear-gradient(top, #7db9e8 0%, #1E5799 59%);
                        background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#7db9e8), color-stop(59%,#1E5799));
                        background-image: filter: progid:DXImageTransform.Microsoft.gradient( startColorstr="#7db9e8", endColorstr="#1E5799",GradientType=0 );
                        background-image: -o-linear-gradient(top, #7db9e8 0%,#1E5799 59%);
                        


                        нужно честно отдавать себе отчет, чем грозят все нестандартные механизмы, либо ограничиваться стандартами (и, кстати, добавлять корректный синтаксис для webkit):

                        background-color: #7db9e8;
                        background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#7db9e8), color-stop(59%,#1E5799));
                        background-image: -webkit-linear-gradient(top, #7db9e8 0%, #1E5799 59%);
                        background-image: -moz-linear-gradient(top, #7db9e8 0%, #1E5799 59%);
                        background-image: -o-linear-gradient(top, #7db9e8 0%,#1E5799 59%);
                        background-image: -ms-linear-gradient(top, #7db9e8 0%,#1E5799 59%);
                        background-image: linear-gradient(top, #7db9e8 0%,#1E5799 59%);
                        
                        

                          0
                          нужно честно отдавать себе отчет, чем грозят все нестандартные механизмы

                          Я собственно постарался реализовать именно этот подход. Поэтому если при тестировании в ИЕ9 выявилась проблема с градиентной заливкой, отменил там бордер радиус. Кстати такая же история с мобильным сафари 4.

                          По поводу использования/неиспользования filter, это по большому счету остается на усмотрение разработчика использующего библиотеку. Те стили которые стоят по-умолчанию скорее всего будут надписываться при имплементации и какие бэкграунды пропишет разработчик решать ему.

                          И кстати Вы натолкнули меня на мысль, чтобы сделать в ИЕ9 радиус, если фон задан строкой, т.е. обычный цвет. В этом случае работает корректно. Сделал. Спасибо.
                      0
                      Здорово! Как бы еще это к Request прикрутить глобально, или свой класс нужно писать?
                        0
                        Насчет Request не думал, если честно. Может что-то вроде:
                        Request.prototype.options.onRequest = function()
                        {
                            if (this.options.muxLoader)
                                this.options.muxLoader.start();
                        }
                        Request.prototype.options.onComplete = function()
                        {
                            if (this.options.muxLoader)
                                this.options.muxLoader.stop();
                        }
                        


                        При этом в опциях создания Request надо будет просовывать ваш лоадер или его элемент, когда нужно. А если используются индивидуальные обработчики onRequest и onComplete прописать в них вызов прототипа:
                        new Request({
                            ...
                            muxLoader: $('my-loader-id'),
                            ...,
                            onRequest: function()
                            {
                                ... // индивидуальный код реквеста
                                // явный вызов общего обработчика, потому что иначе он просто надпишется индивидуальным.
                                Request.prototype.options.onRequest();
                            }
                        });
                        


                        Как-то так.
                        0
                        При большой аудитории получим нагрузку бОльшую, чем при гифке, которая один раз закешировалась и все. А тут постоянно надо будет анимацию обрабатывать. В чем преимущество перед гифкой?
                          0
                          Мне кажется основным преимуществом является возможность стилизации одного элемента под разные части сайта/приложения — чуть больше / чуть меньше, где-то немного другой фон и т.п. Лично мне так проще, чем постоянно переделывать гифы.
                          С другой стороны я не расчитываю, что веб-разработчики резко забросят гифы и кинутся использовать этот плагин/технологию. Мне просто было интересно его написать, javascript для меня хобби.
                            +1
                            При большой аудитории получим нагрузку бОльшую, чем при гифке, которая один раз закешировалась и все. А тут постоянно надо будет анимацию обрабатывать. В чем преимущество перед гифкой?

                            Глупость какая-то. При большой аудитории будет нагрузка ровно такая же, как от одной гифки — дать скачать JS-код. Он ведь не на сервере обрабатывается, ей богу)

                            А вот если надо 20 разных гифок, то выгоднее — один код + 20 настроек, чем 20 гифок.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое