Comments 32
Не совсем по теме, однако grunt + grunt-spritesmith = автоматическая сборка спрайтов из отдельных файлов, с формированием less. Создаём 2 папки: одну для обычных спрайтов, вторую для увеличенных, добавляем два задания в grunt для формирования двух спрайтов — profit.
Разобраться с grunt для выполнения подобных задач — дело пары часов, которые потом окупятся сторицей.
Разобраться с grunt для выполнения подобных задач — дело пары часов, которые потом окупятся сторицей.
А вот скажите, в чем смысл css спрайтов, когда есть base64? В чем преимущество? И кстати да, ставить обработчиком grunt, который соберет или base64 из файлов и проставит в нужные места заместо имен — это действительно удобно.
У той или иной задачи есть множество реализаций. В данной статье я не описываю преимущество данного способа над base64.
А по вашему вопросу — css спрайты наиболее известны, популярны. А в вашем решении необходимо использовать дополнительный обработчик, скрипты. Что, впрочем, соразмерно с использованием less.
А по вашему вопросу — css спрайты наиболее известны, популярны. А в вашем решении необходимо использовать дополнительный обработчик, скрипты. Что, впрочем, соразмерно с использованием less.
Вот вам один из доводов
> Использовать css3 в данном методе мы будем только для дисплеев с ppi, выше стандартных 72. Подобные дисплеи появились сравнительно недавно, и никакие IE7.0 – IE8.0 там стоять не будут.
В Windows Phone 7 как раз IE 7.0 – IE8.0 и большой ppi.
В Windows Phone 7 как раз IE 7.0 – IE8.0 и большой ppi.
Полагаю, вы имеете ввиду самую-самую первую. Я имею ввиду 7.5, так как она, по словам википедии:
В системе обновился браузер Internet Explorer Mobile до версии 9, который теперь поддерживает HTML5, Canvas, аппаратное ускорение. Появилась возможность использовать фронтальную камеру.
UFO just landed and posted this here
Да какая разница. Автор написал, что на устройствах с ppi больше 72 не может стоять IE7. Это не так.
Что ж, поделитесь ссылкой, что Windows Phone 7, как вы говорите, с IE8, стоит хотя бы на тысячной доле процента от всех мобильных пользователей. Если такого нет, то можно вполне сказать, так, как я написал в статье.
При чем тут доля. Может стоять же? Причем я не прикапываюсь к словам типа «ага, у меня монитор 92 ppi, на нем ие8 в виртуалке!», я о реальных устройствах с ppi за 200.
Ну, значит у них будет размытые иконки. Доля очень здесь причем. Если для того, чтобы сайт работал на экзотических девайсах, нужно вкладывать много времени на разработку, то на эту долю забивают. И доля пользователей с ppi 200+ и IE 7-8, крайне мала.
А вообще, как я понял, вам просто хочется придраться к какой-то мелочи. Можно было написать в ЛС. А в комментариях писать все же по теме, а не придираться к выражениям.
А вообще, как я понял, вам просто хочется придраться к какой-то мелочи. Можно было написать в ЛС. А в комментариях писать все же по теме, а не придираться к выражениям.
Руки оторвать тем, кто ретину сделали.
Почему блин в андроиде сделали нормальные девайсонезависимые пиксели и совместимо все, а из-за этих дизайнеров с ретиновскими картинками приходится извращаться везде — начиная от того что теперь нужно две картинки, заканчивая тем что есть всякие админки и на том-же html браузеры такого изврата особо не понимают, а учитывая любовь дизайнеров верстать по пикселям (ага — добро пожаловать в 90-е) получается вообще полный…
Опять получилась фигня когда доверили дизайнерам то что должны были делать технари.
Почему блин в андроиде сделали нормальные девайсонезависимые пиксели и совместимо все, а из-за этих дизайнеров с ретиновскими картинками приходится извращаться везде — начиная от того что теперь нужно две картинки, заканчивая тем что есть всякие админки и на том-же html браузеры такого изврата особо не понимают, а учитывая любовь дизайнеров верстать по пикселям (ага — добро пожаловать в 90-е) получается вообще полный…
Опять получилась фигня когда доверили дизайнерам то что должны были делать технари.
Ретина — это лишь маркетинговое словечко. Говоришь «ретина», и окружающие так «оооооооо!». В реальном мире — ретина не такая уж и крутая, есть, например Meizu MX3, HTC One и много всяких других устройств, где плотность пикселей может быть в полтора и более раз выше, чем у самого крутого девайса от яблочка.
90-е тут не при чём, время идёт, если заглядывать в прошлое веб разработки, то лет 10 назад стандартом было разрешение 800х600 (если даже не 640х480, хотя врятли), лет 5 назад, де-факто, было разрешение 1024х760 и так далее. Сайты разрабатывались с учётом подобных мониторов и размер экрана был практически пропорционален количеству пикселей. Но вдруг технология шагнула вперёд и подобные «мозги» компьютера начали без проблем всовывать в сотовые телефоны, при этом если на Desktop компьютерах на размер экрана пофигу (даже наоборот, чем больше — тем круче), то в планшетных ПК, смартфонах и прочих «приблудах» так не разгуляешься, экран должен быть фиксированного размера +\- (я умолчу о любителях лопат), по-этому следующим шагом было увеличение плотности пикселей на экранах подобных устройств, и если, повторюсь, в эпоху настольных ПК разрешение экранов было примерно пропорционально размеру самого экрана, то на устройстве с разрешением 1920х1080 сайт, заточенный под разрешение 800+, выглядел бы, прямо скажем — не очень (если нет конечно под рукой микроскопа).
Я предполагаю, что всё рассказанное мной — довольно очевидно и дизайнеры тут совсем не при чём (ну или только частично). В таком случае можно хаять дизайнеров на то, что приходится использовать много цветов, вместо палитры из 8 битов =)
90-е тут не при чём, время идёт, если заглядывать в прошлое веб разработки, то лет 10 назад стандартом было разрешение 800х600 (если даже не 640х480, хотя врятли), лет 5 назад, де-факто, было разрешение 1024х760 и так далее. Сайты разрабатывались с учётом подобных мониторов и размер экрана был практически пропорционален количеству пикселей. Но вдруг технология шагнула вперёд и подобные «мозги» компьютера начали без проблем всовывать в сотовые телефоны, при этом если на Desktop компьютерах на размер экрана пофигу (даже наоборот, чем больше — тем круче), то в планшетных ПК, смартфонах и прочих «приблудах» так не разгуляешься, экран должен быть фиксированного размера +\- (я умолчу о любителях лопат), по-этому следующим шагом было увеличение плотности пикселей на экранах подобных устройств, и если, повторюсь, в эпоху настольных ПК разрешение экранов было примерно пропорционально размеру самого экрана, то на устройстве с разрешением 1920х1080 сайт, заточенный под разрешение 800+, выглядел бы, прямо скажем — не очень (если нет конечно под рукой микроскопа).
Я предполагаю, что всё рассказанное мной — довольно очевидно и дизайнеры тут совсем не при чём (ну или только частично). В таком случае можно хаять дизайнеров на то, что приходится использовать много цветов, вместо палитры из 8 битов =)
Дополню (не успел во время отредактировать):
Попробуйте запустить игру, заточенную под 640х480 на современном мониторе — поймёте почему затачивать решения под пиксели, а не размазывать их — всё же лучше. Хотя в глубине души мне тоже хочется одну, большую, красную кнопку — «сделать всё круто», но увы.
Попробуйте запустить игру, заточенную под 640х480 на современном мониторе — поймёте почему затачивать решения под пиксели, а не размазывать их — всё же лучше. Хотя в глубине души мне тоже хочется одну, большую, красную кнопку — «сделать всё круто», но увы.
Я прекрасно знаю что «ретина» это результат деятельности маркетологов огрызка.
Я не говорю о том, что повышать плотность и разрешение плохо.
Я говорю о том как через большую и круглую это реализовали в эппле «дизайнеры», потому что по тому что они выпускают не похоже что там вообще есть технари.
Андроид поддерживает девайсо-независимые пиксели, три варианта плотности точек, кучу различных разрешений экранов, динамическое размещение компонентов по лайаутам, и делать там дизайн вообще отлично.
Тут же блин второе разрешение экрана ввести не могут — это же надо додуматься просто своим идиотизмом поломать полностью обратную совместимость даже в такой простой задаче.
И про игру — извините, но на современном мониторе она просто будет размазана, а не просто расползется нафиг из-за того, что половину размерностей мы тупо увеличили в два раза, а половину забыли. Просто яблочники наверное не в курсе, что помимо их отстоя есть и нормальные системы/планшеты/телефоны и компы.
Я не говорю о том, что повышать плотность и разрешение плохо.
Я говорю о том как через большую и круглую это реализовали в эппле «дизайнеры», потому что по тому что они выпускают не похоже что там вообще есть технари.
Андроид поддерживает девайсо-независимые пиксели, три варианта плотности точек, кучу различных разрешений экранов, динамическое размещение компонентов по лайаутам, и делать там дизайн вообще отлично.
Тут же блин второе разрешение экрана ввести не могут — это же надо додуматься просто своим идиотизмом поломать полностью обратную совместимость даже в такой простой задаче.
И про игру — извините, но на современном мониторе она просто будет размазана, а не просто расползется нафиг из-за того, что половину размерностей мы тупо увеличили в два раза, а половину забыли. Просто яблочники наверное не в курсе, что помимо их отстоя есть и нормальные системы/планшеты/телефоны и компы.
Не вижу ни одной проблемы в верстке под iOs по сравнению с Android.
И да, у вас баттхерт.
И да, у вас баттхерт.
> Тут же блин второе разрешение экрана ввести не могут —
> это же надо додуматься просто своим идиотизмом поломать
> полностью обратную совместимость даже в такой простой задаче.
Почему не могут ввести? Ввели. Что поломали?
> это же надо додуматься просто своим идиотизмом поломать
> полностью обратную совместимость даже в такой простой задаче.
Почему не могут ввести? Ввели. Что поломали?
У вас все в голове смешалось.
Мне приятно смотреть на экран с высоким ppi. А контент должен подтягиваться. Вас же не смущает смотреть SD-видео? Вы понимаете, что HD намного комфортнее и лучше.
А всякие варианты про «две картинки» — лишь из-за того, чтобы не грузить большие объемы информации там, где она просто не нужна. Хотя в посте я отметил в самом конце о разумности метода, когда мы сразу подгружаем качественные иконки.
Мне приятно смотреть на экран с высоким ppi. А контент должен подтягиваться. Вас же не смущает смотреть SD-видео? Вы понимаете, что HD намного комфортнее и лучше.
А всякие варианты про «две картинки» — лишь из-за того, чтобы не грузить большие объемы информации там, где она просто не нужна. Хотя в посте я отметил в самом конце о разумности метода, когда мы сразу подгружаем качественные иконки.
Проголосовал за все 4 варианта.
Спасибо.
Спасибо.
Тем, кто всё ещё не определился с препроцессором, рекомендую не смотреть в сторону Less, а обратить внимание на Stylus+Nib (Node.js) и Sass+Compass (Ruby). Особенно в вопросах генерации спрайтов.
Ну, хочу немного возразить. Less действительно проще и ближе к css. На него легче пересесть, а использование базовых возможностей: вложенности селекторов, миксинов и переменных, сразу почти в два раза ускоряют верстку проектов.
Ни разу не ближе, ни разу не легче, чем на Sass или Stylus, а вот отсутствие функций, if/else, циклов, доступа к файловой системе и расширений, ощутимо уменьшает возможности по ускорению вёрстки. Однажды в них упрётся каждый разработчик и непременно проклянёт «тот день, когда сел за баранку этого пылесоса».
А вот тут я не соглашусь. Less действительно проще и ближе к CSS, правда возможностей из коробки — Вы правы, меньше, чем в Sass (Scss) и Stylus.
Судя по этому комментарию, вы или теоретизируете или же просто троллите меня.
Любой фронтенд-разработчик, который использовал в реальных проектах разные препроцессоры, знает, что хоть с коробкой, хоть без коробки less проигрывает по всем фронтам, ещё и отличаясь от конкурентов в худшую сторону в плане читабельности. И да, я говорю не про HelloWorld, а про реальные, сложные стили с кучей условий.
Любой фронтенд-разработчик, который использовал в реальных проектах разные препроцессоры, знает, что хоть с коробкой, хоть без коробки less проигрывает по всем фронтам, ещё и отличаясь от конкурентов в худшую сторону в плане читабельности. И да, я говорю не про HelloWorld, а про реальные, сложные стили с кучей условий.
Stylus есть и на руби, а Scss+Compass и Stylus, и Less есть и на PHP =)
Проблема с по́ртами Sass в том, что они не подсасывают config.rb, в который очень удобно добавлять различные плюшки (мини-расширения), написанные на руби.
Зато могут подсосать (ух какое ядрёное словечко) config.php, config.js, config.coffee, config.*подставить_любимое_расширение*. Плюшки точно так же без проблем пишутся (могу отвечать, правда, только за PHP порт).
Дело в том, что в интернетах ну оооочень много сниппетов для конфиг-файлов Sass и Compass, написанных на руби.
В случае порта нужно либо переписывать сниппет на выбранный язык, либо изначально писать свой и вообще не использовать великий и могучий копипаст. И это печально.
Плюс, не знаю, как там на PHP, но на Node.js Compass до сих пор не реализован в полном объёме. Т.е. опять же, в случае порта, вы рискуете наткнуться на баг, которого нет.
В случае порта нужно либо переписывать сниппет на выбранный язык, либо изначально писать свой и вообще не использовать великий и могучий копипаст. И это печально.
Плюс, не знаю, как там на PHP, но на Node.js Compass до сих пор не реализован в полном объёме. Т.е. опять же, в случае порта, вы рискуете наткнуться на баг, которого нет.
Тема относительно старая, но все таки спрошу. Зачем выносить 1пх в переменную?
Я бы понял, если рассматривать конкретный пример, если бы вынесли в переменную число 32пх, то есть размер одной иконки и в дальнейшем бы для каждой иконки делали смещение под её позицию, то есть
Иконка 1: бгпозишн: size*2 0;
Иконка 2: бгпозишн: size*3 0;
И так далее…
Я бы понял, если рассматривать конкретный пример, если бы вынесли в переменную число 32пх, то есть размер одной иконки и в дальнейшем бы для каждой иконки делали смещение под её позицию, то есть
Иконка 1: бгпозишн: size*2 0;
Иконка 2: бгпозишн: size*3 0;
И так далее…
Для однотипно-элементных спрайтов – да, хорошо. А что если элементы спрайта неодинаковы?
Sign up to leave a comment.
Делаем css-спрайты отзывчивее на retina-дисплеях и не только [less]