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

Статья целиком: http://habrahabr.ru/post/180473/
Автор: everyonesdesign

Источник: http://habrahabr.ru/post/180615/
Автор: SVGen

Задача

ВОШ — эффект, возникающий при стилизации текста подключаемым шрифтом, не установленным на компьютере пользователя. Проявляется, когда подключаемый шрифт ещё не успел скачаться, и стилизуемый текст отображается следующим шрифтом из значения свойства font-family этого элемента. Такое переключение шрифтов также может повлиять на размеры элемента, если они зависят от размеров текста в нём.
Эффект известен также как FOUT — так его назвал Пол Айриш.

При общих моментах, есть и особенности. Например, в Файрфоксе текст, который нужно будет отрисовать нестандартным шрифтом, в течение 3 секунд не отображается, в Хроме тоже есть подобная задержка. Если шрифт успеет скачаться за это время, текст отобразится сразу нужным шрифтом.

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

Решение

Чтобы устранить ВОШ, я решил указывать шрифт в основном файле стилей при помощи data:uri, чтобы шрифт отображался сразу, вместе со страницей.

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

Шрифты в eot наиболее лёгкие, но поддерживаются только ИЕ.
Шрифты в ttf и svg тяжелы, иногда — конечно, это зависит от шрифта — занимающие в два раза больше места, чем eot и woff. В моей ситуации я выбрал woff, этот формат поддерживается большинством браузеров наших посетителей.
Ещё есть браузеры, которые woff не понимают, поэтому указываются альтернативы для них.

ИЕ версии 8 и старше не понимают шрифты в woff, им нужен eot. В то же время, ИЕ8 не понимает файлы в data:uri тяжелее 32КБ, а более старшие версии не воспринимают совсем никакие, поэтому в отдельном файле стилей для них можно просто указать ссылки на файлы шрифтов. Чтобы эти браузеры не загружали ненужное, подключение шрифта в woff и в других форматах выделено в отдельный файл стилей и отделено условным комментарием.

Также, есть мнение, что под Вин в Хроме svg-шрифты выглядят лучше других, но, мне кажется, это дело вкуса. Шрифт в этом формате лучше других сжимается при помощи gzip, но не поддерживается Файрфоксами и ИЕ.

Таким образом, подгружать шрифты можно при помощи следующего кода:

<!-- подключение файлов стилей -->
<!--[if lte IE 8]>
  <link rel="stylesheet" href="fonts_ie.css" media="all">
<![endif]-->
<!--[if gt IE 8]><!-->
  <link rel="stylesheet" href="fonts.css" media="all">
<!--<![endif]-->
 
<link rel="stylesheet" href="main.css" media="all">

/* fonts_ie.css */
@font-face {
    font-family: 'PT Sans Narrow';
    font-style: italic;
    font-weight: bold;
    src: url('PTS76F_W.eot');
}

/* fonts.css */
@font-face {
    font-family: 'PT Sans Narrow';
    font-style: italic;
    font-weight: bold;
    font-variant: normal;
    src: url('data:application/x-font-woff;base64,d09GRgABAAAA...aCw0AAA==') format('woff'),
         url('PTN77F_W.svg#PTSans-NarrowBold') format('svg'),
         url('PTN77F_W.ttf') format('truetype');
}

/* main.css */
body {
    font-family: 'PT Sans Narrow', 'Arial Narrow', sans-serif;
    font-style: italic;
}

При использовании этого способа ВОШ остаётся только в неподдерживающих woff-шрифты, планомерно теряющих пользователей браузерах, самый распространённый из которых на данный момент — ИЕ8.

На этой странице шрифт подключен традиционно.
Здесь шрифт закодирован.
Эффект заметней на медленном соединении.

Особенности

Стоит осознать, что при использовании такой техники остаются браузеры, которые не понимают шрифты в woff, но которым придётся их загружать. Тут уже играет роль количество посетителей с такими браузерами и продуктивность их посещений. В моей ситуации оказалось, что лучше устранить ВОШ.

Шрифт всё равно будет скачиваться, даже если установлен локально. Это сделано, чтобы предотвратить конфликты между начертаниями; будет скачиваться такое, какое нужно.
Страница не будет отрисовываться, пока файл стилей со шрифтом не скачается.

Также отмечу, что способ не подойдёт для шрифтов с лицензией, не позволяющей загружать их при помощи data:uri.

И, конечно, гарантированное решение всех проблем с подгружаемыми шрифтами — отказаться от их использования. Серьёзно, иногда они ни к чему.

Дополнительная информация

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

Немного об особенностях подключения.

Максим Ильяхов

Редактор Мегаплана

Домашнее чтение

Я рассказал о своем опыте создания рассылки Мегаплана. В книге Дмитрия Кота сказано все остальное. Это чудесная короткая книга без лишней теории и булшита, с правильным отношением к клиенту.

Если хотите узнать больше о рассылке Мегаплана, рассказать о своем бизнесе или прислать ссылку на интересную статью, проект или блог, пишите: maxim@megaplan.ru

Ссылка для подписки:
megaplan.ru/subscribe
(перешлите друзьям)

Хорошего дня и успехов!

Источник: http://us2.campaign-archive2.com/?u=833bf5395122c8de57f99f863&id=b093e2e3cb&e=e621a121a4

I recently redesigned my blog, The Sunday Best. In the process, I think I did something new: I completely avoided the use of px units in my CSS.

http://medium.com/design-ux/66bddb327bb1

I’ve been (badly) making websites since I was 14. In 1996, and indeed for most of the Web’s existence, makers of websites had to be very concerned about the average resolution of users’ screens. I felt safe stretching my sites to just under 800-pixels wide to avoid horizontal scroll bars on monitors in the late ‘90s. By the early ‘00s, it was safe to make websites just under 1024-pixels wide.

In 2013, however, it’s more complicated. Uber users run Thunderbolt displays stretching 2560 pixels. Those same users are also on Macbook Airs with just 1366 pixels. Or on iPhones, with a width of 640 pixels but which answer to media quieries for 320-pixel design.

In 2013, the pixel is nearly meaningless. I got tired of guessing users’ pixel counts. I fully adopted vw and em units in my CSS.

It started when I discovered vw units, and learned that I could define a font size in them. My initial goal was to simply resize the font based on the width of the viewport — and it worked, at least in modern browsers.

body { font-size: 1.8vw; }

I then wanted to see how far I could take the idea. I ended up completely removing px units from my CSS. And I’m very happy with the results.

The final challenge in extricating pixels from my design came from social share buttons. While the rest of my page fitted perfectly to any size screen, share buttons such as Facebook’s Like didn’t resize the same way. In mobile Safari, the button was uselessly tiny. Twitter offers different sizes for the Tweet button, but Facebook surprisingly has no options. In the end, I nixed the standard share buttons and created my own. (They’re not quite as functional as stock buttons, but certainly more usable on mobile, and more attractive.)

The benefits

Responsiveness is built in. Sort of. I still use media queries to adjust the layout for portrait screens and small screens.

Everything is kept to scale. Font size doesn’t adjust independently of the column width — roughly the same character count per line is retained. Dividing lines are sized relative everything else, maintaining the original proportions no matter what.

Users can resize a browser window to any size or aspect ratio and the design will fit — no horizontal scroll bars, no obstructed content. Instead of keeping a rigid browser size, this allows users to move the content anywhere on a desktop.

There’s no unused blank space around the page, no wasted screen.

It’s not easy for most people to do, but users can load multiple sites within a set of adjacent iframes, effectively viewing multiple websites at once. (Assuming other sites are as flexibly designed. Here’s an example — naturally, it works with most responsive designs.)

The drawbacks

