В этом посте речь пойдет о тех ошибках, которые допускают дизайнеры в макетах, предназначенных для вёрстки. Рассмотрим наиболее часто встречающиеся проблемы, с которыми сталкивается верстальщик при работе с psd-макетами. Если Вы дизайнер, и Вам часто приходится передавать свой дизайн в руки коллег по цеху, то, возможно, этот пост поможет Вам лучше понять, какие неприятности испытывают верстальщики, и избежать некоторых ошибок в будущем, за что коллеги будут Вам очень благодарны.
Прежде всего отмечу, что здесь я рассмотрю именно технические аспекты подготовки макетов и ни в коем случае не буду учить дизайнеров делать их работу. Почвой для написания поста стал трёхлетний опыт работы в веб-студии.
1. Цветовой профиль
Проблема с цветовыми профилями чаще всего возникает из-за отсутствия понимания у дизайнера, что же такое цветовой профиль и как его выбирать. Наиболее часто встречаются профили Adobe RGB (1998) и sRGB IEC61966-2.1 (далее просто sRGB), о которых можно почитать, например, здесь.
Для веба, как правило, используется профиль sRGB — он является профилем по умолчанию, например, в ОС Windows. Это значит, что мы видим изображение на экране в цветах, определенных стандартом sRGB IEC61966-2.1. Разница между Adode RGB и sRGB заключается в ширине цветового спектра.
В чем же проблема? Дизайнер, создавая в Photoshop новый проект, не указывает цветовой профиль, и, как следствие, Photoshop оставляет значение по умолчанию — Adode RGB. В свою очередь, верстальщик, получив макет, нарезает его, и в какой-то момент замечает, что цвета в макете и на свёрстанной странице отличаются на несколько тонов.
Что же произошло? Еще на стадии сохранения нарезанных изображений, верстальщик воспользовался замечательной функцией Save for Web & Devices, которая по умолчанию выполняет преобразование изображения в sRGB. В итоге мы видим одни цвета в рабочем пространстве Photoshop и совсем другие на готовом сайте.
Для одного заказчика небольшая разница в цвете фона на сайте может быть некритична, а для другого — это повод для скандала. Думаю, найдутся люди, которым приходилось полностью переделывать дизайн или вёрстку из-за такого упущения, как забытый цветовой профиль.
Решение проблемы — всегда при начале работы убеждаться, что установлен правильный профиль.
2. Направляющие
Установка направляющих — казалось бы, простое дело. Но и тут возникают проблемы. Невнимательный верстальщик, используя установленные дизайнером направляющие, нарезает изображения и получает на выходе что-то подобное:
Почему так получилось? При близком рассмотрении видно, что направляющие сами не привязываются к границам пикселей, соответственно, когда дизайнер «на глаз» ставит направляющую, то, скорее всего, она не попадёт ровно между пикселями
Выделение, наоборот, привязывается к пикселям:
Даже если верстальщик был внимателен и заметил это, то все равно встаёт вопрос: куда всё таки дизайнер хотел поставить направляющую — левее или правее?
Простой совет, как избежать этой проблемы: сначала выполните выделение, а затем установите направляющую на линию выделения.
3. Группы, слои, маски
Верстальщику необходимо отдавать именно подготовленный к вёрстке макет, а не рабочий проект весом под 100 Мб.
Что значит «подготовленный к вёрстке макет»?
- Группы и слои проименованы: основные элементы дизайна желательно именовать в соответствии с их назначением (лучше всего латиницей)
- Если есть сгруппированные слои, то группировка выполнена в соответствии с логической структурой страницы:
шапка, контент, баннер, кнопка, список и т. д., и вложенность не превышает разумных пределов, а лучше вообще избегать вложенности групп. - Скрытые, но не играющие никакой роли в дизайне слои, должны быть удалены
- Обрезка фотографий (скругление углов и т.п.) должны производиться с сохранением исходных изображений — лучше всего делать это с помощью масок
- Размер холста должен соответствовать максимально возможной ширине/высоте дизайна
4. Цвета
Вернёмся к проблемам с цветами. Для элементов, имеющих по замыслу одинаковый цвет границы/заливки/шрифта, необходимо указывать, как нетрудно догадаться, одинаковый цвет в параметрах наложения, свойствах символа и т.д.
Что за ерунда? И так ведь понятно, что цвет одинаковый.
Но не тогда, когда, например, цвет одной надписи отличается от другой всего на половину тона. Придирчивый заказчик может запросто испортить верстальщику, выбравшему неверный вариант их двух возможных, настроение до конца дня, если заметит эту разницу. А дизайнер по факту будет не при чём.
Совет дизайнерам: используйте палитры или каким-либо образом заготовленные наборы цветов, чтобы избежать разногласий.
5. Трансформации, фигуры
Прошли времена вёрстки скругленных уголков картинками. Каждый уважающий себя браузер умеет скруглять углы с помощью CSS-свойства border-radius, чем и пользуются верстальщики.
Но порой встречаются дизайн-макеты, в которых скругления «не совсем округлые». Что это значит? Просто дизайнер в какой-то момент изменил размер своего скругленного прямоугольника с помощью функции Transform, изменив его пропорции. В результате углы оказались вовсе не скругленными, а «овальными».
Само собой, верстальщик не станет из-за этого нарезать блок картинками. Но это говорит о ненадлежащем отношении дизайнера к работе.
Решив вопрос скгругления углов, верстальщик вновь столкнулся с проблемой:
Когда речь идет о pixel-perfect вёрстке, подобные неточности в дизайне могут доставить немало хлопот верстальщику. В данном случае левый край блока имеет нечёткую границу, а из-за этого невозможно точно определить ширину блока.
Для предотвращения нечеткости границ фигур в Photoshop 13 есть специальная опция «выровнять края».
6. Единицы измерения, символы, абзацы
Чаще всего в вебе нам приходится иметь дело с пикселями. В большинстве случаев нет причин использовать какие-либо другие единицы измерения, такие как пункты, дюймы и т. д. Желательно, чтобы дизайнер устанавливал в настройках Photoshop именно пиксели в качестве основной единицы измерения.
Как и в случае с цветами, для дизайна текстовых блоков дизайнеру следует придерживаться строго фиксированных значений размеров. Для каждого абзаца необходимо однозначно задавать кегль и интерлиньяж.
Если Вы изменили размер текста с помощью Transform, то после этого кегль или другие свойства символа могут принять дробное значение (например, 14.5 px). При подготовке макета к вёрстке обязательно нужно привести все размеры к целым значениям. В противном случае перед верстальщиком вновь встанет дилемма: 14 или 15 пикселей?
Что касается выключки строк (выравнивания), то дизайнеру следует помнить: браузеры полноценно поддерживают лишь 3 варианта: по левому краю, по правому краю или по центру. Выключка по формату в браузере зачастую сильно отличается от того, что мы видим в Photoshop.
7. Параметры наложения, стили слоя
Каждому дизайнеру следует хоть немного знать о том, какие возможности имеют современные браузеры. Эти знания могут значительно облегчить жизнь как самому дизайнеру, так и верстальщику.
Посмотрим, какие стили слоя в Photoshop имеют полную или частичную возможность реализации с помощью CSS (без использования картинок):
- Тени и свечения (внутренние и внешние)
text-shadow— тень для текста
box-shadow— тень для блока - Обводка
border— обводка линией
box-shadow— возможна обводка однопиксельной тенью
outline— строго прямоугольная обводка - Заливка
background-color— заливка цветом (возможно полупрозрачным)
background-image— заливка узором/картинкой
background-image: linear-gradient()— линейный градиент
background-image: radial-gradient()— радиальный градиент - Прозрачность
opacity— прозрачность элемента целиком
[color:] rgba(r,g,b,a)— прозрачность rgb-цвета, где a — степень непрозрачности от 0 до 1
[color:] hsla(h,s,l,a)— прозрачность hsl-цвета, где a — степень непрозрачности от 0 до 1
О поддержке браузерами того или иного свойства можно узнать здесь.
Стоит помнить: браузеры не поддерживают ни один из режимов наложения, такие как Overlay, Screen и др. Это необходимо обязательно учитывать и при необходимости обходиться нормальным режимом наложения в сочетании с прозрачностью и градиентами.
Подводя итог
В данной статье были рассмотрены некоторые нюансы подготовки дизайнером psd-макета для верстальщика. Надеюсь, кто-нибудь почерпнёт из нее для себя что-либо новое или просто найдет в ней повод напомнить своим дизайнерам о несложных правилах, придерживаясь которых они прослывут педантами в хорошем смысле этого слова, а их работы будут поражать аккуратностью исполнения.
Выравнивание правого края
Текст с ровным правым краем выглядит хорошо. Но выровнять его непросто. Слова имеют разную длину, поэтому сделать правый край ровным можно либо вручную с помощью переносов, либо автоматически, выровняв его по ширине. Ни один из этих способов не подойдет для верстки веб-страницы.
Проблема ручного выравнивания в размере мониторов: на разных устройствах текст будет отображаться по-разному, и все переносы «поедут». Выравнивание текста по ширине тоже не решает проблему. Этот способ выравнивает правый край за счет разной длины пробелов между словами. В итоге текст выглядит уродливо, усложняет чтение и выдает некачественную верстку.
В блоге медиахаба «Rockin’Robin» делают правый край текста ровным с помощью автоматического выравнивания по ширине. Из-за этого между словами образуются дыры:
Если отключить выравнивание по ширине, то пробелы между словами будут одинаковыми, и станет заметно лучше:
Совет: Выравнивайте текст по левому краю. Рваный правый край выглядит лучше, чем разная длина пробелов между словами.
Продвинем ваш бизнес
В Google и «Яндексе», соцсетях, рассылках, на видеоплатформах, у блогеров
Подробнее
Цвет текста не контрастен к фону
Чем меньше соотношение цвета текста и фона, тем сложнее его читать. Если мы напишем белым цветом на белом фоне, то соотношение цветов будет 1:1. Такой текст невозможно прочитать. Светло-серый текст на белом фоне будет иметь соотношение 1:6.
Текст различим, но читабельность все еще низкая. Чтобы текст хорошо читался, соотношение цветов должно быть 5:1 или больше.
Чтобы прочитать эти четыре слова, напрягаться не нужно. Но если в таком же соотношении набрать целую статью, читабельность ухудшится:
Поэтому для статей нужно выбирать более контрастный цвет шрифта. Проверить соотношение контрастности цвета шрифта и фона можно с помощью специального инструмента. Самая большая контрастность между черным и белым. Поэтому черный текст на белом фоне — самый читабельный.
Совет: Пишите черным по белому.
Незаметный подзаголовок
Подзаголовки — это один из способов привлечь внимание читателя. Когда человек открывает статью, первым делом он сканирует текст и только потом принимает решение: читать его или нет. При сканировании взгляд читателя цепляется за подзаголовки, иллюстрации, врезки. Если подзаголовок оформлен плохо, то при сканировании читатель не зацепится за него, не поймет о чем статья и уйдет. Поэтому подзаголовки должны быть заметные. Выделить подзаголовок можно жирным стилем, увеличенным кеглем и цветом.
В блоге «Madcats» подзаголовки выделяют только крупным кеглем, жирность и цвет не используют. Поэтому при сканировании мимо них легко проскочить:
Внимание к подзаголовкам привлекают только красные линии, но они не информативны: читатель их заметит, но подзаголовок может не прочитать. Если поменять цвет подзаголовков и добавить жирность, то мимо них уже не проскочишь:
Совет: Подзаголовки должны выделяться.
Неправильное соотношение верхнего и нижнего отступа в подзаголовке
Еще одна ошибка в оформлении подзаголовков — неправильная величина отступов. Величина отступа сверху подзаголовка должна быть больше, чем величина отступа снизу. Так мы визуально показываем, что подзаголовок относится к нижнему абзацу, а не к верхнему.
В блоге «GetGoodRank» подзаголовки оформлены невнятно, поэтому их можно спутать с врезками.
Сделаем отступ сверху больше, чем снизу, и иерархия станет понятной:
Совет: у читателя не должно возникать сомнений, к какому абзацу относится подзаголовок.
Сложная структура
Подзаголовки создают структуру статьи. Хорошая структура помогает читателю ориентироваться в статье. Но если структура многоуровневая, то читатель может запутаться. Принцип многоуровневой структуры — каждый следующий подзаголовок вкладывается в предыдущий и создает новый уровень вложенности.
Если подзаголовок включает в себя еще один подзаголовок — структура получается с трехуровневой вложенностью:
- Заголовок (Первый уровень)
- Подзаголовок (Второй уровень)
- Подзаголовок (Третий уровень)
- Подзаголовок (Третий уровень)
- Подзаголовок (Второй уровень)
- Подзаголовок (Второй уровень)
Такая структура воспринимается нормально, но если добавить еще один уровень, то читатель может потеряться в статье:
- Заголовок (Первый уровень)
- Подзаголовок (Второй уровень)
- Подзаголовок (Третий уровень)
- Подзаголовок (Четвертый уровень)
- Подзаголовок (Четвертый уровень)
- Подзаголовок (Третий уровень)
- Подзаголовок (Второй уровень)
- Подзаголовок (Второй уровень)
Многоуровневая структура хорошо подходит для справочников: с ее помощью легко находить информацию. Но читать статью с такой структурой сложно. Читателю приходится запоминать, в каком разделе он находится, что приводит к лишнему напряжению и путанице. Поэтому в статьях лучше использовать простую структуру:
- Заголовок
- Подзаголовок
- Подзаголовок
- Подзаголовок
Совет: Делайте структуру статьи проще. Многоуровневую структуру оставьте для тех, кто верстает справочники.
Неподходящий размер интерлиньяжа
Интерлиньяж — это расстояние между строками. Размер интерлиньяжа зависит от размера кегля и от ширины строки. Чем шире строка и крупнее кегль, тем больше должен быть интерлиньяж. Чтобы строки не получились слишком слипшимися, нужно ориентироваться на расстояние между словами: оно должно быть заметно меньше, чем интерлиньяж.
Текст стал читабельнее. Но нужно чувствовать меру:
Слишком большой интерлиньяж мешает чтению не меньше, чем маленький:
Совет: Подбирая размер интерлиньяжа, ориентируйтесь на размер кегля, ширину текстового поля и расстояние между словами.
Слишком широкое текстовое поле
От размера текстового поля зависит скорость и удобство чтения. Слишком длинное текстовое поле затрудняет чтение: дочитав одну строку, сложно перескочить на следующую. Поэтому читатель может перепрыгнуть не на ту строку.
Сделаем наборную строку чуть уже, и читать станет легче:
Чтобы определить подходящую длину строки, можно использовать формулу Роберта Брингхарста: размер кегля умножить на 30.
Мелкий размер кегля
Мелкий размер кегля — это неуважение к читателю. Размер кегля должен быть таким, чтобы его можно было читать без усилий.
Увеличим кегль с 12 до 16 px, и текст можно спокойно читать:
Совет: Основной текст на веб-странице лучше не набирать кеглем меньше 14 px.
Отсутствие абзацев
Абзацы — это один из показателей хорошей структуры текста. Абзацы делают текст читабельнее и привлекательнее. Длинные полотна текста не хочется читать, кажется, что там написано о чем-то сложном.
Разделим это полотно на абзацы:
Совет: Делите текст на абзацы размером не более 8 строк.
Подведем итог
- Выравнивайте текст по левому краю;
- Подбирайте цвет шрифта, который наиболее контрастен к фону;
- Выделяйте подзаголовки четче;
- Расстояние сверху подзаголовка должно быть больше, чем снизу;
- Не используйте сложную структуру в статье;
- Межстрочный интервал должен быть заметно больше расстояния между словами;
- Текстовое поле не должно быть слишком широким;
- Набирать статью кеглем меньше 14 px — неуважение к читателю;
- Делите текст на абзацы.
Веб-дизайн призван решать бизнес-задачи. При этом всегда есть определённые ограничения, которые следует учитывать: по загружаемому контенту, его обновлению и отображению на разных устройствах, по работе с базами данных и внешними системами и не только.
Однако не все дизайнеры думают о том, как их макеты будут функционировать на сайте или в приложении. Руководитель студии дизайна и разработки сайтов и сервисов Method Zero Антон Шакиров рассказывает о самых распространённых ошибках, которые последние пару лет замечал на дизайн-площадках и сайтах, и делится принципами, которые помогут их избежать.
Дизайнеры, как правило, создают макеты для трёх разрешений экранов:
- под компьютеры и ноутбуки: ширина макетов — 1 920, 1 440 или 1 360 пикселей, обычно для сайтов берут только одно из этих разрешений;
- под планшеты: ширина макетов — 767 пикселей;
- под смартфоны: ширина макетов — 375 пикселей.
Дизайн хорошо смотрится, первый экран красиво передаёт нужную информацию и вовлекает скроллить дальше. При этом часто забывают, что на реальных устройствах первый экран будет меньше по высоте из-за окна браузера, поля с адресом сайта и панели закладок. Кнопка с призывом к действию и вовсе может уехать за пределы экрана. Всё это ломает дизайн.
Нужно помнить и про использование графики. В примере ниже фоновая иллюстрация растягивается по ширине сайта, при этом нижняя часть круга обрезается и выходит за пределы первого экрана, где её изначально располагал дизайнер:
Исправить этот недочёт можно так: увеличить отступы справа и слева от картинки до краёв экрана или поместить круги в отдельные элементы и работать с ними уже там.
Случается и обратная ситуация, когда специалист не адаптирует дизайн под ультраширокие мониторы 3 440 x 1 440 и не объясняет разработчикам, как должен вести себя сайт при изменении ширины экрана. Решить этот вопрос поможет:
- Резиновая вёрстка, когда весь сайт пропорционально растягивается по ширине экрана. Но следует учитывать, что контент может слишком укрупниться и будет видна только треть того, что должно было помещаться в рамках одного экрана.
- Добавление полей справа и слева. Здесь стоит помнить про закреплённые на экране элементы и про фоновые видео и изображения, которые обрезаются по краям экрана на стандартных экранах.
Пример резиновой вёрстки: контент остаётся в рамках одного экрана, благодаря правильному позиционированию всех элементов на странице ↓
В примере ниже разные части дизайна закреплены с левой и с правой стороны. Если открыть этот сайт на ультрашироком мониторе, посередине возникает дыра:
Для макетов для iPhone. При дизайне кнопок, закреплённых снизу на мобильном устройстве, часто забывают про индикатор «Домой» (Home indicator) — чёрную полоску снизу, область под которой не кликабельна. Кнопки следует приподнимать выше этого индикатора или ставить больше внутренних отступов под ней, но не прижимать её к низу. Это также немного повлияет на высоту элементов в рамках одного экрана сайта или приложения.
Не стоит забывать готовить и передавать разработчикам все видео и изображения в большем размере для сохранения их качества на мониторах 4K и 5K. Если изображение на весь экран, готовим его под всю ширину монитора, например, 4K — 3 440 px. Если на пол-экрана — 1 720 соответственно. Это важно, потому что часто разработчики экспортируют картинки напрямую из макетов, где эти картинки делают в небольшом разрешении. Экспорт изображений в увеличенных размерах не поможет в этом случае. Исключение составляют только векторные изображения в svg-формате, которые могут бесконечно увеличиваться и уменьшаться без потери качества.
Можно не рисовать отдельно макеты под планшет, если дизайнер делает проект, который:
- нужно оперативно запустить;
- не содержит сложных таблиц и сеток с переносами контента на следующие строки или с его скрытием на некоторых разрешениях экранов.
Согласно данным SimilarWeb и по личному опыту, на планшеты в среднем приходится 1–2% всего трафика, поэтому нецелесообразно тратить четверть проектного времени на эти макеты. Правда, если есть нестандартный блок со сложной сеткой, можно отдельно нарисовать планшетную версию только этой части. В остальных случаях опытные разработчики сами адаптируют десктопную версию макета под планшет.
Под динамическими элементами страниц подразумеваю всё, что может менять своё состояние — вид, содержание — в зависимости от положения курсора мыши, факта нажатия или перетаскивания элементов, фокуса, времени, скролла страниц, состояния каких-либо данных на странице.
На этапе дизайна динамических элементов нужно представлять, объяснять и рисовать, как этот элемент будет вести себя дальше или как он будет реагировать на определённые события.
Чаще всего забывают нарисовать и продумать состояния ховеров, когда на элемент наводится курсор, состояния нажатия или перетаскивания, состояния фокуса у кнопок, ссылок, форм, кликабельных элементов. Все эти состояния помогают пользователям понять, что на этот элемент можно нажимать, что в фокусе этот объект или что в поле есть ошибки.
При работе с формами — помимо состояний ошибок и невалидности полей — стоит помнить о сообщениях об успешной отправке формы. Так пользователь поймёт, что всё хорошо и его данные отправлены.
Некоторые элементы могут быть динамичными сами по себе. Например, если на сайте есть таймер обратного отсчёта, секундомер, экраны загрузки сайта, сообщения о загрузке данных. Нужно не только нарисовать то, как эти элементы выглядят, но и что с ними происходит в процессе и что будет после завершения действия.
Например, если говорить про таймер обратного отсчёта, нужно учитывать изменение цифр и изменение ширины всего текста из-за разной ширины отдельных цифр — если это не моноширинный шрифт, где каждый символ всегда занимает одинаковую ширину, что позволяет ориентироваться только на количество символов. Для этого делаем дизайн других состояний или описываем для разработчиков, как оно должно изменяться. А также готовим макеты или анимации того, что будет отображаться по истечении срока.
Если на сайте будут размещаться вакансии, новости, события, команды, магазины и другие данные, которые будут подгружаться из внешних систем и активно обновляться, следует заранее узнать у заказчика:
- как эти данные хранятся,
- какая есть или будет информация,
- как и кем данные будут актуализироваться,
- какие сложности могут возникнуть.
Это позволит определить полный набор данных для работы — или понять новые ограничения по дизайну и вёрстке.
Например, при проектировании HR-портала компании мы не можем вслепую задизайнить страницу поиска вакансий и каждую вакансию отдельно. Сперва нам надо узнать, какая информация по вакансиям будет доступна. Так, если в вакансиях нет информации о метро, мы и не должны рисовать это в макетах. Если в поле «Регион» хотим разделить Москву и Московскую область, узнаём у клиента, есть ли такая информация в принципе, а у разработчиков — возможно ли так сделать с технической точки зрения.
Нужно выяснить обязательность полей или целых разделов. Если мы делаем дизайн вакансий, может ли поле с графиком работы или со станцией метро полностью отсутствовать? Если делаем разделы со статьями, может ли какой-то раздел оказаться пустым? Может ли не быть ближайших событий? Может ли клиент удалить все новости?
С помощью таких вопросов дизайнер выявляет дополнительный набор состояний, который нужно задизайнить и передать разработчикам.
Другая ситуация — при наличии данных они могут не успеть подгрузиться с сервера при обращении к соответствующей странице. Если дизайнер знает, что эти данные будут грузиться извне, то лучше заранее предусмотреть сообщения о том, что всё в порядке и контент загружается.
Стоит помнить и про ограничения на контент, которые стоит задать для отдельных полей или частей контента. Ограничение может быть на длину текста, количество элементов в списке, количество фотографий.
Например, в слайдере с отзывами один из отзывов может быть сильно больше других. Это приведёт к тому, что под небольшими отзывами снизу будут дырки, так как нижестоящий контент отодвинется отзывом с самым длинным текстом:
Лучше заранее продумать в дизайне варианты поведения при таких сценариях или обговорить с клиентом и разработчиками введение ограничений на количество символов в каждом отзыве.
- Получите опыт 4 ведущих дизайн-студий и создадите 7 проектов для своего портфолио
- Научитесь создавать сайты под ключ, оформлять дизайн-проекты и презентовать их заказчику
- Сможете искать работу и проходить собеседования уже в середине обучения
Некоторые части сайта подлежат частым правкам: портфолио с кейсами, баннер с призывом к действию, блок с информацией о следующем событии, стоимость товаров или услуг и другое.
На этапе дизайна нужно сразу принимать в расчёт ограничения клиента по времени и деньгам, которые он готов тратить на обновления сайта.
Например, на первый экран сайта добавили баннер со следующим событием. В портфолио разместили профессионально отрисованные обложки работ, а на странице каждой модели часов — 3D-модель. Но сможет ли клиент самостоятельно выпускать аналогичный контент или будет ли он располагать дополнительными ресурсами на повторное привлечение дизайнеров под эти задачи?
Лучше сразу обсудить с заказчиком дизайн-решения и дальнейшее обновление контента. Показать, что нужно будет делать для добавления нового контента, какие есть условия для графики и фотографий.
Дизайнер должен быть уверен, что клиент сможет получить фотографии в заложенной стилистике под разные материалы или сделать предварительную постобработку и цветокоррекцию фотографий.
Дизайнеры знают про наличие в HTML заголовков H1–H6 и используют их при наименовании стилей. Однако при создании новых наборов стилей под мобильную версию сайта из-за удобства в дизайне и не знания того, что это делать нельзя, могут менять тип заголовка и стиля на элементах относительно десктопной версии. Был заголовок H1, а в мобильной версии у того же элемента стал H2. Был дополнительный стиль small text — стал просто text.
Если дизайнер создаёт с помощью HTML-тегов элемент H1, то он и должен оставаться H1 в мобильной версии. Иначе при разработке придётся делать дублирование всего элемента и создавать костыли с помощью CSS-классов — рабочее, но некрасивое и неэффективное решение.
Если нужно, чтобы какой-то элемент был по стилю таким же, как и элемент с другим стилем, стоит их сделать одинаковыми на определённых разрешениях экранов. Но сам элемент должен оставаться с таким же типом класса, как и на макетах под другие разрешения экранов.
Один и тот же элемент не должен менять свой заголовок между различными разрешениями экранов. Если в десктопной версии (верхнее изображение) заголовок соответствует стилю H4, то и в мобильной версии этот заголовок должен соответствовать стилю H4, даже если он эквивалентен мобильному H3
В этом вопросе дизайнерам и разработчикам сильно помогает создание UI Kit, где как минимум будут указаны все стили шрифтов, цветов, состояния элементов. Это позволяет проверить правильность указания всех стилей элементам и неизменность всего набора стилей между разными разрешениями экранов.
Здесь речь идёт скорее про уменьшение вероятных ошибок на готовом сайте и про сильную помощь разработчикам и ускорение их работы, а не про прямую ошибку дизайнеров. Но иногда это и про недостаточный объём того, что нужно сделать специалисту.
Все дизайнеры знают про favicon — маленькую картинку, которая отображается на вкладке сайта в браузере. Но не все создают и передают разработчикам webclip — картинку 256 x 256, которая видна в панели закладок Safari, — и opengraph-изображения для сайта и для отдельных страниц — изображение с рекомендуемым разрешением 1 200 x 630, которое видим при вставке в соцсетях ссылки на сайт.
Если фоновые изображения и другие элементы всегда зарезаются краями экрана или блоками в одном и том же месте, стоит сразу кадрировать эти изображения в макете. Часто дизайнеры отодвигают фоновую картинку за края экрана и включают у элементов обрезание контента за пределами макета страницы. Но когда разработчики будут скачивать такую картинку для экспорта на сайт, она выгрузится целиком. Так изображение попадёт на сайт в большем, чем нужно, размере, что будет замедлять загрузку и добавит разработчикам хлопот с выравниваниями.
Ещё одна частая ошибка — делать разные иконки в разных по размеру фреймах. Часто можно заверстать и так, но для этого разработчикам нужно под каждую иконку задавать свойства размеров, отступов. Если потребуется заменить иконку на другую, придётся менять размеры и отступы. Это приносит много проблем разработчикам и тормозит разработку.
Все иконки в дизайне должны быть сделаны внутри одинаковых по размеру областей — фреймов, внутри которых они уже выравниваются и масштабируются как нужно. Таким образом, все иконки вне зависимости от их реального размера будут занимать одинаковые области этих самых фреймов.
Иконки должны располагаться внутри одинаковых квадратных или прямоугольных областей, внутри которых они уже индивидуально выравниваются и масштабируются.
Вот примеры правильной работы с иконками:
На этапе разработки показывать все идеи и макеты разработчикам. Они скажут о возможных проблемах, которые всплывут при разработке.
Всегда просить обратную связь от разработчиков: что им не хватило при передаче дизайна. Через несколько проектов сформируется понимание, на что обращать внимание и что ещё нужно учесть и подготовить в дизайне.
Начать самостоятельно разрабатывать несложные сайты на технологиях no-code. Рекомендую Tilda, Readymag и WebFlow. После нескольких собранных сайтов станет ясно, с чем возникают сложности, где и что работает не так.
Самостоятельно проводить тестирование сайтов на различных устройствах. Такие сервисы, как BrowserStack, позволяют открыть сайт под различными ОС, браузерами и телефонами. Самостоятельно подвигать окно браузера, взять другой компьютер и посмотреть, как сайт себя ведёт в браузере Safari, где чаще возникают проблемы.
Мыслить критически. Советую моделировать все возможные ситуации и показывать в дизайне, как это всё должно работать. Задавайтесь вопросом «а что, если». А что, если клиент введёт описание в 2 раза длиннее, чем было в макетах? А что, если не будет картинки под новость? Продумывайте все ситуации, которые могут случиться, и любые возможные действия пользователей и клиента.
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
Советы
15 ошибок вёрстки, из-за которых письмо может попасть в спам
… и как их исправить.
Сыграем в игру. Я покажу 2 письма, а вы угадаете, какое я достал из папки «Спам».
Игра: какое письмо я достал из спама?
Спам-рассылку сразу видно из-за специфического дизайна: шапка и футер отсутствуют, ссылки привязаны почти ко всему тексту, используются вырвиглазные цвета.
Почтовые клиенты анализируют тонны таких писем и вычисляют приёмы, которые спамеры используют чаще всего. Эти закономерности лежат в работе спам-фильтра. Именно он решает, куда отправить письмо — в «Спам» или во «Входящие».
Иногда спам-фильтры отправляют в «Спам» письма от добросовестных отправителей. Часто это происходит из-за особенностей вёрстки — программа цепляется к цвету шрифта, сокращённым ссылкам или отсутствию alt-тегов у картинок. Если таких мелочей наберется достаточно, рассылка будет отмечена как спам и не дойдёт до «Входящих».
Я расскажу об ошибках в вёрстке письма, из-за которых рассылка может попасть в спам, и дам рекомендации, как их исправить.
Ошибка 1. Отсутствует Plain text версия письма
Plain text — письмо, которое состоит только из текста. Такой формат нужен для почтовых клиентов, которые не могут отображать HTML. Отсутствие Plain text версии письма настораживает спам-фильтры — почтовый сервис может посчитать рассылку спамом.
HTML и Plain text версии письма
Большинство писем уходят сразу в 2 форматах: HTML + Plain text. Какую из версий показать пользователю, решает почтовый клиент.
Как исправить. Большинство сервисов рассылок автоматически добавляют Plain text версию. Проверяем текстовую версию письма в Unisender:
Ошибка 2. Письмо свёрстано одной картинкой
Письма одной картинкой часто используют спамеры, поэтому спам-фильтры блокируют такие сообщения. Вот пример письма из одного изображения, которое я взял из нашей статьи про шедевры спама:
Как исправить. Напишите в письме текст, хотя бы 1-2 абзаца. Это снизит риск того, что рассылка попадёт в спам.
Ошибка 3. В письме есть Flash, JavaScript или ActiveX
С помощью Flash, JavaScript и ActiveX спамеры могут рассылать вирусы. Большинство почтовых сервисов не поддерживают эти технологии и с подозрением относятся к письмам, в которых они есть.
Чаще всего Flash, JavaScript и ActiveX попадают в рассылки, когда отправитель напрямую копирует код с сайта в письмо. Также в сообщение могут проникнуть запрещённые CSS-стили и атрибуты HTML. Mail.ru написали об этом в требованиях по отправке электронных писем:
При использовании HTML в ваших сообщениях, убедитесь что соблюдена валидная структура HTML-документа. Запрещено использовать потенциально опасные объекты, такие как ActiveX, JavaScript, VBScript, Java-апплеты, Frames и IFrames, подключаемые с внешних сайтов CSS, Meta Refresh и т.п. (использование таких элементов может привести к блокировке ваших рассылок).
Как исправить. Просто вырезаем все элементы, которые могут смутить спам-фильтры. В некоторых случаях Flash-анимацию можно заменить на GIF.
Ошибка 4. В письме используются редиректы или укоротители ссылок
Почтовые сервисы не хотят, чтобы отправители скрывали ссылки, на которые кликают пользователи. Редиректы и укоротители ссылок часто используют спамеры — так можно скрыть загрузку .exe-файла или переход на вредоносный сайт. Снова цитируем требования по отправке электронных писем Mail.ru:
Попытка использовать сторонние сервисы (редиректоры, „укоротители ссылок“) для сокрытия информации о настоящей целевой странице любой из веб-ссылок в письме могут привести к тому, что рассылка будет заблокирована.
Похожая проблема может возникнуть, если вы указываете полный URL ссылки, а не зашиваете его в гиперссылку. Если включить отслеживание переходов, то URL сменится на зашифрованную ссылку. Спам-фильтр увидит несоответствие URL с конечным адресом, что приравнивается к редиректу.
Гиперссылка ведет прямиком на сайт — у спам-фильтра никаких подозрений
URL в письме не совпадает с конечным адресом. Не удивительно, что письмо попало в «Спам»
Как исправить. Зашиваем ссылки в текст и картинки. Укоротители ссылок и редиректы не используем.
Ошибка 5. Большой размер вложения к письму
Спамеры используют вложения, чтобы прикрепить к письму вредоносные файлы. Спам-фильтры с подозрением относятся к таким рассылкам и часто блокируют их.
Как исправить. Если вам нужно, чтобы пользователь скачал файл, дайте на него ссылку в письме. Файл для этого нужно заранее залить на файлообменник. Вот пример того, как можно привязать ссылку на загрузку к кнопке:
Привязываем ссылку на Google Диск к кнопке
Бывают ситуации, когда без вложения не обойтись. Тогда проследите, чтобы файл не превышал допустимый лимит:
Лимиты на размер вложенных файлов. Информация из Базы знаний UniSender
Ошибка 6. Большой размер письма
Маркетологи из Email On Acid решили выяснить, как размер письма влияет на доставляемость. Они протестировали текстовые HTML-письма размером от 15 до 650 КБ на 23 наиболее известных спам-фильтрах. Сообщения меньше 100 КБ успешно проходили антиспам-проверку. При увеличении размера начинались проблемы: один или несколько спам-фильтров не пропускали сообщение во «Входящие».
7 из 23 спам-фильтров не пропустили «тяжелое» письмо во «Входящие»
Как исправить. Стараемся уменьшить размер писем до 100 КБ и меньше. Мы уже писали, как это сделать, в статье про схлопывание писем в Gmail.
Ошибка 7. Слишком широкое письмо
Большинство десктопных сервисов для чтения почты имеют размер области просмотра меньше 600 px. Письмо шире 600 px будет разъезжаться и не отобразится нормально.
Как исправить. Задавайте ширину тела письма в 550-620 px, когда верстаете под экраны компьютера. Это гарантия того, что письмо будет хорошо смотреться в любом десктопном приложении.
Ошибка 8. Много ярких шрифтов
Яркие шрифты, которые часто меняются по ходу письма — популярный прием спамеров. Вот типичный пример спам-рассылки:
Два письма из спама с частой сменой ярких цветов
Как исправить. Следим, чтобы рассылка не пестрила. Использовать 2-3 разных цвета можно, если не выкручивать насыщенность на максимум.
Рассылка The Bell. Цвет меняется только по делу: в новом разделе, в подзаголовке и для гиперссылок
Ошибка 9. Часть текста написана с Caps Lock
Ещё один прием, который можно встретить в спам-рассылках. Авторы хотят заинтересовать пользователей отдельными словами и фразами, но привлекают только внимание спам-фильтров.
Caps Lock, восклицательные знаки и яркие цвета — все, чтобы попасть в «Спам»
Как исправить. Не злоупотребляйте заглавными буквами и восклицательными знаками. Привлечь внимание подписчиков можно другими средствами дизайна: плашкой, картинкой, отступом или кнопкой.
Ошибка 10. Форматирование скопировано с текстовых редакторов или с сайта
Текстовые редакторы добавляют в текст собственные теги. Не все они будут отображаться в письме. Например, в тексте может быть шрифт, который не загрузится в почтовых приложениях.
Похожая ситуация с сайтами — иногда пользователи бездумно копируют разметку HTML-страницы со всеми стилями, тегами и атрибутами в письмо. Часть из них не отобразится в сообщении, чем привлечет внимание спам-фильтров. Кроме ненужных стилей и тегов с сайта можно случайно перенести элементы JavaScript или Flash-анимации, которые тоже не поддерживаются в почтовых системах.
Преобразовал Google Doc в HTML через конвертер. В коде появились атрибуты HTML и стили CSS, которые не поддерживаются почтовыми приложениями
Как исправить. Если нужно скопировать текст в рассылку, то сначала вставьте его в простейший текстовый редактор («Блокнот»), а только потом — в письмо. Так вы очистите форматирование текста — лишние теги и атрибуты не попадут в рассылку.
Проблемы с форматированием чаще возникают, когда копируют текст с отступами, дополнительными колонками, редкими шрифтами или заливкой фона. Если вставить несколько предложений обычного текста, написанного на Arial, то, скорее всего, ничего страшного не произойдет. Но чтобы перестраховаться, рекомендую любой текст прогонять через «Блокнот» или набирать вручную.
Ошибка 11. Нет ссылки на отписку
Ссылка на отписку от рассылки — обязательное требование всех почтовых сервисов. Письма, от которых нельзя отписаться, с большой вероятностью попадут в папку «Спам» или будут заблокированы.
Ссылка на отписку в письме
Как исправить. Цитируем требования Яндекс.Почты к честным рассылкам:
«Процесс отказа от подписки:
- (Обяз.) В каждом письме должны быть даны чёткие инструкции о том, как отписаться от рассылки. При этом процесс отписки не должен требовать от получателя сложных действий, таких как восстановление пароля, регистрация или авторизация. Получатель должен иметь возможность отписаться от рассылки в течение 10 минут.
- В теле письма должен быть явно указан адрес подписчика.
- (Обяз.) В письме должен быть использован заголовок list-unsubscribe, оформленный по стандарту RFC. При переходе по ссылке из этого заголовка пользователь должен быть моментально отписан от рассылки.
- (Обяз.) Для отписки необходимо указывать только работающие ссылки».
Ошибка 12. Неправильно выбрана кодировка письма
Для вёрстки рассылок используют кодировку UTF-8. Это стандартная кодировка Юникода, которую используют для большинства HTML-страниц. Если использовать другую кодировку, то письмо отобразится некорректно, из-за чего может попасть «Спам».
Как исправить. Кодировку задают верстальщики, когда создают новую веб-страницу. Чтобы использовать UTF-8, в разделе <head> нужно добавить метатег:
<meta http-equiv=»Content-Type» content=»text/html; charset=UTF-8″>
Чтобы проверить кодировку, откройте HTML-версию письма в редакторе первичного кода (можно даже в «Блокноте») и ищите атрибут charset. Если у него стоит значение «UTF-8», значит все ОК, кодировка выбрана правильно.
Если делаете письмо в сервисе рассылки, можно не переживать — блочные редакторы автоматически задают кодировку UTF-8.
Ошибка 13. У картинок отсутствуют alt-теги
Alt-тег — текст, который показывает браузер, если картинка не отобразилась или отключена.
Отключил картинки, чтобы увидеть alt-теги
К письмам без alt-тегов спам-фильтры относятся неодобрительно: пользователи с отключенными картинками могут не понять сути сообщения.
Как исправить. Прописываем alt-теги к каждой картинке. Если изображение имеет исключительно декоративную роль, alt-тег всё равно нужен, но его можно оставить пустым: alt=»».
Ошибка 14. Коды цветов указаны не полностью
Некоторые почтовые приложения не понимают сокращённые коды цветов из 3 символов (#000). В результате этого часть цветов может пропасть из рассылки или замениться другими.
Как исправить. Указываем все цвета в шестнадцатеричном формате (шесть символов). Например, чёрный будет выглядеть так: #000000.
Ошибка 15. Ссылки из письма открываются в окне почтового приложения
Подписчики не обрадуются, если клик по ссылке откроет страницу в том же окне браузера. Чтобы этого не происходило, всегда используйте атрибут «target» со значением «_blank». Такие ссылки всегда будут открываться в новом окне.
Как исправить. Добавляем тег к каждой ссылке:
Ссылка откроется в новом окне браузера
Делаем чистенько
Спам-фильтрам нравится, когда рассылка аккуратно свёрстана и продумана до мелочей: для тех, кто смотрит без картинок, есть alt-теги, для старых почтовых приложений прикручен Plain text, а внизу гордо красуется большая кнопка отписки. Аккуратное и любовно свёрстанное письмо с большей вероятностью упадет во «Входящие», чем в «Спам».
В завершение ловите чеклист — что проверить в вёрстке, чтобы не попасть в спам:
Обновлено 17 августа 2022 г.
ЭКСКЛЮЗИВЫ ⚡️
Читайте только в блоге Unisender
Поделиться
СВЕЖИЕ СТАТЬИ
Другие материалы из этой рубрики
Не пропускайте новые статьи
Подписывайтесь на соцсети
Делимся новостями и свежими статьями, рассказываем о новинках сервиса
Статьи почтой
Раз в неделю присылаем подборку свежих статей и новостей из блога. Пытаемся
шутить, но получается не всегда
Сейчас я уже порядка 3-х лет в программировании и верстки не касался, кроме исправления каких-то ошибок, но мне постоянно приходится с ней работать, и грамотный верстальщик уже знает как нужно делать, а как не стоит городить.
В этом посте я хотел бы рассказать о том, что не стоит делать, а что очень облегчает работу программисту, возможно я приведу дальше не все примеры или ошибки, так как пишу пост из головы. Поехали!
Минимизированный css
Работая с многими верстальщиками, я уже узнал особенности каждого и что именно у того или иного нужно проверять. Верстальщик, который работает на потоке различных заказов может вам сдавать верстку с сжатым кодом, но когда вы доберетесь до натяжки ее, он уже может просто удалить данный проект. Уважаемые верстальщики, если вы желаете самостоятельно минимизировать стили, то прошу вас, отправляйте файлы вместе с расширенной версией.
Ссылки на сторонние ресурсы
Самый распространенный косяк верстальщиков, которые делают на скорую руку — это ссылки на библиотеки или дополнительные файлы с сторонних ресурсов. Не работая программистом или сеошником — вы никогда не узнаете почему это плохо, и по этому я каждому своему сотруднику это объясняю.
Причин тут на самом деле несколько:
- Ссылаясь на другой ресурс, вы отрезаете себе СЕО, но улучшаете его тому ресурсу, на который ссылаетесь.
- При загрузке сайта, скорость загрузки увеличивается, обращаясь к другому ресурсу, соответственно снижается скорость загрузки и страдает СЕО.
- Если ресурс закроется, на котором находилась нужная библиотека или переедет на другой домен — ваш сайт будет работать, мягко говоря — неправильно. Ни кто не застрахован от того, что bootstrap или jquery просто переедут, или их домен выкупят, потому что какой-то менеджер забыл по ошибке проплатить за него. А сайт, который вы делали — запущен уже 2 года как, и вы забыли уже про него. Вы не сразу поймете что что-то рухнуло, как и клиент, просто сильно начнет проседать сео и узнаете вы об этом только тогда, когда вашему клиенту кто-то это сообщит. Не очень приятная ситуация, когда вам позвонит клиент и будет орать в трубку, что его сайт не работает по вашей вине! Зачем допускать такие моменты, если сразу можно сделать и скачать нужные вам файлы, ведь свое — всегда лучше!
ALT and TITLE
Да, немогу назвать это ошибкой, но считаю что верстальщик, который стремиться стать профессионалом — обязан проставлять пустые alt и title. Это значительно облегчает работу программисту, при проставлении нужных переменных туда.
Адаптивность и кроссбраузерность
Как же часто, проверяя в Яндекс браузере или Egge я нахожу косяки или нерабочие js, потому что тот или иной браузер их не воспринимает, либо не закрывает глаза на ошибки js, на которые закрывает google chrome. Не ленитесь — делайте качественно и перед сдачей обязательно проверяйте везде, на всех юраузерах и разных расширениях, не забывайте о маленьких телефонах или перевернутом экране.
Табы и слайдеры
Не раз встречал от неопытных верстальщиков такой момент, что на клик по табу верстальщик написал js на его id, присвоил каждому свой id и не учел что табов или слайдов может быть больше или меньше, написал так, что бы работало при проверке и все. А написать унифицированное решение не хватило мозгов, или не было желания подумать немножко. Конечно же такая часть работы идет на свалку и нам приходиться самостоятельно переписывать данную часть полностью.
Структурирование объектов
Бывает приходит верстка, которая ну просто в ужасном состоянии, нет иерархии, не видно вложенности и просто беспорядок. С такой версткой просто нет желания работать! Прошу вас, верстальщики, задумайтесь о том, что вы делаете для людей и после вас с этим кодом еще нужно работать программисту.
Дублирование объектов для адаптации
Оу, ну это самое интересное, что можно встретить у новичков. Мне попадалось дублирование много раз. Что же это такое? Дублирование — это когда верстальщик не смог реализовать перестроение на мобильную версию и просто сделал 2 варианта, которые он включает или отключает через @media через css. Выглядит все красиво, но пока не заглянул в код. Обращаюсь к тем, кто этим злоупотребляет — если вы думаете что это будет не замечено, поверьте, это 1000% будет видно! Чаще всего это делают на ПК меню и мобильном меню.
Это основные моменты, которые я сейчас смог вспомнить, конечно же есть еще детали и нюансы, которые вы можете дописать в комментарии к данному посту. Расскажите о косяках, которые встречали вы, мне будет интересно почитать.
Верстка – процесс весьма кропотливый. Пусть HTML/CSS и не являются языками программирования, освоить CSS – в разы сложнее, чем освоить тот же Python. Причина – в том, что если Питон развивался логично и постепенно, то CSS развивался в условиях непримиримой войны между браузерами, каждый из которых пытался пропихнуть свои стандарты. Добавьте сюда кодировки, изменения HTML от W3C и позднее «накручивание» DOM для высокоуровневых языков – получите ад, бардак и хаос. Из него растут типичные ошибки начинающего верстальщика, не успевшего в этом хаосе сориентироваться – неправильное использование id, использование style, попытка решения проблем через !important, invisible text для отступов и так далее.
1. Неправильные имена классов
2. Описание стилей внутри < style >
3. Символы, не предназначенные для верстки
4. Использование ID для идентификации
5. Очень большие картинки
6. Использование HTML для верстки в целом
7. Неправильное использование заголовков
8. Использование !important
9. Не прописаны альты в < img >
Ниже мы все эти ошибки рассмотрим и расскажем, почему не стоит так делать.
1. Неправильные имена классов
Правильная верстка в CSS организуется через классы – вы указываете классы для элементов, и когда вы меняете что-то в классе, изменения применяются ко всем элементам этого класса. Идея пришла из объектно-ориентированного подхода к программированию, и самое прекрасное, что классы дают – это принцип DRY, Don’t Repeat Yourself, «Не повторяй себя». Если у вас на сайте 50 одинаковых кнопок, без классов вам пришлось бы менять цвет кнопки 50 раз, когда заказчик захочет кислотно-зеленую кнопку «КУПИТЬ» вместо красной. С классами вам нужно поменять всего одно значение.
С классами связано множество ошибок начинающих верстальщиков, но самая распространенная – это бессмысленные (и беспощадные) имена классов: .knopka, .vtoraya-knopka-sleva, .vyrovnyat, .ne-trogat – вы и сами можете придумать/найти множество таких примеров. Конкретно эти плохи по двум причинам:
- Ничего не понятно (но очень интересно).
- Транслит.
Транслит – это всегда плохо, потому что он вырвиглазный и его невозможно читать. Но если мы подберем адекватные имена на английском (.button, .second-button-on-the-left, .align, .do-not-touch), то хорошо все еще не станет, потому что назначение классов не прояснилось. В основном эта проблема бьет по программистам, которые затем будут писать js-код, но если вы расплодите кучу бессмысленных названий, то вам потом самим будет сложно понять, что вам нужно подправить: .button3, .button12 или .button-on-top-final-red-v2.
Давайте понятные имена: .shopping-cart-buy-button, .header-logo, .search-page-backgr. И по возможности группируйте классы в .css-файле, чтобы их было проще искать.
2. Описание стилей внутри < style >
Забудьте про прописывание стиля в этом тэге. Функция была добавлена еще до появления CSS и оставлена в HTML для обратной совместимости – чтобы очень старые сайты не сломались. Описывать разметку в < style > нельзя, потому что ломаются приоритеты и при отладке сложно найти ошибку – особенно если искать ее будете не вы. Вся верстка должна быть исключительно в .css-файле – этот принцип в программировании называется инкапсуляцией, и за его применение другие верстальщики (которые будут разбираться с вашей разметкой) скажут вам огромное спасибо.
3. Символы, не предназначенные для верстки
Unicode/UTF обладает множеством интересных символов для отображения, сюда входят пиктограммы, смайлики и invisible text. Будьте с ними очень аккуратны – разные шрифты могут по-разному «относиться» к отображению этих символов, некоторые браузеры тоже воспринимают их некорректно. Если прямо совсем хочется их использовать – хотя бы сбросьте стандартную верстку браузера через * {} и протестируйте верстку на нескольких устройствах.
Кстати, для пиктограмм и смайликов можно создать отдельный шрифт, в этом случае вы получите безболезненное масштабирование и гарантию отображения.
4. Использование ID для идентификации
Использование ID для «точечного» задания стиля – это удобно, но делать так тоже не стоит. JS активно взаимодействует с ID и может менять идентификаторы элементов для своих внутренних целей. Если js-код поменяет ID, которому вы прописали стиль – верстка слетит. Лучше напишите пару лишних строчек кода для класса.
5. Очень большие картинки
Несмотря на улучшение качества интернета в мире, эта проблема все еще остается. Большие картинки долго грузятся, а чем дольше висит загрузка страницы, тем больше шансов, что человек уйдет к конкурентам, у которых сайт не тормозит.
Пережимайте картинки в jpg, а если прямо необходимо выкладывать большие картинки на странице – ищите специальные js-скрипты, которые позволяют догружать картинки отдельно от остального контента на странице.
6. Использование HTML для верстки в целом
Самая частая проблема – использование /br для верстки, сюда же относится прописывание стиля в < class > и < p > для создания отступов или пустого пространства. HTML – язык разметки, он показывает браузеру, где и какие элементы должны находиться. Как эти элементы выглядят и как делят между собой пространство – вопрос к языку стилей CSS. Вот им вы и должны пользоваться для решения этих проблем. А если у вас половина разметки будет в CSS, а половина в HTML, то при достижении определенного порога сложности проекта вы вдруг обнаружите, что при любом внесенном изменении все ломается.
7. Неправильное использование заголовков
Заголовки показывают и браузеру, и поисковым роботам, где находится основной контент. H1 должен быть в единичном экземпляре, h2 должны быть вложены в h1, h3 должны быть вложены в h2 и так далее.
Если вы не придерживаетесь этих правил – не удивляйтесь потом, почему поисковые роботы игнорируют вашу страницу.
8. Использование !important
!important – вселенское зло. !important переопределяет естественные приоритеты CSS, и это выстрелит вам в ногу, когда вы будете искать ошибку в верстке. Хуже того, поведение нескольких !important при их пересечении не очень хорошо задекларировано, и ошибка может стать плавающей – в одном браузере она есть, в другом его нет. Плавающие ошибки – самое плохое, что может случиться в коде, потому что при наличии такой ошибки бывает проще все снести и переписать заново, чем отлавливать такую ошибку.
Еще один важный момент – если вам нужно использовать более одного !important в разметке, это почти всегда означает, что вы плохо эту самую разметку продумали. Сядьте и задайте себе вопрос: «Почему мне приходится использовать !important здесь?» Ответом на вопрос почти всегда будет плохо продуманная система классов, то есть плохая архитектура. С самых первых шагов в верстке приучайте себя продумывать архитектуру классов и селекторов – это сэкономит вам кучу времени в дальнейшем.
9. Не прописаны альты в < img >
Вам alt в <img> может быть и не нужен, но он очень нужен SEO-специалистам и js-программистам.
Пропишите хотя бы пустой alt.
10. Злоупотребление div
Если вам нужно создать контейнер – используйте div, который для этого и предназначен. Если вам нужно вывести текст – используйте span, который для этого предназначен. Не нужно мудрить и использовать div для текста и span для блоков – когда верстка станет более сложной, будет больше шансов, что что-то сломается. Если вам прямо очень сильно нужно использовать span для блока – пропишите для него display:block.
Правильное ревью верстки
Провести самостоятельное ревью верстки довольно сложно – глаз «замыливается», и вы можете пропустить очевидную ошибку. Есть один инструмент, который может вам помочь – валидатор от W3-консорциума, расположен тут: https://validator.w3.org/. Он показывает основные ошибки в HTML, хотя для CSS code-review подходит так себе. Лучший способ сделать ревью – найти другого верстальщика и отдать страницу на ревью ему.
Если такого верстальщика нет – возьмите 10 советов выше и 10 раз пройдитесь по коду, с каждой итерацией проверяйте, выполнили ли вы все рекомендации.
FAQ
- Что такое DOM? Document Object Model – это модель, описывающая взаимодействие элементов на странице. На основе всех элементов строится дерево, с помощью которого js-программист может быстро получить доступ к нужному элементу. DOM строится на ID, классах и тэгах, и чем более логично они будут прописаны на странице, тем проще будет писать код для скриптов.
- Можно ли взломать сайт через ошибки в HTML/CSS? Как ни странно, можно – через cross-site scripting. О том, как от этого защититься, можно почитать здесь: https://www.w3.org/TR/CSP2/.
Подведем итоги
Тезисно:
- выбирайте содержательные имена классов;
- не описывайте стили внутри < style >;
- с осторожностью используйте invisible text и другие редкие символы Unicode;
- старайтесь избегать использования id для идентификации;
- сжимайте картинки;
- не используйте HTML для верстки;
- расставляйте заголовки логично, более низкие вложены в более высокие;
- избегайте !important, продумывайте структуру верстки заранее;
- прописывайте альты в < img >, даже пустые;
- используйте < div > для блоков и < span > для текста.
Исправление ошибок верстки
Верстка сайта – это не просто создание технического каркаса будущего веб-ресурса и воплощение творческих идей в конкретной визуальной оболочке. Правильная верстка – одно из условий популярности будущего ресурса у пользователей сети и поисковых машин. Она определяет валидность сайта (соответствие ресурса общепринятым стандартам веб пространства), его корректное отображение в различных браузерах. Если проверка на валидность пройдена успешно, то есть документ является валидным, то с большой долей вероятности он одинаково будет отображаться во всех браузерах (кроссбраузерность).
Валидная верстка — это обычно «чистый», красивый код, который ко всему прочему «нравится» поисковым системам. Поэтому проверка кода на валидность — обязательный этап при верстке сайтов.
Наконец, от качества верстки зависит соответствие созданного сайта изначальному дизайну, общий визуальный эффект от просмотра страниц интернет портала и отношение к нему пользователей сети.
Что такое ошибки верстки, почему они возникают и как с ними бороться?
Ошибками верстки обычно называют критическое несоответствие результатов верстки первоначально созданному дизайну либо некорректное поведение элементов html-документа (смещение текста или изображений, открытие нового материала не в том окне, нарушение цветовой палитры и т.д.). Причины возникновения ошибок верстки могут быть самыми разными:
- фактические ошибки, допущенные человеком (пропуск закрывающих тегов или других элементов кода);
- синтаксические ошибки и опечатки;
- незнание особенностей конкретных браузеров.
Главная сложность при исправлении ошибок верстки – это трудоемкость поиска самой ошибки. Далеко не всегда проблема сразу видна даже самым опытным специалистам нашей компании. Выявить ее помогает следование четким алгоритмам поиска ошибок верстки и использование соответствующих инструментов для этого поиска.
Для начала специалист пытается идентифицировать проблему и определить, какие элементы в структуре сайта могут быть связаны с возникающей на веб портале ошибкой. Прежде, чем начать устранение проблемы, следует исключить ошибки валидации и убедиться, что сайт полностью соответствует требованиям, предъявляемым к веб ресурсам. Когда проблема определена, ее нужно максимально локализовать, чтобы очертить участок поиска ошибок.