Верстка

Речь пойдёт о Marka Email Generator. Это новый плагин для Фигмы инструмента, в котором мы работаем с дизайнами и прототипами писем.

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

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

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

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

Возможности плагина

1. Качество вёрстки науровне высококлассного верстальщика.

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

2. Адаптивность.

   Имеется поддержка адаптивности её теперь полностью контролирует дизайнер.

3. Поддержка Outlook.

   Вёрстка электронных писем, которую генерирует плагин, постоянно тестируется вemailonacid.comи поддерживается популярными почтовыми клиентами, включая Outlook.

4. Поддержка произвольной базовой ширины письма.

   Оптимальной считается базовая ширина 600px, но это не закон. Часто для лучшего результата требуется большая или меньшая базовая ширина. Плагин способен на программном уровне устанавливать базовую ширину в соответствии с шириной вашего дизайн-макета.

5. Возможность добавлять вписьмо блоки сшириной, отличной отбазовой.

   Если необходимо сделать подвал, шапку письма или какой-то акцентный блок в содержимом шириной 100%, в Marka такое возможно.

6. Поддержка тёмных тем.

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

7. Управление видимостью блоков надесктопе/мобильных.

   Если требуется десктопной и мобильной аудитории показывать разные варианты одного и того же блока или вовсе не показывать одной из аудиторий определённый контент, то в Marka это очень просто реализовано.

8. Возможность использования Google-шрифтов.

   Вы можете использовать в Фигме любой шрифт из коллекцииGoogle Fonts плагин автоматически добавит шрифты вписьмо.

9. Автоматическая конвертация SVG-графики врастровую.

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

10. Поддержка шахматных блоков.

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

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

    MailChimp, ExpertSender, MindBox и другие системы рассылки позволяют загружать письмо в вёрстку в виде архива и сразу кодом в html-документе, где есть относительные ссылки до изображений в архиве. Marka умеет выгружать вёрстку писем в таком формате.

12. Опциональная автозагрузка изображений письма наоблачный хостинг.

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

13. Опциональная обработка текста письмаТипографом.

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

14. Опциональная минификация кода.

    Если письмо весит больше 102кБ, почтовый клиент Gmail отобразит его неполностью.

    Если вы делаете в Marka письмо, которое не вписывается в лимит, то можно использовать опцию минификации. Она уберёт лишние символы (пробелы, переносы, комментарии) и сократит вес кода на 40%.

15. Возможность добавления невидимого прехедера.

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

Как собирается письмо измастер-шаблона спомощью Marka Email Generator

Лучше один раз увидеть

Сравним использование плагина для Фигмы с другими способами вёрстки

Marka Email Generator удобное No-code решение с агентским качеством вёрстки писем на выходе. Marka предоставляет новый подход к процессу создание письма и новые возможности. Сравним подход Marka с другими способами создания вёрстки:

Боевое применение нового плагина для Фигмы

Летом продукт был готов кпрактическому использованию. Мызакрыли несколько проектов, где плагин заменил классическую вёрстку.

Одним изпервых заказчиков, для которых мыиспользовали новый инструмент, стал туроператор Алеан.

Мыадаптировали дизайн мастер-шаблона под логику Marka Email Generator. Финальная сборка писем сейчас производится настороне заказчика инапоминает работу сблочным редактором.

Ещё одна работа письма для агентства i-Media:

Что говорят клиенты

Туроператор Алеан

Анна Сахарова, интернет-маркетолог туроператора Алеан:

Технология Marka Email Generator вызвала у нас большой интерес: из макета, сделанного в Фигме, буквально за пару секунд получается письмо, свёрстанное в лучших практиках HTML.

Ребята изEmail Soldiers подготовили для нас два мастер-шаблона, сблоками, которые можно вразличных конфигурациях применять вписьмах. Изних мысоздали уже около 20разных писем. Очень трудно остановиться настандартном шаблоне, когда можно постоянно применять что-то новое ?

Что нам понравилось:

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

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

Сразу в Фигме можно обработать довольно много изображений и даже gif-анимацию и вставить в письмо.

Плагин стоит всего 7$вмесяц.

Ребята готовы помогать вработе сплагином игибко совершенствовать функционал для удобства работы сним.

Агентство интернет-рекламы i-Media

Мария Гудкова, маркетолог i-Media:

Унас вi-Media 13услуг, которые мыпродвигаем ипять отраслей бизнеса, накоторые мынацелены. Под каждую услугу иотрасль регулярно верстаем email-рассылки, отправляем дайджесты для клиентов инаших сотрудников. Вмесяц унас выходит оттрёх довосьми писем.

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

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

Теперь маркетологи сами справляются совсем процессом. Тратим гораздо меньше времени исил наemail-письма. Сплагином отидеи доотправки письма проходит небольше 2часов.

Как отреагировала команда

Что говорит дизайнер

Андрей Ведерников, дизайнер Creative Soldiers:

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

Подойдёт не любой дизайн-макет, а только который сделан по правилам разработчика плагина. В гайде к Marka описаны основные функции плагина для Фигмы и даны подробные разъяснения про его работу. Но главное, что нужно для успешной работы с Marka, практика. Мы до сих пор открываем для себя особенности этого инструмента.

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

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

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

Подводные камни нового плагина для Фигмы

Особенности плагина обнаруживаются, в большинстве своём, методом проб и ошибок.

Можно изучить гайд для разработчиков, но что-то придётся открывать напрямую в работе. Например, в письмах задан кёрнинг (расстояние между буквами) в 3%, а плагин для Фигмы не считал эту информацию. Приходится поправлять руками.

Ещё пример: мобильная версия рассылок работает нетак, как насайтах, ивMarka есть возможность перенести картинку наследующую строку мобильной версии, тогда как ввеб-версии картинки расположены наодной строке. Обнаружили это тоже только напрактике.

Плюсы Marka

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

Что говорит менеджер

Сергей Соболевский, интернет-маркетолог Email Soldiers:

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

Марка отлично подойдёт клиентам, укоторых нет верстальщика вштате.

Плагин для Фигмы гораздо эффективнее классических блочных редакторов: у последних много ограничений при подготовке письма.

У Marka Email Generator есть свой обучающий мануал, но подойдёт он не всем. Для правильной работы нужно разбираться в Фигме хотя бы на среднем уровне.

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

Начнём с самого начала. Создаём базовую HTML-разметку:

<!doctype html><html lang="en"><head>    <meta charset="UTF-8">    <meta name="viewport"          content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">    <meta http-equiv="X-UA-Compatible" content="ie=edge">    <title>Document</title></head><body>    <div id="app">        <header>            <h1 id="title">Color Picker</h1>        </header>    </div>    <div id="colors-block"></div></body></html>

Далее надо вывести все цвета. Я решил выводить их на PHP, чтобы пользователь после открытия страницы уже видел палитру, а не ждал, пока это отрендерится у него на клиенте. Выводить решил в шестнадцатеричном варианте. Для этого делаем 6 вложенных циклов for и выводим блоки 1x1 px.

<?php$color = '';        for($i=0;$i<15;$i++) {            $a = $i;            switch($i) {                case 10:                    $a = 'A';                    break;                case 11:                    $a = 'B';                    break;                case 12:                    $a = 'C';                    break;                case 13:                    $a = 'D';                    break;                case 14:                    $a = 'E';                    break;                case 15:                    $a = 'F';                    break;            }            for($j=0;$j<15;$j++) {                $b = $j;                switch($j) {                    case 10:                        $b = 'A';                        break;                    case 11:                        $b = 'B';                        break;                    case 12:                        $b = 'C';                        break;                    case 13:                        $b = 'D';                        break;                    case 14:                        $b = 'E';                        break;                    case 15:                        $b = 'F';                        break;                }                for($k=0;$k<15;$k++) {                    $c = $k;                    switch($k) {                        case 10:                            $c = 'A';                            break;                        case 11:                            $c = 'B';                            break;                        case 12:                            $c = 'C';                            break;                        case 13:                            $c = 'D';                            break;                        case 14:                            $c = 'E';                            break;                        case 15:                            $c = 'F';                            break;                    }                    for($l=0;$l<15;$l++) {                        $d = $l;                        switch($l) {                            case 10:                                $d = 'A';                                break;                            case 11:                                $d = 'B';                                break;                            case 12:                                $d = 'C';                                break;                            case 13:                                $d = 'D';                                break;                            case 14:                                $d = 'E';                                break;                            case 15:                                $d = 'F';                                break;                        }                        for($m=0;$m<15;$m++) {                            $e = $m;                            switch($m) {                                case 10:                                    $e = 'A';                                    break;                                case 11:                                    $e = 'B';                                    break;                                case 12:                                    $e = 'C';                                    break;                                case 13:                                    $e = 'D';                                    break;                                case 14:                                    $e = 'E';                                    break;                                case 15:                                    $e = 'F';                                    break;                            }                            for($n=0;$n<15;$n++) {                                $f = $n;                                switch($n) {                                    case 10:                                        $f = 'A';                                        break;                                    case 11:                                        $f = 'B';                                        break;                                    case 12:                                        $f = 'C';                                        break;                                    case 13:                                        $f = 'D';                                        break;                                    case 14:                                        $f = 'E';                                        break;                                    case 15:                                        $f = 'F';                                        break;                                }                                $color = "#{$a}{$b}{$c}{$d}{$e}{$f}";                                                                echo '<div class="color__item" style="width:1px; height:1px;background:'.$color.';"></div>';                                $color = '';                                                            }                        }                    }                }            }        }

