Требуется верстка макета От исполнителя ожидается бюджет, сроки, портфолио 1. Общие положения 1.1 Необходимо сверстать базовый макет, а потом все остальные, чтобы их поведение соответствовало проекту в figma 1.1.1 Необходимо создать стили для форм, для всех элементов. Макет в данный момент готовится 1.2 Основные элементы должны на 100% соответствовать стилю, который задан в компонентах 1.3 Верстка проверяется на соответствие макетам. 1.3.1 Допустимы отклонения в размерах шрифтов, межстрочный интервал, расстояния между элементами (padding, margin). Но отклонения должны быть обоснованы и согласованы 1.4 В качестве основной методологии необходимо использовать БЭМ или его модификации 1.5 Весь интерфейс модульный и содержит множество повторяющихся элементов, потому повторное использование приоритетно 1.5.1 Почти все элементы имеют состояние, потому необходимо использовать модификаторы (элементы дерева имеют множество состояний, которые определяют их цвет и дополнительную иконку; элементы функционального блока имеют состояние открыто/закрыто; основные блоки имеют состояния: свернуто, раскрыто). 1.5.1.1 Front-End разработчик будет оперировать именно состояниями, добавляя модификаторы. 1.6 Максимально стараться избегать important 1.7 Иконки используются fontawesome (в последствии будут другие, но тоже шрифтовые) 1.8 Все загружаемые элементы должны быть загружены локально, без зависимости от внешних сервисов 1.9 Поля вида input могут иметь маски ввода, например, телефон может иметь маску +7 (999) 999-99-99 1.10 Текстовые блоки user generated content (UGC) должны верстаться чистой разметкой пренебрегая правилами БЭМ. Например блок с контентом документа или комментария пользователя который будет выводиться из админки должен содержать чистые теги p, ul, li, blockquote, а не p.article-text__paragraph (наследование от родителя .article-content или .comment__body) 1.11 Верстка должна проходить тесты на переполнения и незаполнения 1.12 Недопустимы грубые ошибки в разметке (ссылки сделаны не тегом , абзацы должны быть абзацами, а не

, формы должны быть только внутри тега
) 1.13 Нельзя использовать транслит в названиях классов, атрибутах и так далее 1.14 Допускается и поощряется комментирование кода 2. Технические условия 2.1 Макет должен одинаково смотреться (с учетом ограничений браузеров) на следующих устройствах: 2.1.1 Мониторы: 19, 21, 23 дюйма 2.1.1.1 Разрешения экранов (ширина): 1920(hd+), 1440 (hd), 1200px (wide) 2.1.2 Операционная система: windows 7, windows 10, MacOs, Debian (KDE, Gnome) 2.1.3 Браузеры: Internet Explorer (11+), Firefox (52+), Chrome (49+), Safari (10+), Opera (56+), Microsoft Edge (15+) 2.2 Мобильная версия будет создана отдельно, но она будет использовать компоненты, созданные в основном макете 2.3 Структура каталогов 2.3.1 /theme/main/ {main} - название текущего шаблона 2.3.2 /theme/main/vendor/ - внешние плагины {наименование vendor}/{плагин}, к примеру: jquery/jquery-contextmenu 2.3.2 /theme/main/css/ - Общие таблицы стилей проекта 2.3.2 /theme/main/js/ - Общие скрипты 2.3.2 /theme/main/images/ - Изображения 2.3.2 /theme/main/fonts/ - Шрифты 2.4 С целью избегания багов с кешем браузера, используем версионирование, при обновлении верстки/стилей/скриптов 2.4.1 ?ver={базовая часть - текущая реализация ядра}.{front.major}.{front.minor} 2.4.1.1 к примеру: theme.site/theme/main/css/buttons.css?ver=0.9.2.1 2.5 Принятый шаблонизатор в проекте - blade (laravel) 3. Стиль программирования 3.1 Табуляция: tab 3.2 Обязательно комментирование крупных смысловых блоков в целях читаемости 3.3 Верстка может быть невалидной по валидатору W3C 3.4 Стиль написания составных слов: under_score 4. Плагины 4.1 Допустимо использование плагинов, но они должны пройти согласование 4.1.1 Плагины jQuery имеют преимущество в выборе 4.2 Перечень принятых плагинов: 4.2.1 Деревья: https://github.com/vakata/jstree 5. Организационные моменты 5.1 Допускаются перерывы в работе до двух дней. Работа в выходные дни и государственные праздники остается на усмотрение исполнителя 5.2 Хорошей практикой является предоставление ежедневной отчетности и информирование о ходе работ 5.3 Код храниться в нашем репозитарии git и обновляется по мере необходимости (желательно в конце рабочего дня) 5.4 Работа ограничена тремя итерациями - основная и 2 правок. В первой исполнитель делает как считает нужным, но допускает незначительное вмешательство заказчика в рамках корректировки глобальных моментов на которые нужно обратить внимание. Далее собирается пакет правок и отправляется на исправление. После этого может быть еще одна такая итерация правок.