Это перевод статьи, написанной Jon Hobbs-Smith. Я счел ее довольно интересной и решил выложить в своем блоге, а также поделиться им с хабрапользователями, также как и я заинтересованными в библиотеке jQuery. Перед тем как начать хочу отметить, что написана она (как и переведена) далеко не экспертом в jQuery, поэтому если вы найдете в ней ошибку, пожалуйста, сообщите. Итак, начнем.

Пользуетесь FCKEditor и хотите чтоб ваш сайт выглядел хорошо с точки зрения типографики, но не хочется каждый раз куда-то лезть? тогда это для вас, Plugin для FCKEditor который позволяет оттипографить прямо в редакторе.

За основу моего был взят плагин http://click1.ru/book/tipograf-plagin-k-redaktoru-fck, после того как он у меня сразу не захотел работать пришлось допилить его немного ручками, в результате чего получился мой вариант этого плагина.

Представляю вашему вниманию обзор нескольких полезных инструментов для всестороннего тестирования сайтов.

Моя статья на Временно.нет

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

Здесь представлен обзор 38 статей, разбитых на 4 категории по способам реализации.

Вторая версия статьи, расширенная и дополненая.

Большая часть готовилась для моего выступления на «РИТ: Клиентские технологии», куда я, к сожалению, не доехал.

 



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

Первоначально эта памятка писалась мною для внутреннего пользования но, обрастая материалами, выросла в самостоятельную статью. Америку я не открыл, а просто собрал воедино и сформулировал ряд требований, которые должен учитывать дизайнер в процессе проектирования и оформления сайта.

Идея такая: Нас трое и мы в течении целой недели, 24 часа в сутки 7 дней в неделю, т.е. ровно 168 часов, закрывшись в комнате и «выкинув» ключ будем делать стартап.

Краткая предыстория: Сегодня (17.12.08) мы (mimic, m2k и strel) собрались на организационную встречу СтартапПоинт. Рассуждая о том как нужно делать успешные стартапы, в шутку произнесли подобную идею (целую неделю безвылазно делать стартап, можно это даже через вебку в интернет транслировать). После 2х с половиной часов самомотивации приняли решение. Еще через час этот топик уже был написан на 15%.
Кстати, какой именно стартап мы будем реализовывать еще не известно. Но мы же стартаперы, гениальных идей революционных проектов у нас у каждого по несколько, не было только времени на их реализацию. Да-да, все стандартно, жалко было оставить нелюбимую работу, не хотелось ограничивать себя во сне и еде, хотелось хорошо отдохнуть с друзьями и т.д., ну вы меня понимаете?!

Цель: Создание успешного стартапа в лучших традициях начинающих бизнесов в гараже.
Задача: максимально ограничить себя, выйти из «зоны комфорта», чтобы c наибольшей вероятностью достичь поставленной цели.

Речь в статье пойдет о такой, казалось бы изжеваной и изъезженой теме, как валидация веб-документа по одной из DTD-схем, которые в свою очередь определяются с помощью DOCTYPE.

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

В последнее время, многие редакторы и CMS'ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.

Сложность элементов интерфейса увеличивается с каждым новым макетом, что доставляет немало хлопот верстальщикам. Развивающиеся технологии позволяют создавать в WEBе сложные приложения (Google не даст мне соврать), поэтому дизайнеры себя не сдерживают и рисуют всё более навороченные вещи. Как правило, это приводит к большому количеству графики на страницах.

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

Уже не раз сталкиваюсь с подобной проблемой, когда люди приходят и просят помочь в решении проблем распределения нагрузки при внезапном возрастании аудитории их сайтов. Ну и самое трудоемкое в данной проблеме — это самописные CMS-подобные системы, которые иногда приходиться переписывать полностью.

Я не буду вдаваться в подробности распределения нагрузки, а отпишу лишь основные правила при соблюдении которых Ваша CMS будет легко масштабироваться.

О чем это?

Возможно ли узнать более детальную информацию о браузере посетителя кроме строки, содержащейся в $_SERVER[«HTTP_USER_AGENT»]: поддерживает ли яву, апплеты, таблицы стилей и фреймы? А может это вообще гуглобот зашел?

1. Что такое PNG?
2. PNG vs GIF.
3. PNG vs JPEG.
4. Жизнь после Photoshop'а или сжимаем дальше.
5. Adobe Fireworks или PNG-8 с альфа-каналом.
6. Вердикт.

Осторожно, много картинок! Все кликабельны.

Много было про то написано, да не суть…

Озадачился следующей задумкой: перетаскиваемый слой с фиксированным положением на экране, страница скролица — слой остаётся на месте. Как известно данная задумка на ура воплощается в FF, Opera, Google Chrome, но вот IE интеллигентно послал мою задумку в свою мусорную корзинку — при скролинге передвинутый слой сползал вместе со страницей.

Шрифты в Em/% хороши всем — возможностью пользователей IE увеличивать кегль, заботой о пользователях, что предпочитают увеличивать размер шрифта браузера по-умолчанию, чтоб лучше видеть текст, да и просто являются нормой для профессиональных верстальщиков.

Минусы: … их вроде как нет, но!
А что если у пользователя разрешение экрана выставлено не в стандартное 96 dpi, а в 120?
Сайт с увеличенными шрифтами смотрится уже не так красиво, как нарисовал дизайнер — ведь масштабируются только шрифты, а не весь сайт! А разрешение 120dpi становится всё популярней, особенно на ноутбуках! Что же делать? Возвращаться к px?

Нет!