Browser zoom controls no longer do anything on my blog — the only way to increase or decrease the size of the text is to resize the browser window.

I haven’t yet established a style for very large browsers, so at high resolution and a full-screen window the design gets a bit silly.

I had to give up stock social share buttons. They’re ugly anyway.

Images are still in pixels, and they get stretched. I don’t use many images in the page design, but do use a lot of photos. I’m pretty happy with how resized photos look in modern browsers. (Vector graphics and more advanced image serving could negate this issue.)

Browser compatibility with vw and vh units is still an issue. They work great in WebKit and Gecko. I looked at my blog in Internet Explorer just once and it seemed usable, though there were certainly some issues. I have the luxury of not having to worry about Internet Explorer.

Most of the Web isn’t built like this, which means some of the ideals behind it don’t really work. Users aren’t accustomed to resizing their browser window to squeeze content to a preferred size. Some users always run full-screen even on large resolutions, which makes my blog look silly (words get huge). And few users are in the habit of loading multiple websites in adjacent iframes — we use tabs instead, which are generally preferable anyway (but don’t have the same options for content consumption).

I think the Web should fully move in this direction. True proportionate sizing seems to me a more authentic way to responsively fit websites to browsers (rather than media queries that simply toggle between set pixel widths). It’s also pretty easy, and requires virtually zero guessing about the user’s browser. And after jumping the initial mental hurdle of designing in vw instead of px, I found it much easier and faster to build.

Два варианта:

http://bolknote.ru/2013/04/19/~3946#22

http://kizu.ru/

В то же самое время основным камнем преткновения многих дизайнеров, работающих с типографикой, остается вопрос эстетики. Сложность заключается в том, что под термином «типографика» мы часто понимаем кастомные шрифты для надписей (и наоборот), что на самом деле неверно. Чтобы убедиться в существовании подобного заблуждения, достаточно просмотреть результаты поисковой выдачи материалов с тегом «typography» на Dribbble.com.

Очарование качественно исполненных кастомных шрифтов – а я могу часами просматривать портфолио с ними! – может существенно изменить наши взгляды на гарнитуры, поскольку типографику и создание декоративных шрифтов объединяют общие визуальные концепции. Однако, в своем стремлении найти Самую Красивую Гарнитуру™ всех времен мы можем далеко уйти от функциональности гарнитур и их преимуществ, таких как универсальность, гибкость и возможность многократного использования.

Более того, часто мы слишком увлекаемся использованием новейших функций OpenText, припудриваем материал милыми сердцу лигатурами, нашпиговываем лишь частично описанными переносами слов на новую строку в CSS, а затем в благоговейном восхищении созерцаем получившийся шедевр, безразличные к тому, что наши усилия не оценит никто, кроме другого такого же типографического гика. Суровые реалии жизни не замедлят воздать нам должное в тот момент, когда нормальные люди попытаются прочесть (и понять) наш шедевр, используя при этом все разнообразие существующих в природе устройств, начиная с ноутбуков с дисплеем Retina, заканчивая мониторами с электронно-лучевой трубкой и разрешением 72 dpi, работающими под Windows XP, а то и вовсе какими-нибудь новомодными мобильными устройствами с функцией измерения давления.

«Хорошая типографика нужна не за тем, чтобы радовать эстетов, а для того, чтобы текст было удобно читать»
– Оливер Райхенштайн

Большинство статей в Сети оптимизированы с целью легкости их восприятия – вам знаком термин «перевернутая пирамида»? В самой природе Интернета заложена быстрота обмена информацией соответствующая сравнительно небольшому объему внимания читателя. Люди посещают сайты и используют приложения потому, что, в первую очередь, ищут информацию, в большинстве случаев не пытаясь удовлетворить эстетические потребности. Не поймите меня неправильно – я люблю креативно сверстанные статьи, заголовки и подзаголовки, привлекающие мое внимание – но в то же время мы не можем отрицать необходимость баланса между креативностью и удобством восприятия экземпляра текста.
Давайте приступим!

Начнем с начала: исследование проекта

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

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

Контент

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

Оцените все типографские элементы текста

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

Для первичной разметки гипертекста убедитесь, что вы учли все элементы HTML-разметки. На этом этапе вы можете даже создать образцы HTML- и CSS-файлов, включающие в себя все требуемые элементы, и сохранить их как Project-Typography.html. Как вы уже наверное догадались, этот файл станет основой типографской системы проекта и будет очень полезен, когда вы начнете продумывать моменты изменения адаптивного дизайна.

Оцените время на чтение материала

В среднем, скорость чтения текста колеблется от 100 слов в минуту до нескольких тысяч; большинство взрослых людей читают со скоростью от 200 до 250 слов в минуту. Мы можем подсчитать время на чтение текста, просто разделив количество слов в тексте на 250. Если вам доступен пример текстового материала по вашему проекту, просто загрузите его в установленную на вашем компьютере систему CMS и запустите скрипт для оценки времени чтения текста.

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

Оцените легкость чтения и доступность материала

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

Более того, когда вы работаете совместно с копирайтером, шлифуя содержание и типографику материала, подобные тесты позволят легче отслеживать различия между версиями.

Один из таких тестов – Автоматизированный Индекс Доступности (читабельности) текста – Automated Readability Index (ARI). Показатели индекса ARI базируются на количестве символов, слов и предложений, что делает его удобным для мониторинга версий текста в реальном времени. Тест Flesh-Kincaid Grade Level, с другой стороны, фокусируется в основном на количестве слогов, а не символов, что требует несколько более интенсивной работы процессора и менее удобно для оценки материала в реальном времени.

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

Подсчитывание уровня легкости восприятия каждого отрывка текста вручную – чистейшей воды мазохизм, поэтому я рекомендую обратить внимание на Article Readability Stats, скрипт на PHP, который мы в Crearive Nights разработали для наших собственных проектов.

Контент-стратегия, информационная архитектура и микрокопии

Если мы отойдем чуть в сторону от типографии и обратим внимание на контент-стратегию (область планирования и управления контентом для формализации процесса редактирования) и информационную архитектуру (область организации и описания контента), то среди них, вероятно, найдем ряд полезных для нас моментов.

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

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

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

Контекст

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

Известно также, что планшеты используются чаще всего чтобы быстро продемонстрировать что-либо, просматривать ленту в Twitter за завтраком или читать статьи, сидя в туалете (каждый, кто отрицает этот факт, просто не понимает потребностей пользователей). Плотность пикселей на экранах ноутбуков нового поколения значительно превосходит возможности стареньких 30-дюймовых мониторов с разрешением 96 dpi. Мы восхищаемся универсальностью Интернета, но в то же время не можем забывать о разнообразии пользователей и их устройств.

Ограничения ПО

Пользователи ОС Windows, позволяющей сглаживать символы по технологии ClearType, выигрывают от хинтования шрифта. Проблема заключается в том, что хинтинг – длительный процесс, и далеко не все веб-гарнитуры поддерживают его. В этой связи дополнительное тестирование страницы в Windows-браузерах должно войти в число ваших обязательных действий при работе с публикацией.

Эти скриншоты шрифтов Verdana, Proxima Nova, Arial, Adelle Sans и Georgia, кегль 16п. (за исключением Proxima – кегль 18п.) были сделаны в браузере Firefox 18 на Windows 7. Proxima и Adelle воспроизводятся как веб-шрифты, а другие – как обыкновенные шрифты, предварительно установленные на большинстве ОС. Верхние 5 строк сделаны без сглаживания методом ClearType.

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