Если i>=10 то заменяем на символ из шестнадцатеричной кодировки.

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

Неплохо, но попадать по цветам, слишком неудобно. Поэтому увеличим размеры "пикселей"

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

<header>  <h1 id="title">Color Picker</h1>  <nav>    <ul>      <li><a href="?x=blue">Blue colors</a></li>      <li><a href="?x=green">Green colors</a></li>      <li><a href="?x=red">Red colors</a></li>    </ul>  </nav></header>

А в самом PHP и придумал хитрый способ чтобы переписывать нужны было как можно меньше. Теперь цвета выводятся вот так:

<?php$x = $_GET['x'];if ($x == 'red') {$color = "#{$e}{$f}{$c}{$d}{$a}{$b}";} elseif ($x == 'green') {$color = "#{$a}{$b}{$e}{$f}{$c}{$d}";} else {$color = "#{$a}{$b}{$c}{$d}{$e}{$f}";}$q++;if ($q <=10000) {  echo '<div class="color__item" style="width:2px; height:2px;background:'.$color.';"></div>';  $color = '';}

Что получилось:

Остальные палитры доработаю чуть позже или можете доработать их сами!)

Теперь нам нужно непосредственно сделать выбор цвета и сохранение его в элемент формы. В HTML добавляем такой код:

<h3>Selected Color:</h3><div id="selected-color"></div><input type="hidden" id="color" name="color" value="rgb(255,255,255)">

А вот так выглядит JS:

document.querySelectorAll('.color__item').forEach((item, i, arr) => item.onclick = (e) => {document.querySelector('#selected-color').style.background = e.target.style.background; document.querySelector('#color').value = e.target.style.background});

Отлично! Теперь на все цвета вешается обработчик клика и выбранный цвет записывается в наш input[type='hidden'], который можно будет передать с остальной формой. Также мы показываем выбранный цвет пользователю

Безопасность

Не забудем и о безопасности. Так как название палитры передается как GET-параметр и обрабатывается нашим PHP, то есть вероятность XSS-инъекции! Чтобы защититься от инъекции, я позаимствовал код из этой статьи: http://personeltest.ru/aways/habr.com/ru/post/470193/ Автор показал очень простой и эффективный способ защиты, так что не будем городить костыли и воспользуемся им. Код вставлять сюда не буду, т.к. он идентичен коду в той статье, поэтому не буду дублироваться.

Теперь при открытии страницы появляется ошибка: <b>Call to undefined function mysql_real_escape_string()</b>. Я сначала хотел просто удалить эту строку, но подумал, что если кто-то из вас будет пользоваться моим кодом, то наверняка у вас будет работа с базой данных, поэтому проблему нужно решить.

Я вспомнил, что mysql в PHP устарел, и надо использовать mysqli. Поэтому соответствующим образом исправил вызов функции.

Умная IDE подсказывает, что не хватает обязательного параметра. Поэтому вторым аргументом я просто добавил true. Я нередко видел, как вторым аргументом передают булево значение. Например, в json_decode()

Однако, это не сработало, появился warning, говорящий, что аргумент должен быть строкой. Пришлось обернуть true в кавычки, и это, конечно же, помогло.

$v = mysqli_real_escape_string( $v, 'true' );

Однако, теперь ругается на первый аргумент, говоря, что аргумент должен быть объектом mysqli(), поэтому вместо "$v" я передал "new mysqli()". Он опять начал ругаться на что-то, но у меня плохо с английским, и я не понял суть. Поэтому решил забить и просто закомментировать строку. Скорее всего это баг из-за того, что PHP8 вышел лишь недавно, и многое работает криво.

Зато от XSS мы теперь защищены!

Запоминание цветов

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

<div id="save-color-block"><button id="save-color__button">Запомнить мой цвет</button></div>

Как и говорил, у меня плохо с английский языком, и я не знаю как переводится "запоминать". Поэтому, написал по-русски (приношу извинения перед англоязычными пользователями моего кода (I am sorry)).

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

Код получился вот таким:

