Страницы Фогейма. Общие требования к верстке.

Требования к браузерам

Последние 2-3 версии Firefox, Chrome и Opera Next, а также IE 10+ и Opera 12.1+.

Для проектов, для которых предусмотрены мобильные версии – корректная работа в iOS Safari 6.1+ и браузер по-умолчанию в Android 4+.

HTML

Стараемся использовать не только <div> и <span>, но и другие элементы в зависимости от семантики контента. Тексты предпочтительнее обрамлять в предусмотреных для этого <h?> и <p> и т. п.

Используем все элементы, включая новые, появившиеся в HTML5.

Не боимся таблиц, но если данные не табличные – ставим атрибут role="presentation". Атрибуты id — метки для тестировщиков, для изменения внежнего вида используем только class.

В процессе работы выявили несколько правил, которыми проще руководствоваться в процессе написания HTML:

Если пришло в голову в названии класса использовать подстроку «Title» – это заголовок – <h?>. Все заголовки в блоке начинаем с <h1> и далее по убывающей <h2>, <h3> и т.п. Несколько <h1> – это вполне правильно, если есть отдельные «разделы» на сайте. А они есть, вот почему:
Удобно использовать html-элементы <section> и <article> для обозначения главного элемента в блоке (см. ниже про БЭМ). <section> – для отдельно стоящего блока, а <article> для повторяющихся, одинаковых блоков, идущие подряд в коде. Соответственно внутри них, заголовки, которые начинаются с <h1> подходят идеально.
Если есть какая-нибудь навигация, то не стоит ее делать списком, лучше просто ссылки поместить в <nav>.
Если хочется поставить пустой <i></i> для того, чтобы сделать иконку, то скорее всего это можно сделать с псевдо-элементом :before/:after и элемент вовсе не стоит использовать.
Вообще мы считаем, что псевдо-элементы, это хорошо и не стоит их не использовать, если можно... если они не содержат какую-то важную информацию, а только в декоративных целях, конечно.

БЭМ

Если вы не знакомы с этой аббревиатурой, то о БЭМ можно почитать например на официальном сайте: http://ru.bem.info/method/definitions/

Вкратце – мы задаем класс для каждого элемента, для которого нужно задавать/переопределять стили. Для каждого! Каскад используем только если это заметно облегчает код (например, если реализация hover без каскада невозможна без яваскрипта, который будет менять только класс у нужного элемента).

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

Страничный префикс

Для всех элементов, которые делаются для использования в качестве встроеных внешних страниц, обязательно использование дополнительного т. н. «страничного» префикса. Это префикс к каждому блоку, начинающийся со строчной p (от page – страница) и далее имеющий уникальное, непересекающееся с другими страницами, название. Чаще всего состоит из названия игры и части названия конкретной страницы, например pAtlTournament – это страницы для какого-нибудь турнира для игры «Атлантика».

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

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

Другие изменения в названиях классов

Мы «исповедуем» БЭМ с некоторыми изменениями, которые ввели в начале, поскольку не все в БЭМе казалось очевидным:

для блоков b, элементов e и модификаторов m мы уже не используем префиксы, поэтому классы выглядят так: block(__element)(_modifier_value), хотя раньше использовали, поэтому старые блоки могут быть вида bBlock__eElement_mModifier;
разделитель перед модификатором — один знак подчеркивания;
модификатор может не иметь значение, пример: block_modifier;
многословные наименования пишем в camelCase;
по возможности избегаем миксины — лучше использовать переменные и миксины Less, а если есть одинаковые элементы, которые входят в состав других блоков, то создавать вложенные блоки;
нужно не забывать о страничных префиксов (пока).

CSS

С учетом того, что поддерживаем только современные браузеры (см. требования к браузерам выше), то на полную катушку используем CSS3 и в частности transition, animation, transform (вкл. 3D), flexbox и т. п.

Активно используем псевдо элементы :before и :after, чтобы не создавать ненужные элементы в HTML.

Ластики

Мы на Фогейме отказались от использования т.н. «ластиков», «нормалайзеров» и пр. reset.css, потому что элементов очень много и от них больше вреда, чем польза. Вреда в основном в части производительности, но также смысла в них очень мало – особенно версии, где перечислены все теги, входящие в html.

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

Less

Для упрощения написания длинных классов и сборки всех стилей в несколько файлов, мы используем Less: http://lesscss.org/.

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

.pAtlTournament {
    &__block {
        /* стили для основного элемента блока */
        &__element {
            /* стили элемента */
        }
    }
}

Для каждого блока делаем по одному less-файлу, которые в последствии собираем в одном .css с названием страницы. less-файлы лежат в папках с остальными файлами для блоков.

Файловая структура

Вместо стандартных папок img/, css/ и js/ (или похожие с ними), которые принято делать в каждом проекте, мы используем дерево с блоками – это папка b/ в корне, в которой создаются папки с названиями блоков.

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

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

b/
  layout/
    background.jpg
    layout.less
    logo.png
  myBlock
    icon-4game.svg
    myBlock.less
    bMyBlock.js

Тексты

Мы привыкли типографить тексты. Подробнее об этом можно почитать у Темы Лебедева в Ководстве: http://www.artlebedev.ru/kovodstvo/sections/62/

Неправильно выравнивать тексты с помощью <br> – нужно создать контейнер нужной ширины (если ширину нужно ограничить) и в рамках этого вставить «оттипографленый» текст. Для этого есть очень простая причина – текст может в любой момент поменяться или быть переведенный на другой язык (Фогейм есть не только на русском, но и на английском, немецком, польском и бразильском). И заставлять переводчиков переводит с учетом отведенной ширины блока – нехорошо.

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

Другие детали

Весь контент тянется между 960px и 1200px;
Меньше 960px появляется скролл;
Шрифты — если шрифт есть у гугла (google.com/fonts), то берем шрифт с гугла; если нет, то подключаем через font-face.

Gems/Markup Requirements.md