Хабр - извращенная среда. К примеру, личный блог - последнее по рейтингу место, где может существовать топик. Хуже только nowhere, /dev/null. Если запинали в личном блоге - отползай, скрой и забудь.
Далее, топики-вопроcы здесь таки не приветствуются. Не форум. Хотите спросить "А где в инете такой-то сервис" - действуйте так: сначала гугл, потом в личном блоге или в Идеях для стартапов описываете в форме предлагаемой к реализации идеи то, что ищете. первый десяток комментов содержит все требуемые ссылки на имеющиеся реализации (sic, проверено).
А что, простите, ему прикажете делать? Сказать "Ааа, ну на хер эти лишние ховеры, обойдется юзер и без них. Не буду их обсчитывать. ДжаваСкрипт, забей на это!".
Дело-то как идет: юзер делает десяток ховеров, браузер обрабатывает каждое событие, обработчик события вызывает animate для объекта. jQuery свои анимации ставит в очередь, одна кончилась - берет следующую и делает ее. Поскольку время анимаций существенно выше времени, необходимого на mouseout и новый mouseover, мы и видим эту задержку. В итоге и браузер не виноват (честно отрабатывает каждое элементарное событие), и jQuery ведет себя как полагается (очередь специально для нужд сложных анимаций писалась, чтобы не заворачивать всё в десяток closures по принципу матрешки). Чтобы «такое поведение исправлять», на мой взягляд, надо вставить перед каждым animate() еще и stop(), ну то есть
C одной стороны, видно что художник давно уже не брал в руки шашек ручку, с другой стороны, сам факт существования рисунка доказывает, что автор картины еще помнил на тот момент принципы обращения с невиртуальным инструментом :)
СпринтНет наверное. Я ими тоже весьма доволен, только в важные для меня последние числа месяца они часто бывают в дауне. Зато когда с ними такое, тачскрин ваще тупо не реагирует на нажатия - сразу ясно, что что-то не так.
Я такой специально для поездки на Грушу взял как-то. А то батарейки для обычных фонарей на третий день искать в облом как-то. Ничего, выручил. В палатке не почитаешь, кэшно, при нем, но до лагеря своего после пьянки у соседей дойти помогает, ну и это... в кустах не заблудишься. Чтобы он случаем никуда не упал, нацепил его на шнурок (там же дырка на заду у него есть) - и вся недолга. Никаких эксцессов. Ксти, здоровый такой брать необязательно, есть и поменьше вариант.
Про размер - это да, в смысле что резины не будет. В крайнем случае нарисуют два, ну три макета, и то не всегда помогает. Выполнял я тут тестовое от САЛ - и макетов две штуки, и помечено стрелками и палками, что тянуть и как. Но вот как это сверстать, чтоб работало - «зогатко» :). То есть диз старательно думал о «резине», но думал в Фотошопе, в итоге макет головоломный.
Поток - это я имею в виду любое автоматическое расположение последовательных объектов. В PS наличествует только в текстовом блоке (в пределах одного). Очевидно, основной прокол тут - в парадигдме слоев («кусков прозрачного стекла в размер документа»). Тот же Corel DRAW позволяет как минимум обтекание текстом объектов (объектов!), для Wordа понятие потока вообще родное, картинку например можно привязать к строчке текста, тут почти полный аналог HTML-ного потока (последний чуть проще). Отсутствие потока в PS заставляет дизайнера мыслить в простой двумерной системе координат, воспринимать объекты как области пикселов на разных слоях, а не блоки с зависимостями размеров, усложняет производство той же «резины», и т.д. То есть в общем смысле не позволяет дизу и верстальщику говорить на одном языке.
Отсутсвие автоматики положения блоков в PS (того, что я подразумеваю под потоком) порождает такие частые ошибки и помарки дизайнеров в макетах, как:
- сдвиг отдельных блоков на один-два пиксела (не замечают из-за гайдлайнов, которые по логике должны бы помогать в этой ситуации, этот баг всегда отлавливают только верстальщики)
- непостоянный вертикальный ритм, например, расстояния между текстовыми элементами, расстояния от края блоков до текста в них (на практике, на красивых, впечатляющих макетах ни разу не встретилось решение, помогающее верстальщику реализовать макет с пиксельной точностью. Расстояние от верха «плашки» до заголовка в ней в 99% случаев не совпадет с макетом).
- непостоянные расстояния в горизонтальных распределениях элементов (типа главного меню, которое часто бывает графическим).
Всё указанное вполне поддается ручному контролю, но это ж какая должна быть дотошность! При этом сроки, сами понимаете, не терпят. В итоге верстальщик, ругаясь под нос, реализует половину макета на графике, вырезая гифы с огромными пустыми областями, а относительно другой половины трясется, чтобы менеджеры не стали делать сравнение на точность.
Сейчас, вроде, научились более-менее книги делать из вторсырья. Если конечно коллекционные форматы в расссмотрение не брать (но тут уж какой epaper). Аж даже надоедает уже. Купишь огромный том, возьмешь его в руки - мобильник, ей-богу, тяжелее, чем этот талмуд. Бумага не всегда беленая, красочка бледненькая, так что вред относительный, тогда как от производста устройств - вполне понятный, реальный.
Если учесть, что пишут это скорее программисты, всё становится понятно. Ну не работает PS через командную строку :) Меня самого плющит на тему автоматизации собственной деятельности через Photoshop Scripting :)
Если хобби превращать в работу - хобби надоест. Поэтому тут весь вопрос в степени вовлеченности редакторов, в их обязанности писать энное количество статей. Идея техноблоггинга обязывает, вообще-то, писать часто (на TechCrunch итп взглянуть страншно - я только через твиттер по десятку уведомлений получаю, да в читалке до полусотни постов в день - их авторства).
Далее, топики-вопроcы здесь таки не приветствуются. Не форум. Хотите спросить "А где в инете такой-то сервис" - действуйте так: сначала гугл, потом в личном блоге или в Идеях для стартапов описываете в форме предлагаемой к реализации идеи то, что ищете. первый десяток комментов содержит все требуемые ссылки на имеющиеся реализации (sic, проверено).
Дело-то как идет: юзер делает десяток ховеров, браузер обрабатывает каждое событие, обработчик события вызывает animate для объекта. jQuery свои анимации ставит в очередь, одна кончилась - берет следующую и делает ее. Поскольку время анимаций существенно выше времени, необходимого на mouseout и новый mouseover, мы и видим эту задержку. В итоге и браузер не виноват (честно отрабатывает каждое элементарное событие), и jQuery ведет себя как полагается (очередь специально для нужд сложных анимаций писалась, чтобы не заворачивать всё в десяток closures по принципу матрешки). Чтобы «такое поведение исправлять», на мой взягляд, надо вставить перед каждым animate() еще и stop(), ну то есть
$(this).parent().stop().animate({backgroundPosition…
шашекручку, с другой стороны, сам факт существования рисунка доказывает, что автор картины еще помнил на тот момент принципы обращения с невиртуальным инструментом :)Только всё равно существует миллион случаев, когда внешний вид итоговой надписи в HTML не совпадет с макетом.
Поток - это я имею в виду любое автоматическое расположение последовательных объектов. В PS наличествует только в текстовом блоке (в пределах одного). Очевидно, основной прокол тут - в парадигдме слоев («кусков прозрачного стекла в размер документа»). Тот же Corel DRAW позволяет как минимум обтекание текстом объектов (объектов!), для Wordа понятие потока вообще родное, картинку например можно привязать к строчке текста, тут почти полный аналог HTML-ного потока (последний чуть проще). Отсутствие потока в PS заставляет дизайнера мыслить в простой двумерной системе координат, воспринимать объекты как области пикселов на разных слоях, а не блоки с зависимостями размеров, усложняет производство той же «резины», и т.д. То есть в общем смысле не позволяет дизу и верстальщику говорить на одном языке.
Отсутсвие автоматики положения блоков в PS (того, что я подразумеваю под потоком) порождает такие частые ошибки и помарки дизайнеров в макетах, как:
- сдвиг отдельных блоков на один-два пиксела (не замечают из-за гайдлайнов, которые по логике должны бы помогать в этой ситуации, этот баг всегда отлавливают только верстальщики)
- непостоянный вертикальный ритм, например, расстояния между текстовыми элементами, расстояния от края блоков до текста в них (на практике, на красивых, впечатляющих макетах ни разу не встретилось решение, помогающее верстальщику реализовать макет с пиксельной точностью. Расстояние от верха «плашки» до заголовка в ней в 99% случаев не совпадет с макетом).
- непостоянные расстояния в горизонтальных распределениях элементов (типа главного меню, которое часто бывает графическим).
Всё указанное вполне поддается ручному контролю, но это ж какая должна быть дотошность! При этом сроки, сами понимаете, не терпят. В итоге верстальщик, ругаясь под нос, реализует половину макета на графике, вырезая гифы с огромными пустыми областями, а относительно другой половины трясется, чтобы менеджеры не стали делать сравнение на точность.