document.querySelector('#save-color__button').onclick = () => {  const color = document.querySelector('#color').value;  const key = prompt('Write your key:');  const formData = new FormData();  formData.append('key', key);  formData.append('color', color);  fetch('save-color.php', {    method: 'POST',    body: formData  }).then((response) => {    if (response.status === 200) {      alert('success!');    } else {      alert('error!');    }  })

Теперь нам нужно создать файл "save-color.php". Код его будет крайне простым

<?php$key = $_POST['key'];$value = $_POST['color'];file_put_contents($key.'.txt', $value);

Вот и всё! Теперь мы можем просто вбить в адресную строку mydomain.ru/{key}.txt и увидеть цвет, который мы выбирали!

Заключение

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

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

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

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

Вы познакомитесь с несколькими важными областями валидной SEO-верстки и найдете примеры работы с validators.w3.org. Дополнительные материалы, указанные ниже, будут весьма полезны в повседневной работе верстальщика.

Семантические теги

Семантическая верстка - это html элементы со смыслом понятные разработчику, браузеру и поисковым роботам. К таким относят: header, footer, main, article, section, nav, aside и тд. Использование перечисленных тегов описывается по спецификациям W3C или WHATWG. Короткую вводную можно получить в цикле видео\статей HTML шорты от Вадима Макеева. Приведу описание к нескольким тегам.

Section - определяет раздел в документе. В соответствии со спецификацией W3C по HTML5: "Раздел это тематически сгруппированный контент, как правило с заголовком."
Article - определяет независимый, самодостаточный контент. Контент, помещенный в этот элемент, должен иметь смысл сам по себе, т. е. он должен быть понятен в отрыве от остальных частей веб-сайта.
Подробнее о article, а так же section написано здесь.
Header - предназначен для определения заголовочного блока или "шапки" документа или раздела. Подробнее здесь.
Footer - предназначен для определения "подвала" документа или раздела.
Nav - Предназначен только для основного блока навигационных ссылок.
Aside - определяет некий контент, находящийся в стороне от контента, внутри которого он расположен (как боковой блок страницы, "сайдбар").

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

Микроразметка Schema.org

Чаще всего инструкции по включению микроразметки в HTML-код вы будете получать от SEO-специалистов. Но для понимания немного осветим эту тему.

Schema.org - стандарт семантической разметки данных, который помогает поисковикам лучше понимать данные, представленные на сайте. Например, с помощью разметки можно явно указать поисковым роботам, что на странице site.ru/product_page1 находится товар, и передать основные параметры: название, цену, артикул, производителя и т.д. На основе этих данных поисковики формируют расширенные сниппеты в поисковой выдаче.

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

Подробно о микроразметке написано в вики Яндекса. Документация Schema.org. Так же стоит обратить внимание и на гайд от Google.

Как проверить свой HTML

Так как один из критериев к SEO - это валидная верстка, необходимо прогонять написанный код через ранее упомянутый валидатор. К слову, помимо него есть валидатор от Google - в нем необходимо следить за выбранным роботом (Компьютер/Смартфон) и инструмент от Яндекса. Эти инструменты помогут Вам в задачах связанных с микроразметкой. Следует сравнивать новый и старый код, удостовериться, что ошибок нет и все существующие ранее сущности правильно считываются.

В целом, работа с ними сводится к тому, чтобы скопировать HTML код из браузера и вставить его в соответствующее текстовое поле валидатора. Можно копировать куски кода сразу из вашего IDE, но это должен быть чистый HTML с готовыми данными. После прохождения проверки вы будете получать уведомления о различных ошибках в коде. Warning можно опустить. Но от всех Error необходимо избавиться, чтобы верстка удовлетворяла принципам валидной HTML-страницы. В процессе работы могут возникнуть нерешаемые проблемы. Такое стоит гуглить и принимать во внимание, что валидаторы могут не поспевать за всеми нововведениями.

Перейдем к нескольким конкретным примерам (не)валидной верстки и их проверке с validator.w3.org.

Списки

К спискам относятся теги ul и ol (маркированные и нумерованные соответственно).
Выглядит это так:

<ul><li>item 1</li></ul><!-- или --><ol><li>item 1</li></ol>

Внутри открывающего и закрывающего тегов ul могут стоять только элементы li, а уже внутри самих этих элементов (пунктов) можно вставлять любой контент (текст, картинки, заголовки, абзацы, ссылки и даже другие списки). То есть, <ul><div></div></ul> является не валидной версией, и https://validator.w3.org/nu/ явно об этом напишет в выводе ошибок (Рис 1).

Ссылки

В использовании тега <a> тоже есть нюанс, в href недопустимы пробелы. То есть, <a href="tel:+7 (967) 321-22-33">phone</a> не является валидным вариантом (Рис. 2), однако <a href="tel:+7(967)321-22-33">phone</a> соответствует всем критериям.

Атрибуты

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

Таблицы

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

<table border="1" cellpadding="0" cellspacing="0" width="400"></table>

На данный код мы получим сразу 4 ошибки об устаревших атрибутах (Рис. 3).

Это можно спокойно переписать с использованием стилей и классов.

• border - http://htmlbook.ru/html/table/border

• cellpadding - http://htmlbook.ru/html/table/cellpadding

• cellspacing - http://htmlbook.ru/html/table/cellspacing

• width - http://htmlbook.ru/html/table/width

Резюмируя вышеописанное получим примерно такой код:

<style>.table {  border-collapse: collapse;    width: 400px;    border-spacing: 0;   }.column {    padding: 0;    border: 1px solid #333;  }</style><table class=table>  <tr>  <td class=column></td>  </tr></table>

Подобное решение относится ко всем атрибутам, влияющим на стили элементов. Но есть такие, которые относятся к логике DOM-элементов. Чаще их реализация полностью падает на браузеры. Остальное можно реализовать с помощью JavaScript.

Атрибут id

Этот атрибут является неотъемлемой частью HTML. На нем часто завязаны стили и клиентский JavaScript. Данный подход уже давно не используется ввиду усложнения поддержки написанного кода. Используя id в браузере, часто можно наткнуться на проблему отсутствия уникальности значений этого свойства. Поэтому чаще всего чистый id заменяют на data-id или более специфичные названия. У нас часто используются data-атрибуты data-behavior и data-selector. Первый подходит для взаимодействия с пользователем, второй чаще используется для манипуляций с DOM. Однако, насколько я знаю, это необязательное правило. Помимо этого, в css можно писать код с обращением в любые из свойств элементов, будь то data-* или любой другой атрибут.

Пример микроразметки

Помимо примеров валидной верстки хотелось бы привести небольшой кейс использования микроразметки Schema.org. Используя микроразметку, желательно размечать верстку, которая видна на странице и никоем образом не скрывается от пользователя при помощи opacity, visibility, display или top/left/right/bottom: -100500px. Поисковики не жалуют скрытый контент. Иногда бывают исключения, но их стоит уточнять у SEO специалистов.

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

Itemscope - задает область действия словаря в структуре данных. Как правило, работает совместно с атрибутом itemtype и задаёт пределы, где itemtype будет активен. У этого атрибута нет значений.

Itemtype - указывает адрес словаря, который будет применяться для определения свойств элемента в структуре данных. Яндекс и Google поддерживают стандарт разметки Schema.org. Соответственно, в качестве значения itemtype указывается адрес словаря на этом сайте. К примеру, для разметки организаций используется значение https://schema.org/Organization.

Itemprop - используется для добавления свойств словаря микроданных к элементу. Имя свойства определяется значением itemprop, а значение свойства определяется содержимым HTML-элемента, к примеру, текстом который располагается внутри элемента.
Приведем пример микроразметки Article.

<div itemscope="" itemtype="http://personeltest.ru/aways/schema.org/Article"><...>         <div class="article-meta">     <div       itemprop="author"       itemscope=""       itemtype="http://personeltest.ru/aways/schema.org/Person"     >       <span         itemprop="name"         class="meta-item"       >         ВсеИнструменты.ру       </span>     </div>     <time       itemprop="datePublished"       class="datetime meta-item"       datetime="{{ article.getUpdatedTimeObj().format('Y-m-d') }}"     >       {{ article.getUpdatedTimeObj().format('d.m.Y') }}     </time>   </div>   <meta      itemprop="description"      content="{{ article.getShemaOrgDescription() }}"   />   <div     itemscope     itemprop="image"     itemtype="http://personeltest.ru/away/schema.org/ImageObject"   >     <img       itemprop="url"       src="{{ article.getShemaOrgImageUrl() }}"       alt=""       class="d-none"     >   </div>   <...></div> 

В данном примере представлена микроразметка статьи. Действие микроразметки ограничено дивом с атрибутами itemscope, itemtype = Article. Внутри включает микроразметку автора статьи и дату публикации. Включает в себя также краткое описание статьи и изображение. В данном кейсе при помощи бэкенда на этапе публикации парсится весь список изображений и выдается фронтенду при помощи метода getShemaOrgImageUrl().

Я не хотел бы сильно погружаться в детальные гайды по микроразметке, поэтому просто укажу несколько полезных статей на эту тему.
1. Микроразметка для сайта интернет-магазина: как настроить разметку Schema.org для товаров и категорий
2. Микроразметка товаров

Итог

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

Вступление

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

Мифы о UI/UX-дизайнерах

Вначале я хотел бы обратить внимание на предвзятое отношение и недоверие фронтендщиков к UI/UX-дизайнерам. Далее по тексту я опущу приставку UI/UX и буду писать просто дизайнер, подразумевая именно дизайнеров интерфейсов. Выделим несколько мифов, которые мешают в коммуникации.

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

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

Мой дизайнер только рисует макеты, откуда он знает, как лучше? Этот миф распространен у Junior-разработчиков. Специально для них объясню, что дизайнеры то люди, которые прорабатывают макет не только чтобы он смотрелся красиво и современно, но и чтобы им было удобно пользоваться. Они знают множество паттернов поведения пользователя, сочетания цветов и форм, о которых мы не догадываемся, поэтому лучший совет в этом пункте: больше доверяйте своему коллеге, он наверняка знает, что делает.

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

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

Сложности с макетами

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

Следующая проблема связана с высотой блоков и вертикальными отступами между ними. Бывало, делаешь всё по макету, а при проверке на pixel perfect видишь, что вертикальные отступы отличаются. В моём случае это возникло из-за беспорядка в стилях, определяющих высоту блока. В макете высота строки (line-height) была задана в пикселях и была меньше размера основного текста (font-size), а размер блока был задан через height. При вёрстке я не смотрел на высоту блока, потому что обычно она не задается, ведь это может сломать элемент при переносе строки, и такой блок сложнее адаптировать. Высота блока должна формироваться автоматически и состоять из внутренних отступов (padding), высоты строки (line-height) и ширины рамки (border-width), при этом высота строки должна быть больше либо равна размеру шрифта (font-size). Отступы от блока считаются от внешнего края его границы, поэтому чтобы отступы и размеры блока совпадали с макетом, внимательно проверяйте все свойства. Если в них есть проблемы, постарайтесь объяснить их важность своему дизайнеру и попросите его привести эти стили в порядок. На одном из проектов мы с дизайнером договорились, что все отступы в проекте должны быть кратны определённой величине, например, четырем или восьми пикселям, тогда в случае расхождения отступов на сайте и в макете предпочтение отдаётся ближайшей кратной величине. Этот подход решает много проблем, но важно донести его тестировщику, который может прийти с багами, что отступы отличаются от макетов. Ещё рекомендация: всегда просматривайте свою вёрстку в pixel perfect, чтобы знать, где у вас явные расхождения и где вы могли что-то упустить, а где сам макет расходится с дизайн-системой.

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

В макете отступы внутри кнопки 8px от текста до верхнего края кнопки, но при вёрстке приходится уменьшать их на ширину бордера (border-width), потому что в браузере, как правило (если box-sizing: border-box), бордер входит в высоту и ширину элемента, и внутренний отступ (padding) считается именно от его внутреннего края. Похожая проблема наблюдается, когда кнопка в макете без обводки, но при ховере обводка появляется. Тогда, если делать один-в-один с макетом, наша кнопка будет прыгать, поэтому надо самому добавлять бордер с прозрачностью. Рекомендация только одна: всегда нужно удостовериться, что ваш элемент выглядит так, как нужно.

Следующая проблема связана с прелоадерами. В решении нам поможет теория конечных автоматов. Часто сами фронтендщики грешат тем, что задают одну булевую переменную (isFetching или isLoading) для отображения прелоадера, хотя состояний там гораздо больше. Например, в случае повторного перехода на страницу, на которой уже есть кэшированные данные, произойдёт отображение контента, а потом всё исчезнет и появится прелоадер, потому что пройдет обновление данных. Согласитесь, это не очень красиво. Такая проблема возникла потому, что мы смешали состояние первичной загрузки и обновления данных, а прелоадер использовали один и тот же в обоих случаях. Решить это можно, попросив вашего дизайнера продумать все состояния. Для этого лучше описать их, либо привести пример. При этом на фронтенде нужно будет задавать переменную не в булевом виде, а перечислением состояний, и обрабатывать каждое состояние отдельно.

Раз уж зашла речь о состояниях, хочу отметить, что часто в макетах не хватает всех состояний интерактивных элементов. А их, как правило, шесть:

• Normal сообщает, что компонент интерактивен и включен.

• Focus сообщает, что пользователь выделил элемент, используя клавиатуру или другой метод ввода.

• Hover сообщает, когда пользователь навел курсор на интерактивный элемент.

• Active активное или нажатое состояние сообщает о том, что пользователь нажал на кнопку.

• Progress/Loading используется, когда действие не выполняется немедленно и сообщает, что компонент находится в процессе завершения действия.

• Disabled сообщает, что компонент в настоящее время не является интерактивным, но может быть включен в будущем.

Часто про это забывают, и некоторые состояния сливаются. Сами фронтенд-разработчики иногда объединяют hover и focus в один стиль, что является ошибкой. Постарайтесь обсудить это со своим дизайнером до старта работ, потому что такие решения влияют на доступность вашего продукта. Самый жизненный пример вы кликнули на кнопку, а потом убираете с неё курсор, но она как будто остаётся в состоянии ховера.

О доступности можно написать отдельную статью, поэтому здесь обозначу свою основную боль. Почти во всех проектах, где я работал, дизайнер требовал убрать эту уродскую синюю обводку, которую мы просто отключаем, ничего не добавляя взамен. Речь идёт про outline. Отключая его и не давая ничего взамен, мы ломаем клавиатурную поддержку вашего сайта, потому что по сути мы отключаем у всех интерактивных элементов состояние focus. Вряд ли пользователи, которые пользуются вашим сайтом с клавиатуры, поблагодарят вас, а их немало.

Следующая сложность возникает, когда стайлгайд используется неправильно. Например, есть шрифты для десктопной версии Heading-1 и мобильной версии MobileHeading-1, но в макете Heading-1 в десктопе в мобильной версии неожиданно становится Heading-3. С этим очень сложно работать, потому что вся система, которую я делал на фронте по стайлгайду, начинает рушиться прямо в этом месте. Основной посыл: если есть стайлгайд или дизайн-система, старайтесь максимально ей соответствовать. Например, если дизайнер спрашивает, нужно ли добавлять в стайлгайд немного изменённую кнопку, однозначно говорите да.

Отдельно поговорим об адапативности. Как правило, вёрстка бывает адаптивная и резиновая. Адаптивная подстраивается под конкретные заданные разрешения экрана, а резиновая плавно изменяется, подстраиваясь под любую ширину экрана. На мой взгляд, резиновая вёрстка более современная и универсальная, а ее создание не вызывает трудностей, потому что в арсенале есть flex-box, grid, vw/vh, математические функции и прочее,. Однако, все давно привыкли к бутстраповским брекйпоинтам, и большинство макетов опираются именно на них. Хорошо, если в макете есть хотя бы три состояния: десктоп (как правило, 1440px), планшет (часто это 1024px или 768px) и телефон (320px или 375px). Именно с этого места обычно начинаются проблемы. Приходит заказчик и говорит, что на его моноблоке, у которого разрешение 2500px, сайт выглядит ужасно. Потом приходит аналитик и говорит, что сайт плохо выглядит на его ноутбуке, с разрешением в 1380px и так далее. Здесь описано сразу две проблемы.

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

Вторая проблема промежуточные состояния в макетах. Если размышлять адаптивно, а не резиново, все версии, отображаемые в макете, используются для состояний выше указанного, то есть макет на 1440px подходит для экранов шириной от 1440px и выше до следующего брейкпоинта (если он есть, конечно). Если ширина экрана меньше указанной в макете, должна отображаться версия для предыдущего брейкпоинта. Например, у вас в макете есть состояние на 1440px и 768px, на ширине в 1380px должна отображаться версия на 768px с ограничением ширины контентной области в соответствии с макетом. Выглядеть это будет не очень, мягко говоря. Худший сценарий, когда между брейкпоинтами большой разрыв. Например, дизайнер отобразил состояние на 1920px и на 768px. Тогда, следуя прямой логике, на 1440px включится состояние 768px, но так быть не должно. Суть проблемы в том, что, глядя на макеты в трёх разрешениях, фронтендщик не всегда понимает, какое состояние и в какой момент должно включиться. Если рассмотреть этот пример на резиновой вёрстке, на ширине экрана в 1380px должен отображаться макет для версии в 1440px, а на ширине 1110px версия для 1024px. Здесь возникают вопросы: в какой момент должна включаться какая из версий? До какой ширины экрана будет отображаться версия в 1024px? рассмотрим потенциальные варианты решений. Первый пойти к дизайнеру и описать проблему. Наверняка у него уже есть видение, как сайт должен меняться при сжатии и расширении экрана, он объяснит вам хотя бы на словах, однако это не всегда работает. Второй вариант отвязать свой разум от бутстраповских брейкпоинтов и рассматреть каждый блок как независимый. Потом я начинаю сжимать и разжимать каждый блок, наблюдая за его поведением, и определяю оптимальное разрешение для смены состояния. Многим верстальщикам такой подход не нравится и кажется избыточным. Основной аргумент возможно появление множества брейкпоинтов, но как показывает практика, этих состояний вряд ли будет больше шести, и все они будут инкапсулированы внутри своих блоков и ни на что не повлияют. Однако, ваш макет будет действительно резиновый и сможет подстраиваться под любое разрешение экрана.

Чем дизайнер может помочь фронтенд-разработчику

Здесь я собрал некоторые пункты, наличие которых в проекте помогло бы мне верстать.

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

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

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

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

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

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

• Названия у цветов и шрифтов. Когда у всех цветов и типов шрифтов есть имена, фронтенд разработчику не придётся их придумывать. Идеально, если имена содержат только буквы, цифры и знаки $ и _, при этом первый символ не является цифрой. Это необязательно, но позволит использовать названия прямо в коде, что облегчит их применение и поддержку в актуальном состоянии.

• Консистентность между версиями. Это, скорее, просьба к дизайнерам. Разрабатывая макет мобильной версии сайта, старайтесь помнить, что это всё-таки сайт, а не мобильное приложение. Хочется видеть консистентность между десктопной и мобильной версиями. В некоторых проектах мобильная и десктопная версии настолько отличались, что приходилось делать разные версии с нуля, а это забирает в два раза больше времени на разработку.

Что следует знать дизайнерам о фронтенде

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

  • box-sizing определяет, как вычисляется общая ширина и высота элемента;

  • margin определяет внешний отступ;

  • padding определяет внутренний отступ;

  • border отвечает за все персональные свойства границ;

  • overflow работает с переполнением;

  • flex/grid наиболее популярные типы отображения элементов.

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

• Отличие блочных элементов от строчных. Это позволит глубже понять композицию веб-страницы.

• Браузерные инструменты разработчика упростят процесс проведения авторского надзора и помогут проверить некоторые гипотезы непосредственно в рабочей среде.

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

Что следует знать фронтендщику о дизайне и не только

• Сетка. Практически все макеты строятся на основе сетки. Зная её, верстать становится проще, а учитывая, что теперь у нас есть grid, это превращается в удовольствие.

• Основы Figma. Говорить с дизайнером на одном языке и понимать особенности и отличия вёрстки в Figma и WEB-е.

• БЭМ. Неважно, как вы верстаете, будь то CSS-in-JS или CSS-modules, методология позволяет навести порядок в голове и мыслить правильными категориями.

• Наследование стилей. Многие CSS свойства наследуются от родительского блока, в Figma это отсутствует.Чтобы не переписывать все стили, не глядя , помните, какие свойства берутся от родителя, а какие объявляются в самом элементе.

• Конечные автоматы. Понимать, сколько состояний может быть у того или иного элемента на странице.

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

Заключение

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

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

P. S. (постскриптум)

За помощь в подготовке материала благодарю самого крутого из дизайнеров Олега Ровного.

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

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

Вы готовы? Тогда вперёд!

В чём основная проблема?

Если вы используете переменные CSS так же, как и препроцессоры CSS (например в Sass), то вы не полностью реализуете все их преимущества. Рассмотрите следующий пример:

:root {    --brand-primary: #7777e9;    --brand-secondary: #c96fde;}.title {    color: var(--brand-primary);}

И тут нет никакой разницы с нижеприведённым примером в Sass:

$brand-primary: #7777e9;$brand-secondary: #c96fde;.title {    color: $brand-primary;}

Да, применение переменных CSS в качестве переменных цвета ни в коей мере не является ошибкой. Но это всё равно, что покупать Apple MacBook M1 для посещения интернет-сайтов, хотя с этим и так хорошо справляется ваш старый настольный ПК, собранный в 2012 году. Какой смысл покупать ультрасовременный компьютер и делать на нём то же самое, никак не используя весь спектр его возможностей? Как вы понимаете, примерно так я и думаю об использовании переменных CSS для сохранения информации о цветах.

Цель этой статьи познакомить с различными вариантами практического применения, где полностью раскрываются возможности переменных CSS. Приступаем!

Примеры и случаи практического использования

Полные формы записи свойств

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

<!-- Base component --><header class="page-header">    <h2>...</h2>    <p>...</p></header><!-- Component variation --><header class="page-header page-header--compact">    <h2>...</h2>    <p>...</p></header>

.page-header {    --padding-start: 2.5rem;    --padding-block: 2rem;    padding: var(--padding-block) 1rem var(--padding-block) var(--padding-start);}.page-header--compact {    --padding-start: 1.5rem;    --padding-block: 1rem;}

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

.page-header {    padding: 2rem 1rem 2rem 1.5rem;}.page-header--compact {    padding: 1rem 1rem 1rem 2.5rem;}

Всё вышесказанное применимо и для свойства внешнего отступа margin.

Свойства CSS background

Что касается свойств CSS для работы с фоном, то и здесь переменные CSS помогают сократить объём создаваемого нами кода. И даже больше того: благодаря их применению сам код CSS легче читать.

Хранение значений URL

При работе с интерфейсом пользователя вам может потребоваться добавить какое-либо изображение в декоративных целях. В таком случае хорошим решением будет использование элементов <div> и background-image. Если интерфейс должен быть динамическим, то значения для изображения нужно подставлять с помощью JavaScript.

Без применения переменных CSS соответствующий код HTML будет выглядеть так:

<section     class="newsletter"     style="background-image: url('/assets/ui/decoraitve/newsletter-lg-aj1891101.svg')"></section>

Но вместо того, чтобы напрямую изменять свойство background-image, мы можем сделать следующее.

<section     class="newsletter"     style="--thumb:url('/assets/ui/decoraitve/newsletter-lg-aj1891101.svg')"></section>

.newsletter {    background-image: var(--thumb);    background-size: cover;    background-position: 100% 50%;}

Обратите внимание, что необходимо включить элемент url() без переменной CSS.

Положение фонового изображения

В приведённом выше примере фоновое изображение помещается справа. Для макетов с направлением текста справа налево (RTL) положение фона следует перевернуть.

.newsletter {    --pos: 100% 50%;    background-image: var(--thumb);    background-size: cover;    background-position: 100% 50%;}html[dir="rtl] .newsletter {    -background-position: 0% 50%;}

Чтобы упростить эту задачу, мы можем воспользоваться переменными CSS.

.newsletter {    /* other styles */    background-position: var(--pos);}html[dir="rtl] .newsletter {    --pos: 0% 50%;}

Угловой градиент: часть 1

Угловой градиент также можно применять при создании макетов для нескольких языков. По умолчанию он может быть равен 45deg, и, возможно, потребуется изменить его на -45deg для макетов RTL.

.element {    --angle: 90deg;    background: linear-gradient(var(--angle), #4088vb, #C05858);}html[dir="rtl] .element {    --angle: -90deg;}

Угловой градиент: часть 2

В случае с угловым градиентом использование переменных CSS с радиальными градиентами действительно существенно упрощает настройку положения. В следующем примере положение градиента изменяется при помощи переменной --pos.

А здесь показано, как можно сделать то же самое без переменных CSS.

.card {    background: radial-gradient(        circle 200px at center top,        rgba(64, 136, 203, 0.5),        #f7f7f7    );}

Теперь предположим, что у нас есть какой-то вариант карточки .card-2 и он должен находиться в другом положении. Необходимо написать следующий код:

.card-2 {    background: radial-gradient(        circle 200px at center top,        rgba(64, 136, 203, 0.5),        #f7f7f7    );}

Таким образом, переписывается всё определение градиента. Можно ли сделать лучше? Определённо. Обратите внимание, что единственным настраиваемым значением для этого варианта является переменная --pos.

.card {    --pos: center top;    background: radial-gradient(        circle 200px at var(--pos),        rgba(64, 136, 203, 0.5),        #f7f7f7    );}.card-2 {    --pos: left top;}

Свойство clip-path

Весьма полезным случаем использования переменной CSS является изменение с её помощью значений clip-path: polygon() при переходе с настольных на мобильные устройства.

На показанном выше рисунке необходимо изменить положение вершин многоугольника. С помощью переменных CSS сделать это намного проще.

.hero {    --first: 4% 7%;    --second: 80% 0;    --thrid: 100% 95%;    --fourth: 10% 100%;    clip-path: polygon(var(--first), var(--second), var(--thrid), var(--fourth));}@media (min-width: 40rem) {    .hero {        --second: 96% 0;        --thrid: 92% 82%;    }}

Если вы хотите узнать больше о свойстве CSS clip-path, здесь вы найдёте статью за авторством вашего покорного слуги.

Элемент флажка

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

Первое, что я сделал, это определил значения hsla() для корневого элемента компонента.

.form-item {    --primary-h: 240;    --primary-s: 56%;    --primary-l: 63%;    --primary-alpha: 100%;}

Теперь я могу использовать эти свойства в функции определения цветов hsla().

/* The circle that appears on hover */.form-item__label:after {    --primary-alpha: 0;    background-color: hsla(        var(--primary-h),        var(--primary-s),        var(--primary-l),        var(--primary-alpha)    );}.form-item__label:hover:after {    --primary-alpha: 15%;}

Код SVG, встроенный в CSS

Когда-то я работал над пользовательским интерфейсом для проекта одного клиента и столкнулся с такой ситуацией. У нас был раздел с двумя лентами (одна сверху, а вторая снизу). Мне необходимо было изменить цвет, угол поворота и размер этих лент, не создавая отдельный код CSS для каждой из них. Спасением стали переменные CSS!

Прежде всего я подготовил требуемый код SVG в Adobe Illustrator. Я разделил каждую ленту на три слоя:

• светлые области;

• тёмные области;

• базовый слой.

Затем я экспортировал этот код SVG и поместил его в элементах <defs> так, чтобы легко можно было использовать его повторно. Обратите внимание, я также добавил ключевое слово currentColor! Это и есть то самое магическое значение, которое заставит всё работать.

Наконец, теперь нам необходимо определить размер и угол поворота в CSS.

.tape {    width: var(--size);    transform: rotate(var(--angle));}

<svg class="tape" style="--angle: 10deg; color: red; --size: 120px;" aria-hidden="true" focusable="false" viewBox="0 0 123 47">  <use href="#tape"></use></svg>

Готово. Мы создали собственный код SVG, который можно настраивать по мере необходимости. Впечатляет, не правда ли?

Создание миксинов (примесей-шаблонов), таких, как в Sass

Об этой интересной возможности я узнал из рекомендуемого мною к просмотру выступления Ли Веру (Lea Verou). Идея состоит в том, чтобы установить исходные переменные CSS для определённого свойства, а затем переопределять их, когда это понадобится.

Здесь показан пример, как мы можем использовать эту возможность. Очень часто мне необходимо, чтобы враппер был центрирован, для чего можно добавить margin: 0 auto к соответствующему элементу враппера. В тех случаях, когда необходимо отцентрировать какой-то свой элемент, мы можем выполнить следующее:

<div class="featured-section u-center"></div>

.u-center {  --mx: initial;  --my: initial;  margin: var(--my) var(--mx);}.featured-section {  --mx: auto;  --my: 2rem;}

Во-первых, я создал служебный класс .u-center с заданными по умолчанию значениями для горизонтальных и вертикальных внешних отступов. Я могу добавить этот класс к элементу и затем переопределить переменные CSS. Это может оказаться очень полезным, например, если элементу нужны определённые внешние отступы только с верхней и нижней сторон.

Использование функции calc()

Функция calc() в сочетании с переменными CSS может очень пригодиться. Мы можем создать какой-то базовый размер для компонента, а затем, меняя только одну переменную, можем делать его больше или меньше.

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

.c-avatar {  width: calc(var(--size, 32) * 1px);  height: calc(var(--size, 32) * 1px);}

Обратите внимание, я использовал функцию var(--size, 32). Если переменная --size не определена, то значение 32 будет использовано как резервное значение. Важно указать 1px, чтобы добавить px к результирующему числу.

Таким образом, мы можем создавать вариации классов, просто добавляя переменную CSS --size.

.c-avatar--medium {    --size: 64;}.c-avatar--large {    --size: 128;}

Псевдоэлементы

С помощью переменных CSS можно изменять свойство псевдоэлемента, поскольку оно наследуется от родительского элемента. Рассмотрите следующий пример:

В заголовке раздела содержится декоративная фиолетовая линия, которая является псевдоэлементом. Мы можем передать переменную CSS данному заголовку, и этот псевдоэлемент унаследует её.

.section-title {    --dot-color: #829be9;}.section-title:before {    content: "";    background-color: var(--dot-color);}

Но, кроме того, мы также можем имитировать изменение цвета псевдоэлемента с помощью Javascript.

Встроенные стили

Другим примером полезного применения переменных CSS является использование их в качестве встроенных стилей. И тут открывается множество возможностей для настройки какого-либо компонента путём изменения одной или нескольких переменных.

Рассмотрите следующий пример.

.o-grid {    display: grid;    grid-template-columns: repeat(auto-fit, minmax(var(--item-width, 200px), 1fr);    grid-gap: var(--gap);}

У нас есть настроенный грид и заданное по умолчанию для ширины элемента грида значение 200px. В коде HTML мы можем переопределить его, переустановив значение для переменной CSS.

<!-- Example 1 --><div class="o-grid" style="--item-width: 250px;">     <div></div>     <div></div>     <div></div></div><!-- Example 2 --><div class="o-grid" style="--item-width: 350px;">     <div></div>     <div></div>     <div></div></div>

Ну разве это не полезно? Если вы хотите узнать больше о переменных CSS со встроенными стилями, я уже писал об этом более подробно.

Заключение

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

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Серьёзно и профессионально я начал заниматься вёрсткой в 2019 году, хотя до этого ещё со школы интересовался данной темой как любитель. Поэтому новичком мне себя назвать сложно, но и профессионалом с опытом 5+ лет я тоже не являюсь. Тем не менее, я успел познакомиться со сборщиком Gulp, его плагинами и сделал для себя хорошую, как по мне, сборку для работы. О её возможностях сегодня и расскажу.

ВАЖНО! В этой статье речь пойдёт о самой последней версии сборки. Если вы пользуетесь версиями сборки, вышедшими до публикации этой статьи, информация будет для вас не релевантна, но полезна.

Какие задачи решает эта сборка?

• вёрстка компонентами (вам не нужно в каждую страницу копировать head, header, footer и другие повторяющиеся элементы, вплоть до кнопок или кастомных чекбоксов);

• вёрстка с препроцессорами (SASS/SCSS);

• конвертация шрифтов из ttf в eot, woff, woff2;

• лёгкое (почти автоматическое) подключение шрифтов;

• лёгкое (почти автоматическое) создание псевдоэлементов-иконок;

• обработка изображений "на лету";

• минификация html/css/js файлов;

• возможность вёрстки с использованием php;

• выгрузка файлов на хостинг по FTP;

• несколько мелких задач с помощью миксинов.

Собственно создание сборки

Начнём собирать нашу сборку (простите за тавтологию). Предварительно нам потребуется уже установленная на компьютере LTS-версия Node.js и NPM (входит в пакет Node.js) либо Yarn. Для нашей задачи не имеет значения, какой из этих пакетных менеджеров использовать, однако я буду объяснять на примере NPM, соответственно, для Yarn вам потребуется нагуглить аналоги NPM-команд.

Первое, что нам нужно сделать - это инициализировать проект. Открываем директорию проекта в командной строке (очень надеюсь, вы знаете, как это делается) и вводим команду npm init.

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

Далее будет намного удобнее работать через Visual Studio Code (поскольку у него есть встроенный терминал) или любой другой удобный вам редактор + терминал.

Прежде всего, нам нужно установить сам Gulp. Делается это двумя командами npm i gulp -global - устанавливаем Gulp глобально на систему и npm i gulp --save-dev - устанавливаем Gulp локально в проект. Ключ --save здесь отвечает за сохранение версии плагина при дальнейшей установке (без него вам может установить более новую, несовместимую с другими плагинами версию), а ключ -dev указывает на то, что этот пакет необходим только во время разработки проекта, а не во время его выполнения. Например, если мы устанавливаем в проект пакет Swiper, который содержит скрипты слайдера и будет отображаться на странице, мы будем устанавливать его без ключа -dev, поскольку он нужен для выполнения, а не для разработки.

После того, как Gulp установился, имеет смысл создать в корне проекта управляющий файл gulpfile.js, в котором мы и будем писать задачи для сборщика.

После этого нам нужно подключить Gulp в нашем файле, для того чтобы он исполнялся. Это делается с помощью require:

const gulp = require('gulp');

Далее, для каждой задачи будем использовать модули в отдельных файлах. Для того, чтобы не подключать каждый модуль отдельно, нужно установить и подключить плагин require-dir. Устанавливается он всё той же командой (как и все последующие плагины, поэтому далее повторяться не буду, просто знайте, что установить - это npm i $PLUGIN-NAME$ --save-dev). После установки подключаем его и прописываем путь к директории, в которую будем складывать модули (у меня это директория tasks):

const gulp = require('gulp');const requireDir = require('require-dir');const tasks = requireDir('./tasks');

Первая задача

Давайте проверим, всё ли мы правильно сделали. Создадим в директории tasks файл модуля с именем hello.js. В созданном файле напишем простейшую функцию, которая будет выводить в консоль строку "Hello Gulp!" (можете придумать что-то менее банальное, если хотите).

module.exports = function hello () {console.log("Hello Gulp!");}

Теперь вернёмся в gulpfile.js и зададим там задачу hello:

const gulp = require('gulp');const requireDir = require('require-dir');const tasks = requireDir('./tasks');exports.hello = tasks.hello;

Теперь командой gulp hello в терминале запустим нашу задачу. Если всё сделано правильно - в терминал должно вывестись приблизительно такое сообщение:

[13:17:15] Using gulpfile D:\Web projects\Easy-webdev-startpack-new\gulpfile.js[13:17:15] Starting 'hello'...Hello Gulp![13:17:15] The following tasks did not complete: hello[13:17:15] Did you forget to signal async completion?

Так же, можно получить список всех заданных задач командой gulp --tasks.

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

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

Получиться в итоге должно приблизительно следующее:

 project/  build/ 

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

Почему возникает проблема

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

Ссылки создаются с помощью тега <a>.

<a href="http://personeltest.ru/aways/htmlacademy.ru">HTML Academy</a>

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

Для кнопок используют тег <button>.

<button class="button">9 900 руб.</button>

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

Что случится, если вместо ссылки сделать кнопку

Если URL-адрес обернуть не <а>, а тегом <button>, то при нажатии пользователя на правую кнопку мыши браузер предложит выполнить действия, которые положены при клике на кнопку. Адрес нельзя будет открыть в новой вкладке или отправить через контекстное меню.

Такая кнопка не позволит открыть страницу в новой вкладке и через комбинацию клавиш Ctrl и левая кнопка мыши.

При наведении курсора на правильную ссылку её адрес появляется внизу окна браузера. URL-адрес, обёрнутый в <button>, не отобразится.

Что произойдёт, если вместо кнопки сделать ссылку

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

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

<a href="javascript:;">На самом деле это кнопка</a>

При наведении курсора на псевдоссылку внизу окна браузера появится не адрес, а javascript:; или АдресТекущейСтраницы/#.

Как определить элемент по макету

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

У ссылки должны быть стили для состояния покоя, при наведения курсора :hover, в момент нажатия :focus, активного :active и иногда состояния, когда пользователь уже посещал эту страницу :visited.

У кнопки нет состояния :visited, зато есть состояние блока :disabled.

Однако рассчитывать только на макет не нужно. У ссылки может не быть :visited, а у блока :disabled это может запутать.

Забудьте про div семантика спасёт интернет

Всё-таки кнопка или ссылка?

Если дизайнер по каким-то причинам не отрисовал состояния вообще, то придётся руководствоваться одной логикой.

Пример, чтобы расставить всё по своим местам

На макете отрисована фраза Войти. Если клик по ней должен открывать окно для ввода регистрационных данных на этой же странице, это кнопка. Если при нажатии должна открываться отдельная страница для входа, это ссылка.

Другие великие противостояния

• Как ставить пустые ссылки: 7 способов

• Абсолютные и относительные ссылки

• Когда использовать флексы, а когда гриды

• Что лучше табы или пробелы?

Ссылки ссылками, а промокод VESELO даст приятную скидку на любой профессиональный курс в HTML Academy. Например, на курс Анимации для фронтендеров можно записаться в любой момент, а пользы для карьеры будет целый вагон.

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

Наш сайт это не только витрина для информирования клиентов и продаж услуг и товаров для сегментов B2C, B2B и B2O, он ещё предназначен для обслуживания текущих клиентов: FAQ, чат, формы обратной связи, платежные формы и т.п.Он постоянно обновляется, и каждый раз после выпуска новой версии нужно проверять сотни страниц с богатым, динамичным UI на работоспособность в браузерах и адаптивность вёрстки.

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

Как всё начиналось

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

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

Итого, что нам требовалось:

• возможность сравнения всей страницы целиком, отдельных элементов, групп элементов;

• проверка на адаптивность (десктоп 1920px, планшет 768px, мобила 360px);

• поддержка минимум двух браузеров: Chrome и Firefox;

• игнорирование и скрытие элементов (групп элементов) при сравнениях;

• удобочитаемый отчет с подсветкой отличий.

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

Java основной язык программирования;
TestNG фреймворк автоматизации тестирования;
Maven сборщик;
Selenide обертка над Selenium, которая упрощает написание веб автотестов;
Selenoid GGR сервер-балансировщик для запуска изолированных браузеров в Docker контейнерах;
Allure фреймворк для создания отчётов автотестов и плагин ScreenDiff;
aShot библиотека для попиксельного сравнения изображений.

Благодаря балансировщику Selenoid GGR (Go Grid Router), в котором настроено распределение на несколько машин, мы имеем возможность поддержки нескольких браузеров (при необходимости: нескольких версий), плюс запуск тестов (изолированных браузеров) в параллель (~40 потоков).

В этой статье мы покажем как работает автотестирование по скриншотам будем акцентировать внимание на функционал aShot (кстати, спасибо ребятам из Яндекса за такие полезные инструменты как aShot и Allure) и на самом процессе.

Как это работает

Тесты условно разбиты на две группы:

• fullscreen страницы целиком (с прокручиванием);

• element(s) отдельный элемент (группа элементов)

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

Избавляемся от динамики

Динамика в основном проявляется в виде:

• каретки в полях ввода, которая мигает (может пропасть или появиться);

• CSS Transition и Animations;

• видео с автопроигрыванием и ряд других моментов.

Там, где есть возможность отключаем (инъекцией CSS):

Каретку делаем прозрачной (задаем значениецвета = transparent). Таким образом она всегда будет невидимой и не будет влиять на результат. CSS Transition обнуляем transitions-delay и transition-duration. CSS Animation обнуляем animation-delay, animation-duration и ставим состояние анимации в паузу, устанавливаяanimation-play-stateвpaused.

*, *::after, *::before {    caret-color: transparent !important;    transition-delay: 0s !important;     transition-duration: 0s !important;    animation-delay: 0s !important;     animation-duration: 0s !important;    animation-play-state: paused !important;    overflow: hidden; // Опционально скрываем полосу прокрутки}

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

Проверяем на адаптивность

Если с десктоп браузером всё понятно, с планшетом и мобилой встал вопрос, как проще эмулировать браузер. Было решено, что пока достаточно использовать фичу вебдрайвера mobileEmulation. Пример скрипта поднятия вебдрайвера Chrome с включением этой опции, в режиме планшета и выбором девайса = iPad:

@Override    public WebDriver createDriver(DesiredCapabilities capabilities) {WebDriverManager.chromedriver().setup();Map<String, String> mobileEmulation = new HashMap<>();mobileEmulation.put("deviceName", "iPad");ChromeOptions chromeOptions = new ChromeOptions();chromeOptions.setExperimentalOption("mobileEmulation", mobileEmulation);WebDriver driver = new ChromeDriver(chromeOptions);WebDriverRunner.setWebDriver(driver);return driver;    }

Снимаем скриншоты

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

screens / {browser} / {desktop | tablet | mobile} / {region} в зависимости от выбранного для запуска браузера, устройства (режима адаптивности) и регионов (некоторые компоненты могут быть регионозависимы, т.е. отображаться по-разному в зависимости от выбранного пользователем региона).

Название файла состоит обычно из:

• для fullscreen (страницы целиком) = {URL path} + опционально {query}, {ref};

• для отдельного элемента | групп элементов = {URL path} + {уникальный class | id | path} (тут на усмотрение кому как удобно, главное, чтобы можно было выделить уникальное значение)

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

Текущий скрин снимаем в процессе прогона на выбранном контуре, применяя также предварительно фильтры избавления от динамики и дополнительно указываем игнорируемые элементы (об этом ниже более подробно с примерами).

Пример снятия скриншота всей страницы (fullscreen):

Создаем объект Screenshot AShot, перед вызовом метода takeScreenshot() вызываем метод shootingStrategy(), в параметрах которого задаем правило съемки viewportPasting(300), т.е. снимать скриншот с прокручиванием, с таймаутом 300 мс. AShot по умолчанию использует jQuery для поиска координат, при его отсутствии, необходимо включить поиск координат с помощью WebDriver API предварительно вызвав метод coordsProvider(new WebDriverCoordsProvider()).

Screenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .takeScreenshot(getWebDriver());

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

Погуглив и проанализировав DPR (Device Pixel Ratio) значения страниц в разных режимах, стало понятно, что дело скорее всего в соотношении пикселей устройств, которые мы эмулируем. Запустив window.devicePixelRatio;в консоли браузера, можно найти его. Задали другой shootingStrategy, указав подходящий устройству DPR scaling в параметрах, и таким образом избавились от вышеуказанных проблем.
Для режима планшет (iPad) указали ShootingStrategies.viewportRetina(600,0,0,2f).
Для мобилы (Pixel 2XL) указали ShootingStrategies.viewportRetina(600,0,0,3.5f)

Пример снятия скриншота конкретного элемента (группы элементов):

При вызове метода takeScreenshot(), в параметрах, помимо текущего WebDriver, передаем еще элемент WebElement либо коллекцию элементов Collection <WebElement>, по которым мы хотим получить скриншот:

Collection<WebElement> elements = new ArrayList<>();   elements.add($x("//div[contains(@class,'rtk-offer-list')]")); // допуслуги и оборудование   elements.add($x("//div[@class='rtk-offer__legend']")); // блок ценыScreenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .takeScreenshot(getWebDriver(),elements);

Снятие скриншота c установкой игнорирований элемента(-ов) при сравнении:

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

Set<By> ignoredElements = new HashSet();ignoredElements.add(By.xpath(xpath);

и передаем при снятии актуального скриншота этот набор вызовом метода ignoredElements(final Set ignoredElements)

Screenshot actualScreenshot = new AShot()   .shootingStrategy(ShootingStrategies.viewportPasting(200))   .coordsProvider(new WebDriverCoordsProvider())   .ignoredElements(ignoredElements)   .takeScreenshot(getWebDriver());

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

expectedScreenshot.setIgnoredAreas(actualScreenshot.getIgnoredAreas());

Сравнение скриншотов

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

ImageDiff diff = new ImageDiffer().withDiffMarkupPolicy(new ImageMarkupPolicy().withDiffColor(Color.RED)).makeDiff(expectedScreenshot, actualScreenshot);    if(diff.getDiffSize()!=0){       Allure.label("testType", "screenshotDiff");       attachImg("expected", expectedScreenshot.getImage());       attachImg("actual", actualScreenshot.getImage());       attachImg("diff", diff.getMarkedImage());       attachImg("diff (прозрачность)", diff.getTransparentMarkedImage());       Assert.fail("Скрины отличаются");    }

Для удобства просмотра отличий используем плагин Allure ScreenDiff, который добавляет специальный блок в сценарий, внутри отчёта, с двумя режимами:

• Отображение отличий с подсветкой (Show diff);

• Отображение формы с режимом наложения (Overlay) с передвигаемым по горизонтали ползунком для удобного визуального сопоставления текущего и ожидаемого результата.

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

А в чём польза?

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

Пользователи мобильной версии версии сайта бренда долгое время вместо кнопки Узнайте больше видели Узнайте боль (спасибо ребятам из Альфа-банка, которые первыми это заметили). Это один из примеров, который вызывает больше улыбку чем неудобство, но бывают ситуации, которые не столь безобидны. На этом пока всё. Всем стабильных тестов! :)

Как и CSS Grid, Flex Box довольно сложен, потому что состоит из двух составляющих: контейнера и элементов внутри него.

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

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

CSS Flex или Flex Box

Flex это набор правил для автоматического растягивания нескольких столбцов и строк внутри родительского контейнера.

display:flex

В отличие от многих других свойств CSS, в Flex есть основной контейнер и вложенные в него элементы. Некоторые свойства CSS-Flex относятся только к контейнеру. А другие можно применить только к элементам внутри него.

Вы можете думать о flex-элементе как о родительском контейнере со свойством display: flex. Элемент, помещенный в контейнер, называется item. Каждый контейнер имеет границы начала(flex-start) и конца гибкости(flex-end), как показано на этой диаграмме.

Горизонтальная (main) и вертикальная (cross) оси

Хотя список элементов представлен линейно, необходимо обращать внимание на строки и столбцы. По этой причине Flex включает в себя координатные оси. Горизонтальная ось называется main-axis, а вертикальная cross-axis.

Чтобы управлять шириной содержимого контейнера и промежутками между элементами, которые растягиваются вдоль main-axis, необходимо использовать Justify-content. Для управления вертикальными изменениями элементов необходимо использовать align-items.

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

По умолчанию, элементы Flex равномерно распределяются внутри контейнера по горизонтальной оси. Мы рассмотрим различные свойства и значения.

Распределение строк и столбцов внутри родительского элемента определяется свойствами CSS Flex flex-direction, flex-wrap и некоторыми другими, которые будут продемонстрированы дальше.

Direction

Можно задать направление движения элементов (по умолчанию слева направо).

flex-direction: row-reverse изменяет направление движения списка элементов. По умолчанию стоит значение row, что означает движение слева направо.

Wrap

flex-wrap: wrap определяет перенос элементов на другую строку, когда в родительском контейнере заканчивается место.

Flow

flex-flow включает в себя flex-direction и flex-wrap, что позволяет определять их с помощью одного свойства.

Примеры:

• flex-flow: row wrap определяет значения flex-direction как row и flex-wrap как wrap.

• flex-flow:row wrap-reverse (перенос элементов вверх)

• flex-flow:row wrap (стандартный перенос элементов); justify-content: space-between (пробел между элементами);

• flex-flow: row-reverse wrap (направление движения справа налево со стандартным переносом сверху вниз)

• flex-flow: row-reverse wrap-reverse (направление движения справа налево и обратный перенос элементов);

• flex-flow: row wrap; justify-content: space-between; (стандартный перенос и направление; расстояние между элементами)

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

Когда мы меняем flex-direction на column, свойство flex-flow ведет себя точно так же, как и в предыдущих примерах. За исключением wrap-reverse, когда элементы переносятся снизу вверх.

justify-content

Я получил много просьб прояснить приведенный выше пример. Для этого я создал анимацию:

Надеюсь, эта CSS-анимация поможет лучше понять работу justify content.

Свойства следующие:flex-direction:row; justify-content: flex-start | flex-end | center | space-between | space-around | stretch | space-evenly. В этом примере мы используем только 3 элемента в строке.

Нет никаких ограничений на количество элементов, которые можно использовать в Flex. Эти диаграммы демонстрируют только поведение элементов, когда одно из перечисленных значений применяется к свойству justify-content .

Packing Flex Lines (согласно спецификации Flex)

Я не уверен, реализовано ли это в каком-либо браузере, но когда-то это было частью спецификации CSS-flex и, вероятно, стоит упомянуть об этом для полноты картины.

В спецификации Flex это называется Packing Flex Lines. По сути, это работает так же, как в примерах выше. Однако стоит обратить внимание, что интервал расположен между целыми группами элементов. Это полезно, когда вы хотите создать зазоры между группами.

align-items

align-items контролирует выравнивание элементов по горизонтали относительно родительского контейнера.

flex-basis

flex-basis работает аналогично другому свойству CSS: min-width. Оно увеличивает размер элемента в зависимости от содержимого. Если свойство не задействуется, то используется значение по умолчанию.

flex-grow

flex-grow применяется к конкретному элементу и масштабирует его относительно суммы размеров всех других элементов в той же строке, которые автоматически корректируются в соответствии с заданным значением свойства. В примере значение flex-grow для элементов было установлено на 1, 7 и (3 и 5) в последней строке.

flex-shrink

flex-shrink это противоположность flex-grow. В примере значение flex-shrink равно 7. При таком значении размер элемента равен 1/7 размера окружающих его элементов (размер которых автоматически скорректирован).

При работе с отдельными элементами можно использовать только одно свойство из трёх: flex-grow , flex-shrink или flex-base.

order

Используя свойство order , можно изменить естественный порядок элементов.

justify-items

И последнее, что нужно для тех, кто хочет использовать CSS Grid вместе с Flex Box... justify-items в CSS Grid похожи на justify-content в Flex. Свойства, описанные на приведенной выше диаграмме, не будут работать в Flex, но в значительной степени эквивалентны сетке для выравнивания содержимого ячеек.

Опыт веб-студии ITSOFT

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

При использовании Flex нужно учитывать, что:

• Flex-элементы по умолчанию ужимаются под свое содержимое; Это может пригодиться, когда есть блоки, размер которых изначально неизвестен и зависит от количества контента.

  Примеры: пункты меню в https://ketoplus.ru/

• Внешние отступы flex-элементов не схлопываются и не выпадают, в отличие от блочной модели.

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

  Пример: блоки в http://velpharm.ru/about/veltrade/

• Flex-элементы умеют перераспределять свободное пространство вокруг себя, таким образом меняя свои размеры;

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

  Пример: главная страница http://oflomil.ru/

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

  Бывают макеты страниц, в которых порядок следования элементов отличается на мобильной и десктопной версиях. Flex справится с задачей.

  Пример: разный порядок следования логотипа и навигации в шапке в мобильной и десктопной версиях (http://elmucin.ru/).

• Flex-элементу можно задать не только горизонтальные автоматические отступы, но и вертикальные; к тому же есть специальные свойства, с помощью которых очень просто выравнивать элементы внутри флекс-контейнера по горизонтали или вертикали.

  Пример: кнопка всегда находится в нижней части карточки статьи (https://rabiet.ru/experts/), блок продукция (https://stomatofit.ru/#products).

• Flex-элементы могут переноситься на следующую строку, если указано соответствующее свойство.

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

  Пример: каталог Велфарм (http://velpharm.ru/catalog/), блок Где купить (http://valosemid/#partners, https://gopantomid.ru/)

Стоит отметить, что Flexbox поддерживается в Internet Explorer 10-11, хоть и с некоторыми оговорками.

Некоторые интересные фишки Flex мы реализовали на сайте oflomil.ru. На разводящей странице есть 3 столбца на всю высоту видимой области экрана. На мобильном они трансформируются в 3 строки, каждая из которых равномерно занимает место в видимой части экрана. На продуктовых страницах без единого скрипта реализована бегущая строка. Текстовые элементы расположены в ряд благодаря inline-flex. Все свободное пространство в ряду распределено между этими элементами равномерно. Наш собственный сайт также свёрстан с использованием Flex.

Из недостатков можно отметить то, что Flex не хватает при верстке писем. Не во всех почтовых клиентах он работает корректно.

В скором времени большую распространённость получит технология Grid. Однако Grid не замена Flexbox. Флексы в связке с гридами помогут решать задачи, которые раньше были сложными или вовсе невозможными. К примеру, Masonry-раскладка одна из тех вещей, которую нельзя полноценно реализовать на данный момент. После появления возможностей спецификации Grid Layout 3 уровня в браузерах, реализация такой раскладки станет возможной и к тому же простой.

Источники: оригинал руководства с картинками

Дата-центр ITSOFT размещение и аренда серверов и стоек в двух дата-центрах в Москве. За последние годы UPTIME 100%. Размещение GPU-ферм и ASIC-майнеров, аренда GPU-серверов, лицензии связи, SSL-сертификаты, администрирование серверов и поддержка сайтов.

Блокировка изображений одна из самых серьезных проблем, с которой сталкиваются маркетологи, когда проводят email-кампании. Обычно причина кроется в настройках по умолчанию или личных предпочтениях получателя. В результате у большого количества подписчиков изображения блокируются автоматически и письма не доносят до человека основную мысль сразу же, а то и вовсе выглядят испорченными. Поэтому важно оптимизировать рассылки для режима отключенных изображений. Как это сделать? Сервис DashaMail делится лайфхаками.

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

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

Настройки по умолчанию в популярных почтовых службах

Стандартных настроек для блокировки изображений нет. Ниже мы схематично описываем их для самых популярных почтовых клиентов для ПК, веб-служб и мобильных устройств. Мы добавили в сравнение поддержку ALT-текстов (замещающих или альтернативных текстов) и стилизованных ALT-текстов (стилизованных замещающих текстов). Эти атрибуты HTML-разметки необходимы. Когда изображения в письме отключены или недоступны, заполненный альтернативный текст часто показывается вместо изображения.

Настройки десктопных программ

Отметим несколько нюансов почтовых служб Outlook. Outlook 2000, 2003, 2007, 2010 и 2013 добавляют к альтернативному тексту длинное сообщение от службы безопасности. Из-за этого он становится практически бесполезным, ведь он появляется только в конце предупреждения:

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

Веб-версии почтовиков

Когда речь идет о блокировке изображений и поддержке стилизованного альтернативного текста, операторы веб-почты показывают неоднозначный результат.

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

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

• в электронных письмах с подозрительных адресов он не показывает картинки, но отображает альтернативный текст;

• для пользователей, у которых установлены более строгие настройки блокировки содержимого, Outlook.com использует серые поля.

Gmail не блокирует изображения с декабря 2013 года. Казалось бы, маркетологи и дизайнеры должны быть в восторге письма будут отображаться как нужно, а открытое отслеживание станет более надежным. Однако и это изменение не прошло гладко. Нередко изображения повреждаются или искажаются из-за проблем с кэшированием.

Мобильные почтовые клиенты

Хорошие новости для дизайнеров: у мобильных клиентов почтовых служб отличная поддержка альтернативного и альтернативного стилизованного текста!

Но и тут есть свои нюансы. Например, в Windows Phone вообще не отображается альтернативный текст, а вместо этого показывается сообщение с предложением загрузить изображения:

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

Outlook.com для Android и iPhone по умолчанию блокирует изображения по той же схеме что и Outlook для ПК.

И, наконец, Yahoo! Для пользователей, которые читают имейл-сообщения в браузере Android, используется уникальная тактика блокировки изображений. Yahoo! блокирует все изображения, цвета фона, ссылки и так далее и отображает только текст из HTML-версии. Да-да, это не опечатка только текст из HTML, а не живой текст!

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

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

Как бороться с блокировкой изображений?

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

Альтернативный текст + стилизованный альтернативный текст

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

Чтобы добавить альтернативный текст, нужно прописать атрибут к тегу изображения:

<img alt="insert alt text here" src="image.jpg" width="250" height="250" />

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

<img alt="" src="image.jpg" width="250" height="250" />

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

<img style="font-size: 15px; color: #ffffff; font-style: italic; font-weight: bold; height: 250px; width: 250px;" alt="insert alt text here" src="image.jpg" width="250" height="250" />

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

Неубиваемые кнопки

Хотя тексты и дизайн вашей кампании могут иметь большое значение при взаимодействии подписчиков с письмами, обычно самая важная часть призыв к действию (Call to Action, он же CTA). CTA должны быть доступны для просмотра, даже если картинки отключены. Кнопки на основе изображений не обрабатываются они блокируются. Пользователи не выполняют действия, а конверсия не повышается. Да, есть вариант с текстовыми ссылками, но не лучше ли немного повеселиться и попробовать сохранить стиль бренда, используя неубиваемые кнопки?

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

<table border="0" cellspacing="0" cellpadding="0" width="80%">

<tr>

<td bgcolor="#0b534a" style="padding: 12px 18px 12px 18px; -webkit-border-radius:3px; border-radius:3px" align="center"><a href="http://personeltest.ru/aways/litmus.com" target="_blank" style="font-size: 16px; font-family: Helvetica, Arial, sans-serif; font-weight: normal; color: #ffffff; text-decoration: none;">Visit Litmus</a></td>

</tr>

</table>

Вот пример одной из кампаний по электронной почте, в которой использовался этот метод.

Баланс изображений и текста

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

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

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

• доступность;

• отсутствие проблем со спамом из-за соотношения HTML кода и фактического текста;

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

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

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

Цветной фон

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

Хотя есть несколько способов кодирования цвета фона, рекомендуется использовать атрибут HTML bgcolor (Background Color) с 6-значным HEX-кодом.

Мозаика и пиксельная графика

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

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

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

Выводы

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