Вёрстка — это не тупо
Небольшая сводка ошибок которые встречались во Frontende и Вёрстке за время работы с разными проектами. Конечно это очень малая часть и только те ошибки которые постоянно повторяются. Но всё же давайте пробежимся хотя бы по ним.Мб кому-то этого и не хватало))
UI / UX / Code, 2018–2022 г
Не забывайте читать подписи к картинкам — там раскрыта основная суть)
* »Не заставляйте меня думать» — Книга Стива Круга о взаимодействии человека и компьютера
Вспомните как вас это бесит там где это невозможно
Обязательно должны быть, даже на начальном этапе разработки
Не забывайте напомнить дизайнеру если он о них забыл
Подсказка должна отображать дополнительную информацию или описание неочевидного действия, а не копировать текст из кнопки/ссылки
Описание картинки (alt) — должно быть описанием картинки, а не «avatar»
Проверяйте сайт или библиотеку на доступность если вашим сайтом пользуются люди
Так же к доступности относиться навигация с клавиатуры
Не много про чтение макетов
Пройдемся по кейсам со слайда:
1) Найдите точку «опоры» — якорную точку привязку от куда считать размеры, не забывайте что у нас резиново-адаптивный дизайн, а не вёрстка на обсалютах от точки (0/0)
Мыслите отступами и контейнерами (надеюсь ваш дизайнер делает так же)
2) Размеры кнопок это не ширина -, а текст + отступы
3) Смотрите на то что отрисовано— очевидно, что если в списке отрисован скрол, то значит это максимальная высота списка
Конечно не забывайте включать логику, потому что все ошибаются и какие-то элементы могли быть отрисованы по ошибке
Pro code
Зависит от того как с ним взаимодействовать, где исходники нужно ли пользователю сохранять картинку нужно ли её динамически менять, или например лениво загружать
Если вы знаете только 1 — пройдитесь по всем, не так давно их было около 6. Мб вы найдете для себя более удобный
Не надо использовать и basis и width одновременно, это путает и усложняет дебаг. basis сам подтянется из width
Если вы ещё пишите на БЕМ (и не только)
Данные ошибки часто встречаются в БЕМ, но и в нейминг css-in-js и просто в нейминг компонентов могут утекать.
По кейсам:
1) __p — ну во-первых это не понятное название (не понятно когда его использовать) И этот класс так и умрет без возможности его редактировать. Называйте классы по их назначению например __title, а __p через год жизни проекта уже будет применён к div / h2 / span и любым другим элементам
2) __p-active — это не новый элемент, это вид первого
3) Использование общих селекторов замедляет обработку css
4) .name.name.name — ну тут хз ваще)
5) Не надо использовать слова style если это и так файл стилей и вы описываете стиль (уберите тавтологию если и так все понятно из контекста)
6) Смотри пункт (5)
p.s. не стал расписывать подробно — просто смотрим, что бывает в реальных проектах
Пример рефактора
А когда?
— Когда нет доступа к верстке
— Когда задаются исходные стили
— нормалайз / резет сцц
Если у вас в проекте есть отрицательный index значит не правильно настроены высоты и дыры закрываются костылем.
И еще пару слайдов
Конечное статическое положение должно быть в точке 0,0 — так будет проще работать с элементами
Положением и размером элементов должны управлять сетки, сам элемент уже будет подстраиваться и корректно отображаться в зависимости от размера и контекста
Конец
Источник вдохновения и просто хороший сайт с примерами — https://webmasters.teamdev.com/
