Далеко не в паре, плюс зачем делать велосипеды, если они уже есть.
Да и jquery используется в довольно таки часто, потому скорее всего он уже будет в том проекте, куда будет впихиваться abyz (если будет ;-) )

>> В скрипте много недоделок, те же таблице
например?
Про «таблицу» я ответил на другой пост.

>> можно снизить нагрузку, если не пытаться плавно прокручивать все элементы
Тогда анимация получается «резкой» и начинает раздражать. Тогда смысла в этой утилите вообще нет. Хорошо увеличивается производительность путем уменьшения кол-ва анимированных объектов в конкретный момент. Однако это тоже ведет к через чур резкой анимации и дерганью, что опять таки начинает раздражать.

Изначально так и было.

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

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

Конечно, нагрузка повышается в момент анимации, но именно в момент анимации :) В не её браузер ведет себя нормально.

>> Но городить такое «мясо» и засовывать в него картинки контента считаю неразумным.
В примере было показано как можно «все» картинки сунуть в спрайты. Разработчик же сам определяет какие именно изображения необходимо засовывать в спрайт. По большому счету это могут быть картинки «скругление форм», «повторяющийся фон», «любые другие _декоративные_ элементы». Например, тот же логотип сайта, я бы не засовывал (и не засовываю) в спрайт.

Засовывать ли картинки «контента» — это тоже определяет разработчик. Например вазмем страницу продукции мобильного телефона. На ней представлено фото телефона и 3-6 маааахеньких изображения preview-данного телефона. Если еще само изображение телефона можно грузить отдельно, то смысл разделять preview? их можно объединит, а уже каждое fullsize-изображение отдавать отдельно. При этом формировать css-спрайт для preview-картинок можно на лету — объединение изображений произойдет 1 раз и будет дооооолгим только для первого посетителя страницы, а остальным же будет изображение отдаваться из кэша. (ps: для этого есть user-функция — qpimg_user_get_map() для генерации структура карты на лету). Либо можно реализовать свой доп-модуль по генерации спрайтов при изменении изображений контента в админке сайта Примером работы склейки на лету можно посмотреть тут www.nomoc.com (preview изображения как раз и генеряться online)

>> Проводились ли тесты.
да :)

>> Сколько времени сожрет склейка склейка
скажу просто — «много», до нескольких секунд. Зависит от кол-ва изображений, их объема, нагрузки сервера, и т.д. Тем более, как уже писалось ранее, склейка может идти именно в процессе dev-разработки. Т.е. релиз-сайт уже будет хранить склеенные изображения и они будут отдаваться из кэша. В итоге будто сайт содержит не 15-30 картинок на страницу, а всего 3-5.

>>… не дешевле ли будет отдать множество изображений
как раз смысл уйти от этого.

А сравнительная таблица есть тут code.google.com/p/qpimg/wiki/PageLoadTime — «Зависимость времени загрузки страницы от кол-ва изображений на ней». Имхо, разница очень даже существенная.

Еще один момент, зачем нужен qpimg. Выше «pepelsbey» написал что qpimg можно юзать как «финальный тюнинг». Однако qpimg позволяет генерить css спрайты на лету именно в процессе разработки. Т.е. qpimg посути должен облегчить процесс разработки сайта. Также вставка этих спрайтов требует некоего пересмотра кода шаблонов (например, вставка пустых ссылок в src-атрибут изображений и вставка qpimg-генерируемых class-значений для этих же изображений). А пересмотр кода «перед запуском» проекта может быть довольно таки не-быстро-делательной работой :) Посяму лучше qpimg использовать в проекте изначально. Плюс в дальнейшей доработке проекта модификация спрайта будет очень простой.

вообще я сам в шоке, что же это за название такое :D

мона просто «кьюпимг» или «квипимг» (откуда «В»? а ведь в «qip» тоже быквы «В» нету, а многие читаю как «квип»). да и чего расслабляться — тренеруемся, тренеруемся… ;-) особенно на "… МГ"

хотя «КьюПиАйЭмДжи» тоже ничего так

Если это «финальный тюнинг», то в qpimg нет смысла :)

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

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

я с symfony не работал, потому писать плагинку пока не буду :)

Подход интересен, но имеет некоторые минусы:

* базовый минус — невозможность тонкой настройки свойств каждого объекта карты. Например, большое кол-во объектов будет назначаться для определенных css-селекторов документа, по типу: для «ul.list1 li», для «ul.list2 li», для «ul.backlist li.active». При определении папки — это теряется либо нужно «еще как-то хитро изощряться» чтобы указывать их;

* именования css-селекторов будет явно подвязано к имени файла, что не всегда удобно. Например, при изменении имени файла измениться и css-селектор объекта, соответвенно нужно будет менять его по всем шаблонам. Плюс нужно будет обрабатывать под папки, а это может привести к часным случаям «совпадения» имен css-селекторов.

* каждая папка создает одну карту с определенным набором изображений (объектов). Получается что нельзя указать выборочные изображения из других папок. А это может быть полезно, если генерируются несколько карт в которых некоторые элементы должны быть вставлены из одного изображения;

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

Да и, например, возмем minify. Проект не мало известен и юзабелен, но всё же каждый файл указывается в массиве.

Хотя в целом идея интересна. Можно будет подумать и записать в ToDo ;-)

Если при отдачи данных в заголовке указано значение «Expires», тогда «Ctrl+F5» не поможет. Данные всё равно будут использоваться из кэша до момента указанного в «Expires».

Если при отдачи данных в загаловке указано значение:

Если спрайты будут генерироваться/перегенерироваться при front-работе сайта, тогда да — «серверу смерть» (хотя при определенных условиях и этот подход имеет право на жизнь).

При разработке же сайта, думаю, сервер может и поднапрячься :)

долго думая, всё таки исправил на «qpimg позволит уменьшить общее время загрузки вашего сайта, ...», потому как «увеличить скорость» (т.е. пропуской канал) qpimg никак не может :(

спасибо за коммент. да — это опечатка. исправил.