Comments 16
Чтобы это не выглядело как оно выглядит нужны примеры. Нейросетка может и в них)
Убедитесь, что нет горизонтального скролла (особенно на мобильных устройствах и планшетах).
Я не верстальщик но спрошу почему так должно быть? Мне, как пользователю, удобно иногда протаскивать скролл. Субъективно это удобнее, чем елозить пальцем по экрану полминуты на длинных страницах.
Да, иногда это так. Но здесь нужен не скоро всей страницы, а слайдер блока.
Попадался такой сайт. Страница получилась очень насыщенной и не длинной. Было несколько блоков подряд с горизонтальными слайдера и. Идея и реализация очень понравились.
Тут речь о том , что пришел с Бека текст большей длины а у тебя например стоит вайтспейс ноуврап и сайт нахрен сломало, ну и куча других вариантов может быть не таких очевидных, также таблицы и тд и тп
Горизонтальный, чтоб страница не уплывал за пределы экрана
Используйте только один h1 на странице.
С появлением элемента section в HTML5 это требование стало необязательным. В книге Джереми Кита «HTML5 для веб-дизайнеров» был даже целый раздел, посвященный данному нововведению.
Верно. И не только в этой книге. Как думаете, логично использовать h1 для страницы со списком разделов сайта? В каких случаях несколько h1 имеет смысл и логичны?
Да, было такое нововведение, но де-факто оно не взлетело.
А сейчас его даже частично выпиливают обратно, как не прошедшее проверку временем.
Пруфы есть?
На странице со списком новостей было бы очень вредным делать заголовок каждой новости ниже, чем h1. Проверьте. Гугл обижается и ранжирует ниже, если там h2 и тем более h3.
Множественные h1 это частное проявление идеи, что уровень заголовка будет определяться уровнем вложенности section.
Но это не особо взлетело, потому что и в разработке неудобно, и с доступностью вопросы есть.
Вот сейчас выпиливают дефолтные стили, которые были частью этого механизма:
https://github.com/whatwg/html/pull/11102
Вывод простой, чем больше технологий тем проще работать и меньше вероятность что что-то сломается. В целом советы годные, но зачастую есть исключения, например про одинаковые стили для универсальной кнопки. Как правило ты начинаешь верстать диз, а через три месяца он у вас изменяется 10 раз, и когда это не условный реакт потом уже сложно отследить в сотнях файлов стилей и шаблонов где ты какой вариант использовал. Скорее годность этих советов для новых небольших проектов. Опять собирать например сторибук это доп время и немало, в небольших компаниях эта документация кода будет очень ощутимой. Проще говоря придерживаться методологий хорошо, но не всегда реализуемо.
Вывод простой, чем больше технологий тем проще работать и меньше вероятность что что-то сломается
Как по мне - ровно наоборот. Чем больше npm-зависимостей вы установите в проект, тем выше риск того, что что-то сломается. Чем большим количеством "стилевых библиотек" вы обмажете проект, тем больше шансов на то, что они начнут конфликтовать между собой.
Как правило ты начинаешь верстать диз, а через три месяца он у вас изменяется 10 раз
Для начала - может просто не стоит брать в работу не утверждённый дизайн? ;)
и когда это не условный реакт потом уже сложно отследить в сотнях файлов стилей и шаблонов где ты какой вариант использовал
А не ровно наоборот? ;) И зачем вам сотни файлов стилей? Ну есть же понятия каскада, специфичности и т.п.
Скорее годность этих советов для новых небольших проектов.
Ровно наоборот - для небольшого проекта можно и в одну портянку стили для каждого элемента собрать. На большом - надо вначале серьёзно продумать "архитектуру стилей".
Ровно наоборот. И это называется иметь брендбук, где все стили прописаны для всего. И если в брендбук вносят изменения, совершенно ясно где поменять код. Если, конечно, он был прописан один раз в одном месте, как и нужно, а не каждый раз копировался по новой.
Ну погнали по порядку))
Не задавайте фиксированную высоту текстовым блокам
Кроме случаев, когда у текстового блока высота фиксирована - а это далеко не самый редкий случай, чтобы выдавать такой безапелляционный тезис.
Соблюдайте единые отступы между секциями
Ок. Но не забывайте про "схлопывание отступов". Ну и тут, опять-таки, многое пляшет от дизайна...
Работайте с единым контейнером через миксины
В тэгах и тексте нигде нет препроцессоров, зато в постулатах всплыли миксины))
Следите за колонками: дизайнеры чаще всего используют сетку на 12 колонок
Не следите за колонками! Следите за размерами блоков. Почему в 2025 дизайнеры до сих пор тащат в веб полиграфические концепты - для меня загадка)) Они там попросту не нужны! Вот она, обратная сторона популярности бутстрапа.
Для колонок не задавайте ширину в px, используйте calc(100% / 12 * N), где N — количество колонок.
Эта формула мне вообще недоступна... Причём тут 12? Зачем тут calc вообще? Сколько там уже существует технология css-grid?..
Открывайте внешние ссылки в новом окне через target="_blank"
Дискуссионно.
Используйте transform и opacity вместо top, width, display: none — это поможет избежать лишней перерисовки и повысит производительность.
А в каком месте opacity аналог display: none? Ну серьёзно? Элемент с opacity: 0 (или там какие лайфхаки с opacity:0.01) занимает место на странице. display: none вообще его удалит из рендеринга, со всеми вытекающими.
Оптимизируйте изображения: используйте ретину (2x), форматы webp и avif, прогоняйте их через svgomg и squoosh.
Ретина может быть и до 4x. Представляете какое мыло я вижу на своей мобиле (568ppi) с вашими 2x? Да и "оптимизация" через webp и aiff выглядит довольно сомнительно... Чай не времена GPRS, чтобы за каждый килобайт сражаться путём порой тотальной деградации изображений.
Тестируйте верстку на реальных данных, особенно после подключения клиентской админки. Вместо ожидаемого текста может прийти null/undefined, а также спецсимволы (­,  ).
Чаще приходят объёмы текста которые попросту не влезают в дизайнерские размеры))
Верстка для ленивых: как перестать бояться CSS и начать верстать как супергерой