Pull to refresh
211
0
Сергей Чикуёнок @chikuyonok

Фронт-энд разработчик

Send message
А вот для рисованой мультяшной картинки размеров 400х600 в 51 получится слишком много артефактов.

Я не предлагаю всё сохранять в JPEG с качеством 51 в фотошопе, я за то, чтобы дизайнер/разработчик включал мозг и для каждой картинки выбирал оптимальный графический формат и оптимальное соотношение размер/качество.

В моём комментарии речь идёт о том, что рекомендуемое топикстартером минимальное значение качества JPEG’а 80 является слишком большим (если речь идёт о фотошопе). Потому что большинство фотографий — а именно для них в первую очередь предназначен формат JPEG — выглядят вполне неплохо при гораздо меньших значениях этого параметра.
Конечно же, всё зависит от конкретного изображения, и где-то даже больше 90 нужно выставить, чтобы смотрелось прилично, а где-то хватит 60-и. Просто надо делать разумный выбор для каждой картинки, а не сохранять всё с одним значением параметра «Качество».
Если мы говорим о вебе, то качество большинства проектов определяется не тем, что хочет дизайнер/кодер, а что в итоге получает конечный пользователь. JPEG с качеством 90 априори будет весить больше, чем, например, с качеством 60, а найти визуальные отличия сможет далеко не каждый (предполагаю, что это сможет сделать только автор изображения, потому что пользователям не показывают макеты в фотошопе).
«Разумное JPEG-качество при экспорте»

По-умолчанию поставь качество не менее 80-ти.


Рискну предположить, что эта цифра взята явно не из фотошопа, а откуда-то вроде Adobe Fireworks. Потому что таком значении картинка будет весить неоправданно много. А всё потому, что спецификация JPEG не определяет какой-либо линейной зависимости шкалы «Качество» и итогового изображения. Поэтому у каждого редактора «своя» шкала качества и в зависимости от значения включаются разные алгоритмы оптимизации.

Для фотошопа оптимальным значением является 51 (если ниже, то включается color downsampling), а значения 60—65 хватит «за глаза» в большинстве случаев.

www.artlebedev.ru/tools/technogrette/img/jpeg-3/
При сохранении через Save As… фотошоп оп умолчанию записывает кучу служебной информации вроде превью картинки, информации о гайдах и т.д. что отрицательно сказывается на объёме файла.
От того, что вы напишете сайт в одну строчку, вы не станете быстрее. Да, нажатий на клавиатуру сделаете меньше, но потратите больше времени на то, чтобы сначала продумать всю структуру в голове, мысленно «схлопнуть» её в аббревиатуру, запомнить её целиком, а после разворачивания ещё дважды проверить, соответствует ли результат вашим ожиданиям.

Гораздо эффективнее писать и разворачивать короткие аббревиатуры в нужных местах.
Всё встроено в сам Zen Coding. От автора плагина, по сути, требуется только реализовать интерфейс взаимодействия с редактором.

Посмотреть, как работает оригинальный Zen Coding, можно на тестовой странице: zen-coding.ru/codemirror/
Для VS неписан неофициальный плагин (может даже неофициальная реализация, где-то видел такую), поэтому, к сожалению, ничем не могу помочь.
В каком редакторе так происходит?
Да, действительно, почему-то проглядел это.
PS: о багах лучше писать в Issues.
Спасибо :)
Насчёт своего редактора — особо не задумывался, потому что хороших редакторов полно и заново изобретать велосипед нет желания.

Но есть планы и большое желание скрестить Zen Coding и Content Assist for <textarea> и сделать удобный редактор для CMS с code complete для обычных текстовых полей: без подсветки, но зато очень быстрый. А подсветку при желании можно сделать на любом из существующих решений (CodeMirror, Bespin/Skywriter).
Ещё нет, но, наверно, стоит написать им. Я пока хочу пару месяцев отдохнуть от ZC (этот релиз активно делался последние полгода), заняться другими проектами, поэтому в данной ситуации я бы с радостью выступил в качестве консультанта, а не автора плагина.
В PhpStorm/IDEA полностью своя реализация Zen Coding, так что ждать возможно придётся долго. Можно попробовать скооперироваться с ребятами из JetBrains и сделать плагин на основе версии для Eclipse.
Сам плагин для Vim я не могу вставить в официальный репозиторий, потому что там полностью своя реализация ядра Zen Coding (но ссылка на плагин есть на главной странице проекта), поэтому некоторые вещи там либо не работают, либо совсем не так (по словам очевидцев). Я всё жду, когда кто-нибудь возьмёт оригинальный ZC и по документации напишет нормальный плагин (я, к сожалению, с Vim совсем не знаком и не смогу сделать его оптимально).

По поводу SciTE: могу добавить вас коммитером в проект, будете поддерживать аббревиатуры в актуальном состоянии
В DW на самом деле чуть устаревшая версия: автор плагина раньше времени накатил апдейт движка, там может кое-что не работать/глючить.
не, это я торможу :) Забыл про контекст
c[a='lineTo'](150,150);c[a](150,200);c[a](150,250);c[a](250,350);c[a](450,350);

l=c.lineTo;l(150,150);l(150,200);l(150,250);l(250,350);l(450,350);
Может, тут найдёте что-нибудь интересное: ritconf.ru/2010/abstracts/438.html
Я недавно для себя делал скрипт, который делает ключевые кадры для CSS3 анимаций на основе функций Роберта Пеннера, может, пригодится кому: media.chikuyonok.ru/animator/
При выборе клиентом такового способа оплаты ИМ отправляет, говоря простыми словами, его на сайт процессинговой компании, передавая туда сам лишь по большому счету номер заказа и сумму, которую нужно списать с клиента.


Сами пишете о том, в чём не разбираетесь. Так работают, например, Cyberplat и Chronopay: пользователя перебрасывают на сайт процессинга, где он вводит данные и, соответственно, совершает платёж. Это самый простой и ненапряжный способ подключения оплаты пластиком на сайте.

А можно напрямую подключаться к процессинговым центрам (мы например, подключены к АльфаБанку), тогда все транзакции проходят через специальный серверный API. И как раз в этом случае реквизиты карты вводятся на сайте магазина, а не процессингово центра.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Date of birth
Registered
Activity