К счастью для всех нас, вендоры сервисов по настройке веб-шрифтов непрерывно улучают их качество и рано или поздно каждый шрифт будет доведен до совершенства. Поскольку подбор соответствующих шрифтов – задача трудоемкая, я советую вам покупать их и подписываться на платные программы веб-хостинга, которые (помимо всего прочего) стимулируют хинтование шрифтов компаниями-разработчиками. Чем больше будет спрос, тем быстрее пойдет процесс.

Если поддержка Windows-пользователей критична для вашего проекта, обратите внимание на гарнитуры, хинтованные вручную, такие как TheSans Office от компании LucasFonts (эти ребята известны своей страстью к хинтованию) или на ряд других гарнитур, разработанных специально для приложений Microsoft Office (в их названиях часто присутствуют элементы “Com,” “Offc” или“Office”). Если поддержка пользователей со старыми версиями Windows для вас не является приоритетной задачей, используйте проверенные шрифты вроде Arial, Georgia или Verdana.

За более подробной информацией о рендеринге шрифтов советую обратиться к статье Тима Аренса «Рендеринг шрифтов в деталях» (Tim Ahrens, “A Closer Look at Font Rendering”).

Ограничения аппаратного обеспечения

Проблема, с которой мы сталкиваемся в рамках всей индустрии аппаратного обеспечения, заключается в существенных различиях в плотности пикселей на экранах устройств – как результат, зачастую типографика материала оказывается не адаптированной под нужды того или иного устройства. В качестве одного из интересных решений предлагается вводить градуированные шрифты для экранов с различной плотностью пикселей точно так же, как дизайнеры печатных изданий используют градуированные шрифты для более точного контроля нанесения чернил на бумагу. Вы можете прочитать более подробно об этом подходе в статье Оливера Райхенштайна «Новый сайт с адаптивной типографикой» (Olivier Reichenstein, “New Site With Responsive Typography”).

Глифы воспроизводятся по-разному даже на устройствах одного и того же производителя. На изображении представлен шрифт Adele, кегль 16п. так, как он воспроизводится на iPhone 3G, iPad 3 и iPhone 4S (скриншот веб-страницы, увеличенный в Photoshop).

