Capptivate.co captures fleeting transitions between app screens and delightful animated UI elements that we’ll otherwise lose forever as apps and operating systems continue to evolve.

It preserves integral and tricky to communicate aspects of app design, sparks new ideas, and functions as a kinetic pattern library for designers and developers working on iOS apps.

The project was inspired by pttrns.com by Robin Raszka and Mobile Patterns by Mari Sheibly.

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

Статья целиком: 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.

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

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

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

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

A showcase collection of various page transition effects using CSS animations.

Демо: http://tympanus.net/Development/PageTransitions/
Описание: http://tympanus.net/codrops/2013/05/07/a-collection-of-page-transitions/

A simple responsive layout with some fancy page transitions. The idea is to show four items initially and expand them. Some additional page transitions are added for inner items.

Демо: http://tympanus.net/Development/FullscreenLayoutPageTransitions/
Описание: http://tympanus.net/codrops/2013/04/23/fullscreen-layout-with-page-transitions/

An experiment about a realistic looking book showcase with some interactivity using CSS 3D transforms.

Демо: http://tympanus.net/Development/3DBookShowcase/
Описание: http://tympanus.net/codrops/2013/01/08/3d-book-showcase/

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

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

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

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

Если хотите узнать больше о рассылке Мегаплана, рассказать о своем бизнесе или прислать ссылку на интересную статью, проект или блог, пишите: 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/

Features

Responsive Nav is a tiny JavaScript plugin which weighs only 1.7 KB minified and Gzip’ed, and helps you to create a toggled navigation for small screens. It uses touch events and CSS3 transitions for the best possible performance. It also contains a “clever” workaround that makes it possible to transition from height: 0 to height: auto, which isn’t normally possible with CSS3 transitions. View live demo or resize this window to see the plugin in action.

http://responsive-nav.com/