Это совет для разработчиков и тех, кто принимает их работу.
Вёрстку важно проверять на прочность, особенно если подставляете в неё содержимое из базы данных: выводите имена пользователей, комментарии, товары, новости.
Ненадёжный кусочек вёрстки может не выдержать пользовательского креатива или редакторской опечатки, сломается сам или покалечит соседние модули.
Советую проверять вёрстку тремя видами содержимого.
Маленькое или пустое содержимое
Например, при вёрстке блога убедитесь, что страница не схлопывается, когда автор публикует заметку из одного абзаца:
Подстраховаться помогут свойства min-height, max-height, min-width, max-width, aspect-ratio и другие инструменты контроля размера элементов.
Слишком большое содержимое
«Константин Константинопольский», огромные фото, километровые комментарии — продумайте поведение элементов при переполнении. Помните о тексте, в котором не сработают переносы: о длинных словах или конструкциях с неразрывными пробелами.
Тут помогут те же min-height, max-height, min-width и max-width, aspect-ratio, а ещё — object-fit, overflow и text-overflow для текстовых модулей.
Необычное содержимое
Что будет, если пользователь добавит в комментарий на сайте ХТМЛ‑теги: жирный, курсив, переносы тегами br или вообще айфрейм с видео? Если допускаете такие сценарии — позаботьтесь, чтобы эти теги выглядели аккуратно и ничего не сломали.
Более опасная ситуация — когда в вёрстку внедряют Яваскрипт в теге script или стили в style. Это называется XSS‑атакой, и от неё нужно защищаться не в вёрстке, а на бэкенде.
Страхуйтесь не только в вёрстке
Любые данные нужно проверять не только в вёрстке, на фронтенде, но и на бэкенде: сжимайте фото товаров при загрузке в админку, чистите лишние и опасные теги при создании статьи или комментария, ограничивайте пользовательский ввод и так далее.
Защита на фронтенде не отменяет защиты на бэке и наоборот, они работают в паре, страхуют и дополняют друг друга.
Знайте меру
Полировать и улучшать код можно бесконечно. Трезво оценивайте время и ресурсы, перспективы и риски проекта. Если у вас мегапопулярный сайт, затраты на оптимизацию наверняка окупятся. Но если речь о сайте‑визитке, который редактируете только вы сами раз в полгода, особо убиваться по надёжности вряд ли рационально.
P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.