Другой пример – использование гарнитур для билбордов и ТВ-экранов – в этом случае часто необходим более насыщенный шрифт и б`ольшая контрастность. В таком случае необходимо увеличить насыщенность шрифта на два пункта по шкале и сочетать стили Regular и Extra bold. Предпросмотра подобных вариантов дизайна на десктопе или ноутбуке с дисплеем Retina недостаточно – как и в случае проектирования типографики для мобильных устройств, необходимо протестировать полученный дизайн на устройствах с низкой плотностью пикселей.

Тип интерфейса

Помимо аспектов, связанных с программным и аппаратным обеспечением, контекст также требует определенного типа интерфейса. К примеру, новостные порталы, Интернет-журналы, электронные книги должны иметь четко прослеживающуюся структуру, элементы которой, тесно связанные друг с другом, при чтении будут складываться в единую последовательность. Темы статей на информационных сайтах часто неоднородны (даже на нишевых порталах), а историю необходимо рассказывать четко и последовательно для того, чтобы она была понятна читателю (помните про редакторские приемы, о которых мы говорили чуть выше?).

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

В веб-приложениях контекст, окружающий содержание излагаемого материала, в большинстве случаев предсказуем. Вот некоторые из наиболее типичных примеров: проверка данных по продажам, анализ таблиц, диаграмм и графиков со статистикой по сайту, редактирование заметок, относящихся к определенной дате/времени и – в случае использования почтового сервиса – проверка писем на предмет очередного выигрыша в Нигерийскую Королевскую Лотерею.

Пользователь

В Интернете каждый пользователь может быть нашим целевым потребителем, особенно если мы создаем многоязыковую систему. И если на кнопке достаточно места для английского “Return”, то французское “Retour”, немецкое “Zurück”, хорватское “Povratak” и тем более венгерское “Visszatérés” могут не уместиться.

Ограничения доступности

Дислексия – болезнь, характеризующаяся затруднением восприятия письменного материала. Например, страдающий дислексией воспринимает символы, как картинки, видит буквы перевернутыми или в зеркальном отражении. Как результат, печатная (т.н. double-story) буква “а”, написанная в нижнем регистре с коротким хвостом, выглядит для больного дислексией так же, как “е” курсивом.

Кроме того, большинство символов в геометрических гарнитурах тяжелы для восприятия больными дислексией из-за схожести форм различных элементов шрифтов. Латинское “p” в зеркальном отражении будет абсолютно идентично “q”, а перевернутую “n” будет не отличить от “u”. Это не означает, что мы должны немедленно переключиться на специализированные гарнитуры, однако в знании таких моментов проявляется грамотность веб-дизайнера. В случаях осложнений (в каждом четвертом клиническом случае) дислексия сопровождается другим заболеванием – синдромом дефицита внимания и гиперактивности.

Акцент на нижнюю часть символов позволяет больным дислексией различать буквы. На изображении представлены шрифты Futura и Open Dyslexic.

Смягчение контрастности шрифта на экране становится возможным благодаря использованию красных, зеленых и синих субпикселей. К несчастью, небольшому количеству людей на Земле некоторые гарнитуры кажутся более контрастными или наоборот более размытыми, более облегченными или насыщенными, чем большинству, просто потому, что красный субпиксель может оказаться недостаточно различим. Используя бесплатные инструменты, такие как Color Oracle, можно легко узнать, как выбранный вами шрифт воспринимается людьми с затрудненным цветовым восприятием.

Люди с нарушением цветового восприятия воспринимают сглаженные буквы (с применением технологии антиалиасинга) по-разному.

Выбор функциональной гарнитуры

В противовес расхожему мнению, вкус к красивым гарнитурам – не врожденный дар. Конечно, на начальном этапе талант даст вам преимущество, но на нем вы далеко не уедете. Тренируйтесь всесторонне изучать проекты, за которые вы беретесь, и вдохновение для выбора идеальной гарнитуры придет само, позволяя вам значительно сузить круг возможных кандидатов.

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

Поскольку указанные цели столь различны между собой, нам приходится лавировать между ними, вынося суждения о тех или иных типах гарнитур и использовать такие более общеупотребительные прилагательные, как “красивый” и такие менее драматические определения, как “приятный” в отрыве от контекста. Гарнитура может быть оценена только в контексте конкретной ситуации. Если гарнитуры рассматривать изолированно от материала, мы должны сравнивать их только по техническим характеристикам.

Когда я вижу приглашение на детский утренник, написанное шрифтом Comic Sans, первое, что я вынужден сделать (само собой) – прикрыть глаза. Но с другой стороны, я должен быть честным и признать, что он подходит для аудитории – моих детей и их друзей – пока я не поощряю их использовать его всегда и везде. Но если я увижу Comic Sans на корпоративном меморандуме, то, скорее всего, пошлю его вразнос.

Антиква VS. Гротеск (шрифт с засечками и без): кто это начал?

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

Иногда проект позволяет нам сгладить углы, и если вы сделали домашнюю работу и изучили контент, наши решения могут основываться на фактах. Например, если мы демонстрируем вертикально-ориентированные данные (таблицу валютных курсов или список цен на продукты), тогда, вероятно, гарнитура без засечек будет более приемлемой, поскольку антиква как правило задает горизонтальное оринетирование текста. С другой стороны, поскольку засечки “ведут” горизонтальную линию текста, антиква больше подходит для линейно-ориентированного материала или в тех случаях, когда вертикальное пространство ограничено.

Мы часто забываем отойти на шаг назад и взглянуть на картину проекта в целом, хотя и знаем о такой необходимости. Мне, например, нравится объяснение Виталия Фридмана (Vitaly Friedman) и Эллиота Джей Стокса (Elliot Jay Stocks) по поводу их решения использовать шрифт без засечек для основного текста в Smashing Magazine. Взглянув на страницу “с высоты птичьего полета”, объединив в своем восприятии разметку страницы и интерфейс, они заключили следующее:

“Поскольку в Smashing Magazine есть много визуальных составляющих – скриншоты, кнопки, назойливая реклама – шрифт без засечек для основного текста будет уравновешивать этот хаос и восприниматься более гармонично ”
– Виталий Фридман и Эллиот Джей Стокс

Читабельность букв

Другой важный тест на доступной восприятия – проверка того, как сильно отличается каждый глиф от остальных в рамках одной гарнитуры. Дизайнеры используют панграммы, или небольшие тестовые тексты, для оценки и сопоставления гарнитур, например (для английского языка): “The quick brown fox jumps over the lazy dog,” “Handgloves” и “Hamburgefonstiv”. Текст “aegh! iIl1 0O”, составленный дизайнером Джоном Таном (Jon Tan) идет дальше: он представляет собой хороший способ одновременно оценить внешний вид гарнитуры и проверить различия между символами “i,” “I,” “l” и“1”, “0” и “O”.

Мы можем расширить такие панграммы и включить в них курсив, капитель и цифры. Например, мы можем продолжить такую строку буквой “e”, написанной курсивом, чтобы убедиться, что она не слишком похожа на перевернутую строчную “а”, что особенно важно для малых кеглей, когда детали начертания теряются.

Старайтесь избегать неопределенных форм в начертании символов. Сверху вниз: League Gothic, Gill Sans, Myriad Pro, Neue Helvetica.

Международные отношения

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

Довольно необычно видеть такие последовательности символов, как “gy” в венгерском или “ij” в ряде южнославянских диалектов, не говоря уже о диграфах (“ch,” “dž,” “ij,” “lj” и “ty”) и триграфах (“dzs” and “sch”), которые обычно изображаются последовательностью соответственно двух или трех глифов.

Любопытно, что в итальянском алфавите буквы “k,” “j,” “w,” “x” и “y” используются для слов, заимствованных из других языков, часто только в разговорной речи – например “k”, как акцентированное “c” – нечто подобное я услышал, когда подрезал одного парня в пробке в последней поездке по Италии. Но я отвлекся. Язык со слегка усеченным алфавитом содержит, как правило, часто встречающиеся комбинации букв вроде “cc,” “ll,” “tt” и “zz”, находящиеся рядом – или окруженные – буквами “o” или “i”. Нетрудно понять, что подобные комбинации могут стать проблемой при разрядке набранного текста.

В юго-восточной Европе фамилии часто заканчиваются на “č” или “ć”, и никому не понравится, что его имя или фамилия лишились диакритических знаков, или, хуже того, отображаются нечитаемыми символами. Датчане и норвежцы, например, используют знак “ø”, а немцы – “ß” – и это одна только латиница.

Изучайте символы и комбинации символов языка вашей целевой аудитории.

Для того, чтобы правильно отображать расширенную латиницу, нам приходится выбирать гарнитуры, включающие в себя все символы, использующиеся в Центральной Европе (как вариант – использовать платные гарнитуры). Но в случае вышеупомянутых комбинаций в менее общеупотребительных языках, стоит рассмотреть те гарнитуры, которые адаптированы именно для этих языков, потому что в CSS нет поддержки ручного кернинга (кроме шуток).

Нам легче читать знакомые шрифты, но мы лучше запоминаем материал на незнакомых гарнитурах

Считается, что людям легче читать знакомые шрифты (PDF, 11.5 MB). Даже эксперты – к примеру, Жужана Лико (Zuzana Licko) и Эрик Шпикерманн (Erik Spiekermann) – утверждают, что нам легче читать тот шрифт, с которым мы сталкиваемся чаще всего. Изучите историю гарнитуры, которую вы рассматриваете, как подходящую, и сопроставьте ее с тем, с чем ваща целевая аудитория сталкивается чаще всего.
Шрифт Skolar, разработанный Дэвидом Брезиной (David Brezina), был создан для научных работ и публикаций на различных языках, то есть для тех случаев, в которых люди привыкли пользоваться Times New Roman. Skolar – небанальный и современный шрифт, хоть в чем-то он и напоминает Times для того, чтобы целевая аудитория воспринимала его адекватно. Это хороший пример безопасного перехода к современной типографике, однако я настоятельно рекомендую вам экспериментировать и рассматривать различные альтернативы, применимые к вашей целевой аудитории.

Skolar как замена Times и Times New Roman? А вы видите различия между двумя Times?

Недавнее исследование, проведенное Коннором Дайманд-Йауманом (Connor Diemand-Yauman), Даниелем Оппенгеймером (Daniel M. Oppenheimer) и Эриккой Воган (Erikka B. Vaughan) по вопросам эффектов потери беглости речи в процессе обучения – “Effects of Disfluency on Educational Outcomes” (PDF, 1.3 MB) показало, что информация, отображенная трудночитаемыми шрифтами, запоминается легче, чем информация, отображенная шрифтами, которые проще читать. Исследование продемонстрировало, что более глубокая обработка информации мозгом, вызванная затруднением чтения, приводит к стимулированию работы памяти. Это не означает, что мы должны немедленно выбрать самый дикий шрифт на планете – просто в том, чтобы рассмотреть альтернативы привычным шрифтам, тоже есть смысл.

Отображение гарнитур в век адаптивного дизайна

Современный Интернет заново открыл уплотненные гротески и специализированные декоративные гарнитуры. Они добавляют тексту стиля и (визуально) придают вес, особенно хорошо работая в качестве элементов привлечения внимания при указании редакционных данных или при расстановке акцентов в длинном тексте. В данной статье не рассматриваются стилистические предпочтения, поскольку заголовки в сети чаще всего написаны так, чтобы соответствовать требованиям SEO-оптимизации и привлекать больше посетителей, что в некоторой степени отличается от функций заголовков в печатных изданиях. Давайте, однако, поговорим о ловушках, таящихся на пути тех, кто использует уплотненные гарнитуры в Сети, где контент никогда не бывает по-настоящему статичен.

Если опустить вопросы изменения ориентации экрана и формата изображения, то заголовок из нескольких слов, написанный шрифтом типа Skyline (то есть с использованием уплотненной гарнитуры без засечек) может хорошо вписаться в страницу с альбомной ориентацией, предназначенную для отображения на широкоформатных мониторах. В то же самое время, такой заголовок может занимать слишком много места на экране смартфона с книжной ориентацией страницы, особенно когда текст, ранее умещавшийся в одну строчку, разбивается на две. Обыкновенное уменьшение кегля помогает, однако результат может стать далеко не таким удобочитаемым, каким был вначале.

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

Этот заголовок, написанный шрифтом League Gothic в одну строку, становится крайне неразборчивым на экране мобильного устройства. Разбитый на две строки, он занимает слишком много места.

Вариант решения проблемы с применением Nimbus Sans Condensed и Nimbus Sans Extended.

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

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

Шрифт Aller в сочетании с Minion Pro, Georgia и Adelle. Minion Pro и Georgia “проседают” по высоте букв.

Подход для тех, кто не рискует

Самое простое решение при сочетании гарнитур – следовать соотношениям шрифтов и собственному здравому смыслу. Гарнитура, которая является частью большой системы может сочетаться с “членами своей семьи” по любому из параметов (плотность, ширина и засечки), так что можете быть уверены, что сочетание гарнитур из одного семейста будет процессом безболезненным. Поищите гарнитуры в расширенных семействах или “супер-семьях”, включающих в себя больше шрифтов, чем обычный набор (стандартный, курсив, полужирный, полужирный курсив). Расширенные семейства включают в себя массу шрифтов, начиная с облегченных до полужирных или даже особенно жирных, тогда как супер-семейства, также называемые типографскими системами, содержат еще и варианты с засечками и без, а также варианты с различной степенью плотности.

Не стоит слишком переживать о точных классификациях, поскольку категории часто меняются от одной типографской компании к другой. Кроме того, границы между расширенными и супер-семьями не всегда четко определены. Например, некоторые семейства включают в себя антикву и гротеск различной плотности, но не различной жирности. Помните, что многие семейства шрифтов содержат лишь ограниченный набор базовых стилей, хотя только несколько десятков гарнитур являются достаточно универсальными, чтобы удовлетворять всем типографским потребностям (несколько десятков среди сотен тысяч существующих шрифтов – величина крайне малая). Если у вас возникают проблемы при сочетании шрифтов, советую начать с универсальных коллекций гарнитур.

Шрифт JAF Bernino Sans содержит большое количество вариаций плотности и жирноти. Буквы, залитые серым – ложный курсив, также называемый наклонным прямым шрифтом. Некоторые браузеры могут деформировать шрифты в наклонную форму на лету, используя CSS, но ложный курсив определенно является типографским преступлением.

Гарнитуры, разработанные одним и тем же дизайнером, обычно хорошо сочетаются, потому что пропорции литер, их формы, штрихи и углы содержат единую ДНК. Обратите внимание на шрифты, разработанные такими дизайнерами, как: Jos Buivenga, Veronika Burian, Matthew Carter, Nikola Đurek, Adrian Frutiger, Jose Scaglione, Mark Simonson и Erik Spiekermann (это всего лишь несколько моих кумиров) и попытайтесь проанализировать индивидуальный почерк каждого.

Как последний вариант, вы можете использовать гарнитуры одной компании, поскольку компании как правило предлагают гарнитуры, сочетающиеся между собой. Опытный дизайнер подписывается на рассылки, посвященные новостям типографики и, таким образом, узнает об огромном количестве проверенных комбинаций шрифтов, подходящих для многократного использования, как утверждают известные дизайнеры и специалисты по типографии, работающие в компаниях, разрабатывающих шрифты. В качестве бонуса – ваша папка с материалами рассылок рано или поздно станет хорошим архивом полезной информации.

Если вы все еще хотите экспериментировать самостоятельно, следите за тем, чтобы между гарнитурами сохранялся достаточно сильный контраст для поддержания баланса. Избегайте гарнитур, откровенно “соперничающих” между собой – это создаст слишком сильный дисбаланс и будет угнетать читателя. С другой стороны, если две гарнитуры слишком близки друг другу, читателя будет раздражать то, что он не видит четких различий. Сочетание вариантов гарнитуры, близких по плотности (таких, как стандартный и полужирный шрифт или полужирный и жирный) не должно входить у вас в привычку, за исключением случаев, когда вы абсолютно уверены в такой необходимости.

Как и в кулинарии, начните с приготовления простых, съедобных блюд. Затем, приобретя некоторый опыт и никого не отравив, вы можете спокойно убрать книги с рецептами на полку и начать экспериментировать с экзотическими приправами и выдумывать собственные приемы. Если вым интересны практические приемы, вот несколько полезных статей:
• “Лучшие практики сочетания шрифтов”, Дуглас Бонневиль (“Best Practices of Combining Typefaces”, Douglas Bonneville)
• “Какой использовать шрифт? – пять принципов выбора и использования гарнитур”, Ден Майер (“What Font Should I Use?’: Five Principles for Choosing and Using Typefaces”, Dan Mayer)
• “Как выбрать гарнитуру”, Дуглас Бонневиль (“How to Choose a Typeface”, Douglas Bonneville)

Редакторские приемы

Особые декоративные шрифты подходят для коротких отрывков текста, таких как заголовки и врезки, потому что они задают колорит и атмосферу текста и позволяют разбивать длинные отрывки (вы же помните про оценку длительности чтения?). Текстовые гарнитуры утилитарны и подходят для продолжительного чтения. Чтение в какой-то момент может наскучить, особенно если сопровождается отвлекающими внимание элементами, как бывает при чтении с компьютера, подключенного к Интернету.

“Дизайнерам нравится даже блеклый шрифт, что для читателя совершенно неприемлемо”
– Эрик Шпикерманн

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

Мы несем ответственность

Есть два важных фактора, которые могут оказать влияние на ваше решение. Во-первых, если читателю не нравится ваш шрифт, он может изменить его благодаря настройкам своего устройства или приложения. И если он это сделал, то скорее всего изменил шрифт на нечто более привычное, то есть полностью разрушил вашу систему гарнитур. Это как вернуться в те дни, когда необходимо было учитывать соотношение высоты строки в абсолютных единицах и размера букв в Internet Explorer в относительных единицах (мне так рассказывали), поэтому даже небольшое изменение кегля приводило к полному хаосу на странице.

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

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

Перевел: dmitrykabanov
Перевод: http://habrahabr.ru/company/uidesign/blog/174517/
Оригинал: http://www.smashingmagazine.com/2013/02/18/designing-reading-experience/

Оригинал статьи: http://habrahabr.ru/company/2gis/blog/169359/
Код решения можно скачать с Github: https://github.com/Diokuz/baron
Демо: http://diokuz.github.com/baron/

Проблема размещения непрерывного контента произвольного объёма в экран, или окно, фиксированных размеров, существует несколько десятков лет. Примерно столько же существует и лучшее решение этой проблемы: элемент графического интерфейса — скроллбар.

Ниже можно узнать, как в ближайшее время будет работать скролл в 2ГИС Онлайн.

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

Дизайн же системного скроллбара, особенно Windows младше 8 версии, способен изуродовать значительную часть сайтов интернета. То, что не все согласны с этим мириться, подтверждается фактом наличия большого числа решений, программно меняющих системный скроллбар на кастомный.

Сейчас в 2ГИС Онлайн (и, соответственно, в API 2ГИС) мы используем FleXcroll: он эмулирует механизм скролла и не подходит нам по ряду причин:

• Не является кроссплатформенным решением (в частности, плохо работает на Mac)
• Как и любой эмулятор в принципе, имеет проблемы с производительностью
• Не имеет встроенного механизма фиксации заголовков.

Все эти факторы заставили нас задуматься над двумя вопросами:

• существует ли нужное нам готовое решение, или необходимо создавать собственное?
• возможно ли в принципе сохранить системный механизм скролла, но полностью заменить его дизайн?

Нами были сформированы основные требования к решению, которое должно менять визуальное представление скроллбара:

1. Системный механизм скролла должен быть сохранён: коррекции подвергается только его дизайн.
2. Общий размер всех зависимостей должен быть минимизирован. В идеальном случае их не должно быть вообще. Должен быть минимизирован размер и самого решения.
3. Должен присутствовать механизм фиксации заголовков контента при выходе их за поле зрения, либо простой интерфейс для добавления такого механизма (подробнее об этом пункте см. ниже).

Ограничения

На момент написания статьи, более или менее гибко кастомизировать скроллбар средствами CSS можно только в браузерах на движке webkit. Цвета скроллбара можно поменять в браузере Internet Explorer. В остальных браузерах поддержка кастомизации скроллбара через CSS полностью отсутствует. Отчасти это связано с жёсткой позицией w3c:

There are just some things that CSS should not do, full stop.

Существующие решения

Из того большого числа js-библиотек более половины подменяют нативный механизм скролла. Это значит, что для враппера свойство overflow выставляется в значение hidden, а вложенный контейнер с нужным нам контентом меняет свою абсолютную позицию при генерации событий, связанных со скроллом (например, mousewheel). К таким решениям можно отнести: jScrollPane, Scrollbar Paper, jQuery Custom Scrollbar plugin, FleXcroll, Tiny Scrollbar и многие другие.

При таком подходе возникает сразу два фундаментальных недостатка: отсутствие кроссбраузерности и отсутствие же кроссплатформенности. Дело в том, что интерфейс событий, генерируемых действиями пользователя, при помощи которых пользователь что-то скроллит, существенно отличается от браузера к браузеру: с точки зрения стандартов тут творится настоящий бардак. Более того, последовательность и логика «бросания» событий серьёзно отличается и между платформами. Например, трекпады на платформе Mac при скролле генерируют события типа Wheel с большей частотой, чем колесо обычной мыши, что приводит к чересчур быстрому скроллу в ряде подобных решений.

Именно эти недостатки эмуляции скролла привели нас к формулированию первого пункта требований.

Многие решения изначально позиционируются как плагины к jQuery. В ситуации, когда мы используем jQuery по частям, возникает проблема экономии трафика. Проблема существенно растёт при наличии у плагина зависимости от куда более тяжеловесного jQuery UI. Это касается, например, ShortScroll и Vertical Scroll. А также от ряда других библиотек: например, один из немногих jQuery плагинов, сохраняющих нативный механизм скролла, Scrollbars, зависит от 4 плагинов: event.drag, resize, mousehold и mousewheel общим весом более 10 кб.

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

Собственное решение

У решения есть две основных задачи: 1) скрыть системный скроллбар и 2) отобразить кастомный скроллбар.

Для простоты будем рассматривать только вертикальный скроллбар — в нашем случае, как и в большинстве других, нужен только он. Кроме того, это экономит объём выходного кода. Для случая с горизонтальным скроллбаром рассуждения расширяются по аналогии.

Для начала, построим html структуру:

<div class='wrapper' id='wrapper'>
    <div class='scroller' id='scroller'>
        <article class='container' id='container'>
        </article>
    </div>
</div>

где container — собственно, то, что мы хотим скроллировать; scroller — блок, в который по высоте не помещается container, но у него выставлено свойство overflow-y: scroll, что приводит к появлению системного скроллбара у его правой границы; wrapper — окно с шириной чуть меньшей, чем у scroller и свойством overflow: hidden. Ширина меньше ровно на ширину скроллбара scroller. К сожалению, средствами CSS невозможно точно узнать ширину системного скроллбара. Например, не работает вариант с выставлением ширины 125% для scroller и 80% для container, при котором, казалось бы, ширины container и wrapper должны точно совпасть. Можно сделать scroller заведомо шире, а wrapper и container выставить одинаковую ширину, но такой способ не подходит для резиновой вёрстки и порождает баг в webkit браузерах (см. ниже). Введём js-переменные:

var wrapper = document.getElementById('wrapper'),
scroller = document.getElementById('scroller'),
container = document.getElementById('container');

Теперь мы можем вычислить ширину системного скроллбара: scroller.offsetWidth — это ширина scroller, включающая в себя border, padding, а также системный скроллбар. Если мы обнулим border и padding при помощи CSS, и вычтем scroller.clientWidth, мы получим искомую ширину скроллбара в пикселях.

В webkit-браузерах существует особенность, заставляющая скроллиться элементы при выделении в них текста в горизонтальном направлении, даже при overflow-x: hidden. То есть scroller начинает двигаться по горизонтали внутри меньшего по ширине wrapper, в результате чего обнажается скрытый нами системный скроллбар. К счастью, в webkit-браузерах, и только в них, мы можем обнулить ширину скроллбара средствами CSS, после чего ширины всех трёх блоков в точности совпадут и места для горизонтального скролла просто не будет:

.scroller::-webkit-scrollbar { width: 0; }

Теперь нарисуем и спозиционируем кастомный скроллбар. Для этого минимально усложним html структуру на 1 элемент, который и будет полностью отвечать за визуальное представление скроллбара:

<div class='wrapper' id='wrapper'>
    <div class='scroller' id='scroller'>
        <article class='container' id='container'>
        </article>
        <div class='scroller__bar'></div>
    </div>
</div>

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

function dontStartSelect() {
    return false;
}
 
function selection(on) {
    if (on) {
        $(document).on('selectstart', dontStartSelect);
    } else {
        $(document).off('selectstart', dontStartSelect);
    }
}
 
event(bar, 'mousedown', function(e) {
    e.preventDefault();
    selection(false); // Disable text selection in IE8
});
 
event(document, 'mouseup blur', function() {
    selection(true); // Enable text selection in IE8
});

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

Прилипающие заголовки

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

Ни абсолютное (относительно scroller), ни относительное (относительно своих начальных позиций) позиционирование заголовков в чистом виде, в данном случае не подходит. Первое — по причине схлапывания контента, окружающего заголовок и соответствующих им рывков при скролле; второе — по причине нативных неустранимых transition’ов у браузера Internet Explorer для скролла, которые приводят к дрожанию всех зафиксированных заголовков.

В связи с этим, html структуру пришлось ещё немного усложнить, обернув все заголовки в врапперы, задача которых — сохранять место под заголовками при их вырывании из потока во время фиксации абсолютным позиционированием. В принципе, аналогичного результата можно добиться подбором отрицательных margin’ов для заголовков и секций, к которым они относятся — тогда можно обойтись и без врапперов заголовков.

При каждом скролле для каждого заголовка необходимо проверять условие:

scroller.scrollTop - H[i].offsetTop > Sum(H[j].offsetHeight, j=0..i-1)
scroller.scrollTop - H[i].offsetTop < scroller.clientHeight - Sum(H[j].offsetHeight, j=i..n-1)

где H — массив элементов заголовков; i — номер заголовка, меняется в диапазоне от 0 до n-1; scroller.scrollTop — виртуальное расстояние от верхней границы container до верхней границы видимой части container; H[i].offsetTop — расстояние от верхней границы container до верхней границы заголовка H[i].

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

Пробрасывание события mousewheel

В webkit браузерах мы столкнулись с неприятным багом: событие mousewheel не пробрасывалось с фиксированных заголовков вверх к scroller. Это создавало эффект поломки (внезапного прекращения) скролла при попадании под курсор фиксированного заголовка (например, в результате всё того же скролла). То есть, пользователь крутит колесо мыши, под курсор попадает заголовок, фиксируется, и, внезапно, скролл перестаёт работать (точнее, скроллиться начинает вся страница).

К счастью, в webkit браузерах (а нам требовалось обратиться только к ним) есть такая возможность:

$(headers).on('mousewheel', function(e) {
    var evt = document.createEvent('WheelEvent');
    evt.initWebKitWheelEvent(e.originalEvent.wheelDeltaX, e.originalEvent.wheelDeltaY);
    scroller.dispatchEvent(evt); // Пробрасываем событие на scroller
    e.preventDefault(); // Останавливаем скролл страницы
});

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

Пример

Для минимизации объёма js-кода и зависимостей был использован подход, при котором библиотека не является плагином jQuery, хотя по-умолчанию использует его.

Например, в самом простом случае (без фиксации заголовков), инициализация выглядит так:

baron($('.wrapper'), { scroller: '.scroller', container: '.container', bar: '.scroller__bar' });

Причём $(‘.wrapper’) может быть массивом html объектов — проинициализируется каждый из них.

Если вы хотите фиксации заголовков, ограничения верхнего положения скроллбара, и использования альтернатив jQuery, инициализация немного усложняется:

baron($('.test_advanced'), {
    scroller: '.scroller',
    container: '.container',
    bar: '.scroller__bar',
    barOnCls: '.scroller__bar_state_on', // Класс, навешиваемый скроллбару, когда он должен быть видимым
    barTop: 40, // Ограничитель позиции скроллбара сверху
    header: '.header__title',
    hFixCls: 'header__title_state_fixed', // Класс, навешиваемый зафиксированным заголовкам
    selector: qwery, // Селектор
    event: function(elem, event, func, off) { // Менеджер событий
        if (off) {
            bean.off(elem, event, func);
        } else {
            bean.on(elem, event, func);
        }
    },
    dom: bonzo // Библиотека для работы с DOM
});

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

Тестирование

В тестировании принимали участие актуальные версии браузеров Chrome, Firefox, Opera, Safari и Internet Explorer (IE) на платформах Windows, Mac и iOs (тестировались, конечно, только существующие версии браузеров ). Кроме этого, тестировался IE9 и IE8. Все тесты на всех браузерах проходят нормально.

Особенность предлагаемого в данной статье решения заключается в том, что даже в случае каких-то ошибок в JavaScript, скролл всё равно будет работать, поскольку он системный, поэтому категорию риска попадают лишь браузеры устаревших версий Android и Opera Mini, в которых системный скролл на элементах не реализован, или реализован плохо.

Итог

Предложенное решение позволяет сохранить механизм системного скролла, заменить его дизайн, полностью отказаться от жестких зависимостей от других библиотек, и уложиться в 998 байт сжатого кода (минифицированного и сжатого gzip). В довесок к этому, есть механизм фиксации каких-либо элементов скроллируемого контента (например, заголовков).

К недостаткам можно отнести отсутствие горизонтального скроллбара и контролов управления вертикальным.

Код решения можно скачать с Github.
Демо.

Внедрение данного решения запланировано на начало марта.

Far from being just a funny little dinkus propped at one end of a browser’s address bar, favicons today have become a key part of the identity of a website and are used for branding purposes. Proper use of them can help you in creating not only a good first impression among site visitors, but a lasting one.

The concept of favicons was first introduced by Internet Explorer in 1999. They were produced in ICO format and were dropped in the root folder of the domain as /favicon.ico. Since then many things have changed. They are now used for multiple purposes in different devices.

The most basic format of using favicon for a website is as follows:

<link rel="shortcut icon" href="favicon.ico"/>

The rel Property

The important part of the above declaration is the rel property. It is this property which helps the browser identify the favicon and show them properly. Traditional IE browsers used “shortcut” and “icon” both to identify the image and to display it in the browser title and shortcut bar. After the release of HTML5 this has been changed to only “icon” as the global representation of favicon.

The Type Property

The type property can sometimes define whether the browser will display the favicon or not. Internet Explorer sees only the server MIME of the ICO file, otherwise it ignores the file. In general one has to declare the favicon in following ways, for IE:

<!-- For IE6+ -->
<link rel="shortcut icon" href="path/to/favicon.ico" type="image/x-icon">

<!-- For IE6+ -->
<link rel="shortcut icon" href="path/to/favicon.ico">

<!-- For IE6+ -->
<link rel="shortcut icon" href="path/to/favicon.ico" type="image/vnd.microsoft.icon">

One of the best upgrades to the use of the favicon in recent times has been the acceptance of PNG files. You can use transparent images with rounded corners as the favicon for your websites. Rounded corners with transparent edges were too difficult to achieve in ICO format. Browsers like Google Chrome and Mozilla Firefox allow the use of PNG favicons.

An important point to note here is that if both ICO format and PNG format are declared the ICO format will be used by all browsers, irrespective of the order in which they are declared.

<!-- Works in Chrome, Safari, IE -->
<link rel="shortcut icon" href="path/to/favicon.ico">

<!-- Works in Firefox, Opera, Chrome and Safari ->
<link rel="icon" href="path/to/favicon.png">

The Size

Another development in the role of the favicon is the size. Older browsers used 16×16 as the standard size of a favicon while modern browsers allow 32×32 size icons which are later scaled down to appropriate size. IE10 uses the 32×32 size icon to display in the address bar.

<!-- For IE 6-10 -->
<link rel="shortcut icon" href="favicon.ico"/>
<!-- For all other browsers -->
<link rel="icon" href="favicon.ico"/>

With the use of PNG favicons, another new property is added called size” which determines the size of the file specified in the href property. For example:

<link rel="icon" href="favicon16.png" sizes="16x16">
<link rel="icon" href="favicon32.png" sizes="32x32">
<link rel="icon" href="favicon48.png" sizes="48x48">
<link rel="icon" href="favicon64.png" sizes="64x64">
<link rel="icon" href="favicon128.png" sizes="128x128">

In general, Firefox and Safari will use the favicon which comes first in the declaration. Different versions of Chrome have different preferences. Chrome for Windows will use either 16×16 or ICO, whichever comes first. Chrome for Mac will use an ICO favicon if present or else it will go with 32×32 size favicon and scale down to 16×16 for higher clarity in non-retina devices. Opera on the other hand doesn’t have any such preferences; it randomly selects any one from all the favicons presents.

Best Use

Since Internet Explorer does not support PNG files and other modern browsers do, we can wrap ICO files in the conditional statement and leave the PNG files open. For example:

<!-- For IE -->
<!--[if IE]><link rel="shortcut icon" href="path/to/favicon.ico"><![endif]-->

<!-- For Modern Browsers with PNG Support -->
<link rel="icon" type="image/png" href="path/to/favicon.png">

But we have an issue in the above declaration! IE 10 doesn’t support conditional statements and neither do PNG files. What should we do now?

We can drop the ICO files in the root directory and make declarations for PNG files only. This way, Internet Explorer will ignore the <icon rel="icon"> and prefer the ICO image in the root directory. Modern browsers will find the <icon rel="icon"> declaration and use PNG files.

For Apple Devices

Apple devices with iOS 1.1.3 and later require a special type of rel property which can be recognized only by such devices. The rel property in such devices use apple-touch-icon and apple-touch-icon-precomposed.

Here the favicons are used not only to display in browsers but also when a website is bookmarked to the apps screen. Such favicons need to be of a higher resolution and custom-made in order to stand out among other apps.

<!-- For rounded corners and reflective shine in Apple devices -->
<link rel="apple-touch-icon" href="favicon.png" />

<!-- Favicon without reflective shine -->
<link rel="apple-touch-icon-precomposed" href="favicon.png" />

The value apple-touch-icon-precomposed is used to instruct the device not to add reflective shine to the favicon and use it as it is.

The recommended basic size for Apple devices is 57×57 with 90 degrees corners. For higher resolution screens use 114×114 size images. iPad 2 uses 72×72 size while iPad 3 uses 114×114 for retina display.

For Windows 8

Windows 8 uses the concept of tiles and has the option to pin a website to the home screen. The favicon in such should be of good quality in order to get look good on the screen.

<meta name="msapplication-TileColor" content="#D83434">
<meta name="msapplication-TileImage" content="path/to/tileicon.png">

Note that in the above declaration I have used the meta tags instead of a link tag. Windows 8 prefers to see the meta declaration for images in the tiles. The msapplication-TileColor tag specifies the colors to be filled in the tile and msapplication-TileImage specifies the image to display at the centre of the tile.

Limitations to favicons

Favicons can sometime create extra traffic for your website due to repeated checking for it in the same location. Sometimes these can even create garbage 404 errors in the log files if not found.

Another important limitation of these favicons is the inability to load the new favicons automatically. This problem is mostly found in older browsers such as IE6-9.

The rel attribute is also not standardized by W3C, so different user agents define their own version.

Favicons have been the main target of many types of phishing attacks and eavesdropping in past such as showing the secured icon when they are not certified to be secured.

These are all points to be taken into consideration when deciding whether and how to use favicons on a website. None of them should stop you using favicons creatively.

Today, favicons have an importance of their own. Their visual impact will continue to grow and you should expect them to grow in functionality, as well.

Оригинал статьи: http://www.sitepoint.com/favicon-a-changing-role/

Когда мы начинаем работать с адаптивным дизайном, мы сталкиваемся с различными техниками того, как лучше обработать изменение нашего навигационного меню для экранов с низким разрешением. Возможности кажутся бесконечными. Поэтому, я покажу вам четыре главных подхода с их достоинствами и недостатками. Три из них сделаны с использованием только CSS и один — с небольшим количеством JavaScript.

Статья: http://habrahabr.ru/post/159359/
Автор перевода: druf
Оригинал: http://css-tricks.com/responsive-menu-concepts/

Введение

В коде, представленном в статье, я не использую браузерные префиксы, чтобы код стилей оставался простым к прочтению и пониманию. В более сложных примерах используется SCSS. Каждый из примеров размещен на сайте CodePen, где вы можете увидеть скомпилированный CSS.

Все подходы в этой статье используют простой HTML код, который я называю «базовое меню». Атрибут role используется чтобы указать определенный тип: горизонтальное меню (full-horizontal), выпадающий список (select), ниспадающее меню (custom-dropdown) и canvas.

Для стилей я использую один и тот же медиа запрос для всех вариантов:

1. Горизонтальное меню

Самый простой подход, потому что вам нужно лишь сделать список элементов шириной во всю страницу.

С дополнительным оформлением так оно выглядит на экранах с небольшим разрешением:

Преимущества

• Не требуется JavaScript
• Никакой лишней разметки
• Простой код стилей

Недостатки

• Занимает слишком много места на экране

Пример горизонтального меню можно увидеть на сайте CodePen.

2. Выпадающий список

В данном подходе скрывается базовое меню и показывается выпадающий список вместо него.

Чтобы добиться такого эффекта нам нужно добавить в базовую разметку выпадающий список. Чтобы он работал нам придется добавить JavaScript код, который изменяет значение window.location.href когда происходит событие onchange

Скрываем список на больших экранах.

На маленьких экранах скрываем базовое меню и показываем выпадающий список. Чтобы помочь пользователю понять, что это меню — мы добавим псевдо-элемент с тектом «Меню»

С дополнительным оформлением так оно выглядит на экранах с небольшим разрешением:

Преимущества

• Не занимает много места
• Использует «собственные» элементы управления

Недостатки

• Для работы требуется JavaScript
• Происходит дублирование содержимого
• Выпадающий список не удается стилизовать во всех браузерах

Пример этого меню.

3. Пользовательское ниспадающее меню

В данном подходе на небольших экранах скрывается базовое меню и показывается input и label вместо них (используется хак с чекбоксом). Когда пользователь кликает на label, базовое меню показывается под ним.

Проблемы с использованием хака с чекбоксом

Две основных проблемы с этим решением:

1. Оно не работает на мобильных версиях Safari (iOS < 6.0). Невозможно кликнуть на label в браузере под iOS < 6.0, чтобы сработал input из-за бага. Решается добавлением пустого события onclick на label
2. Оно не работает на основном браузере ОС Android версии меньше или равной 4.1.2. Давным давно был баг в WebKit движке, который не позволял использовать псевдо-классы с комбинацией селекторов + и ~

Это не оказывало никакого эффекта, потому что хак с чекбоксом использовал псевдокласс :checked с селектором ~. И пока баг не был исправлен в WebKit 535.1 (Chrome 13) и в актуальном для Android 4.1.2 WebKit 534.30, хак не работал ни на каком устройстве с ОС Android.

Лучшее решение — это использовать анимацию только для WebKit-браузеров для тега <body>

Комбинация всех вариантов создает расширенный хак для чекбоксов:
Для больших экранов мы скрываем label:
Для небольших экранов мы скрываем базовое меню и показываем label. Чтобы помочь пользователю понять, чтобы это меню, мы добавим псевдоэлемент с текстом «≡» в label (представим в виде кода «\2261″, чтобы использовать как содержимое псевдоэлемента). Когда пользователь кликает на input, базовое меню показывается и список элементов раскрывается во всю ширину.

Так меню выглядит на маленьких экранах:

Преимущества

• Не занимает много места в закрытом состоянии
• Целиком стилизуется
• Не требует JavaScript

Недостатки

• Не семантичный код (input / label)
• Требуется дополнительный HTML

Пример работы этого меню.

4. Canvas

В этом подходе, на небольших экранах, скрывается базовое меню и показывается input и label как в варианте 3. Когда пользователь кликает на label, базовое меню выплывает слева и содержимое перемещается вправо. Экран разделяется на части в пропорциях 80% меню и 20% содержимое (в зависимости от разрешения и единиц, используемых в CSS)

На больших экранах мы скрываем label.

На маленьких экранах мы помешаем меню вне содержимого окна и показываем label и input. Чтобы скрыть меню мы устанавливаем для него ширину и отрицательное значение положения. Чтобы помочь пользователю понять, чтобы это меню, мы так же добавим псевдоэлемент с текстом «≡» в label (в виде кода «\2261″, чтобы использовать как содержимое псевдоэлемента).

С дополнительным оформлением так оно выглядит на экранах с небольшим разрешением:

Преимущества

• Не занимает много места в закрытом состоянии
• Целиком стилизуется
• Не требует JavaScript
• Работает как Facebook / Google+ приложения

Недостатки

• Не семантичный код (input / label)
• Требуется дополнительный HTML
• Абсолютное позиционирование элемента body вызывает ощущение зафиксированного положения

Пример этого меню.

Работает ли это под IE?

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

С каждым днем появляется все больше сайтов с адаптивной версткой. При проектировании такого дизайна первое, о чем задумывается разработчик — это общее представление контента на устройствах с разным размером экранов. В этой статье я описал некоторые типы (layouts) адаптивных макетов.

Резиновый

Простой в реализации и очевидный для пользователя тип представления контента. Основные блоки сжимаются до ширины экрана мобильного устройства, где такое невозможно — перестраиваются в одну длинную ленту. Такой макет очень просто реализовать с помощью адаптивных CSS-фреймворков, например Twitter Bootstrap.

Примеры:

• Five Simple Steps
• Princess Elisabeth Antarctica
• Trent Walton
• Sifter
• ChoiceResponse

Перенос блоков

Очевидный способ для многоколоночного сайта: при уменьшении ширины экрана дополнительные блоки (сайдбары) переносятся в нижнюю часть макета.

Примеры:

• Modernizr
• Owltastic
• Wee Nudge
• Festival de Saintes
• Ash Personal Training

Переключение макетов

Этот способ наиболее удобен при чтении сайта с различных устройств: под каждое разрешение экрана разрабатывается отдельный макет. Способ трудоемок, поэтому менее популярен, чем предыдущие два.

Примеры:

• Food Sense
• Performance Marketing Awards
• Forefathers Group
• The Boston Globe
• Andersson-Wise Architects

Адаптивность «малой кровью»

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

Примеры:

• Future Friendly
• Path
• Neovada
• Lycos
• Design made in Germany

Панели

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

Пример панелей в мобильном приложении:

Пример панелей на сайтах:

• Kaemingk Christmas 2012

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

Полезные сайты:

• mediaqueri.es — галерея адаптивный сайтов
• Блог с оригиналом Luke Wroblewski
• Блог Brad Frost

Оригинал статьи: habrahabr.ru/post/158703/