Нельзя однозначно сказать, что вёрстка проще программирования: интервью с преподавателем Хекслета Никитой Михайловым
2026-02-26 23:01 Diff
https://ru.hexlet.io/blog/posts/html-css-perspectives

Преподаватель Хекслета Никита Михайлов в интервью рассказал, кому актуально изучать вёрстку, поделился мыслями о ситуации на рынке труда и профессиональных перспективах верстальщиков. Также Никита поделился списком любимых инструментов, рассказал, что нужно знать новичкам, чтобы претендовать на позицию джуниора, порассуждал о перспективах HTML и CSS в обозримой перспективе.

— Никита, представься пожалуйста — расскажи нашим читателям о себе всё, что считаешь нужным.

— Меня зовут Никита Михайлов, занимаюсь разработкой порядка 8 лет. Начинал как веб-мастер, который на все руки. В небольшой веб-студии мы разрабатывали сайты, верстали. Писали код на PHP, JavaScript.

Сейчас развиваю программу «Верстальщик» на Хекслете. Пишу курсы, делюсь своими знаниями и опытом, который приобрёл за годы работы в разработке.

— Кем ты себя считаешь в первую очередь: преподавателем, разработчиком, программистом, верстальщиком?

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

— То есть сочетаешь практику и теорию: преподаёшь и что-то делаешь руками, правильно?

— Конечно. Чтобы написать курсы, упражнения, давать какие-то уроки, ты не можешь устраняться от самой разработки, потому что потеряешь весь скилл. Невозможно просто писать курсы, не занимаясь разработкой.

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

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

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

— Наверное, нельзя сказать, что чистые верстальщики, особенно джуны, так же востребованы на рынке, как JavaScript-разработчики или PHP-, Python-разработчики. Начинающих верстальщиков ждут на рынке не так охотно, как программистов.

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

Но войти в разработку через вёрстку можно. Я посмотрел сейчас на «Хедхантере» — по запросу «HTML-верстальщик» есть 121 вакансия. Это не считая заказы на фрилансе, подработок.

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

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

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

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

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

— Никита, ты говоришь, что фронтендеры должны знать слишком много инструментов. А мы можем сказать, что бэкендарам здесь больше повезло? Что им достаточно выучить сервер, базы данных, и можно работать.

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

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

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

— Знаю людей, которые говорят, что вёрстка — это скучно, что это больше механическая работа. А вот программирование — это интересно, это творческие задачи. Согласен с этим? Лично тебе больше нравится верстать или программировать? Может, ты не разделяешь эти процессы?

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

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

— А что проще — верстать или программировать? Можно ли назвать вёрстку плавным входом в разработку?

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

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

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

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

— Легко верстать не получится. Всё зависит от того, до какого уровня специалист хочет погрузиться в вёрстку. Если нужно просто накидать пару блоков, то да, можно изучить минимум информации за месяц или два. Но чтобы верстать большие проекты, нужно долго учиться и работать над практическими задачами.

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

— Самое смешное, что такое же мнение я слышал много лет назад, когда учился в колледже. Была известная программа Dreamweaver от студии Macromedia, потом её выкупил Adobe. В ней можно было накидывать какой-то дизайн, а на выходе получать вёрстку.

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

Для тех, кто понимает о чём речь — в этой программе вся вёрстка строилась на абсолютном позиционировании. Через какое-то время у Adobe вышла новая программа. Суть была той же, но программа лучше работала с мобильными устройствами. Сейчас программы нет, этот проект закрыт. Алгоритмы снова не смогли заменить верстальщиков, хоть справлялись с вёрсткой лучше, чем Dreamweaver.

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

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

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

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

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

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

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

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

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

Джуниору полезно знать HTML- и CSS-препроцессоры: об инструментах верстальщика

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

— В каждой вакансии для верстальщиков есть строчка «требуется знать HTML и CSS». Это очень расплывчатая формулировка, трудно понять, что именно нужно знать. Если говорить о джуниорах, им нужно знать и понимать такие вещи:

  • Семантическую вёрстку
  • Поток документа и как он работает
  • Основные модули CSS, например, Flex. С гридами не всё однозначно, кто-то их требует, кто-то нет, но знать их полезно

Это базовый набор знаний HTML5 и CSS3, который нужен джуну. Можно ещё включить переменные, какие-то другие новые вещи. Даже джуну стоит смотреть спецификации и изучать новые технологии.

Полезно знать CSS-методологии, хотя бы несколько. Методология — это набор правил, которые мы используем для структурирования CSS. Здесь есть много подходов. Наверное, самый популярный — БЭМ или Блок, Элемент, Модификатор. Он используется в Яндексе. Можно спорить о достоинствах и недостатках этой методологии, но она самая популярная в российском сегменте разработки. Этого нельзя сказать о зарубежном сегменте.

На Западе популярны объектно-ориентированный CSS, SMACSS, атомарный CSS. Атомарный, наверное, в меньшей степени. Но всё равно он встречается в фреймворках. Фреймворки тоже желательно знать. Наверное, самый популярный фреймворк — Bootstrap. Ещё есть Tailwind CSS, UIKit. Хотя бы один из них стоит выучить. Даже если в компании, в которой вы хотите работать, используют другой фреймворк, благодаря изучению Bootstrap вы будете понимать, что такое фреймворки и как с ними работать.

Джуниору полезно знать HTML- и CSS-препроцессоры. Тут можно выбирать на свой вкус. Можно смотреть на синтаксис: что нравится, что нет. Если вы работали с одним препроцессором, переключиться на другой будет просто.

Ещё нужны общие знания. Например, работа с Git — без него не получится. Многие новички пропускают изучение систем контроля версий, думают, что освоят их на работе. Конечно, на работе вы их освоите, но сначала наломаете дров. Надо понимать, что многие работодатели даже на этапе собеседования просят ссылку на GitHub. Они смотрят даже учебные проекты, оценивают, умеет ли кандидат работать с Git.

И ещё один момент — хотите или нет, но базовые знания JavaScript вам понадобятся. Это обязательно для верстальщика, так как многие взаимодействия с пользователем всё-таки происходят через JavaScript. HTML и CSS постоянно совершенствуются, в них появляются какие-то фишки для взаимодействия с пользователем без JavaScript, но без основ программирования пока ещё работать трудно.

Это примерный набор базовых знаний, которые нужны джуну. Понятно, что от новичка никто не ждёт знания нюансов. Если мы возьмём Flex, джуну не надо знать, по какой формуле работает flex-shrink или flex-grow, он просто должен знать, о чём это.

— Ты говоришь, что джуниор должен знать основы JavaScript. Речь идёт о браузерном JS, или надо изучать основные программирования, алгоритмы, структуры данных и другие фундаментальные штуки? В каком объёме надо знать JavaScript, чтобы стать верстальщиком?

— Для вёрстки достаточно знать, как работает браузерный JavaScript. Можно пропустить сложные вещи, можно не понимать, что такое функциональное программирование, чистые функции и так далее.

Верстальщик должен уметь подключить любую библиотеку, настроить её. Возможно, нужно уметь реализовать простую логику на уровне «если пользователь нажал на такой-то элемент, показываем ему другой элемент». Это не очень сложные задачи, разобраться с ними можно по готовым паттернам.

— Холиварный вопрос — как ты относишься к pixel perfect? Должен ли верстальщик уметь верстать с точностью до пикселя?

— Использовать или нет pixel perfect — моё мнение на это не влияет. Я негативно отношусь к чистому pixel perfect, где надо всё переделывать, если у нас расхождения в пару пикселей. Это скорее вредит работе верстальщика. Он начинает нервничать, а верстальщики как художники — обидеть их может каждый.

Получается, ради pixel perfect мы начинаем подгонять шаблон. Вместо того, чтобы сделать его аккуратным, мы занимаемся подгонкой. Возьмём пример — у нас есть пять кнопок с одинаковой функциональностью, но с разным цветом. Как с ними работать правильно?

У нас есть базовый класс или миксин, который мы переиспользуем. А теперь представим, что у дизайнера дрогнула рука, и он сделал одну из кнопок на три пискеля шире. Тут возможны два варианта. Первый — мы забываем о pixel perfect и оставляем систему, с которой будет удобно работать. Второй — мы навешиваем ещё один класс или переписываем классы конкретно для этого элемента, подгоняя его под шаблон.

Четыре элемента из пяти у нас правильно оформлены как компоненты. А пятый остался с новыми стилями, который там не нужны. Поэтому я против жёсткого pixel perfect.

Понятно, что какая-то точность должна быть, чтобы элементы были на своих местах. Даже в упражнениях и проектах на Хекслете решение студента тестируется с помощью скриншотов. Это можно назвать проверкой с помощью pixel perfect. Но я даю какие-то допуски. Например, шапка не должна отличаться от эталона больше чем на 5%. Эти 5% как раз возьмут на себя все недочёты, небольшие ошибки дизайнера, различия в версиях браузера.

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

— У нас в профессии «Верстальщик» студенты изучают Bootstrap, это самый популярный фреймворк. С одной стороны, его используют большие серьёзные проекты, например, Хекслет :-) С другой стороны, можно встретить высказывания, что бутстрап и другие фреймворки годятся только для прототипирования или админок, что серьёзные верстальщики должны верстать без фреймворков. Можешь рассказать о своём отношении к фреймворкам?

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

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

Давайте вспомним, откуда вырос Bootstrap. Это внутренний проект Twitter. Это уже говорит о том, что это не просто какой-то человек с улицы написал. Этот фреймворк решал задачи Twitter и он решает эти задачи сейчас. Кроме Twitter, Bootstrap используют GitHub, PayPal, Spotify. Это далеко не полный список. Как-то это не вяжется с мнением, что Bootstrap годится только для админок и прототипирования.

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

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

Поэтому серьёзные верстальщики должны знать Bootstrap. Это как с React, Angular, Vue в JavaScript, как Symfony, Laravel, Yii2 у PHP-разработчиков, как Django в Python. То же самое и у верстальщиков.

Кто-то считает, что Bootstrap нельзя использовать с БЭМ. Это не так, фреймворк прекрасно работает с этой методологией.

Это моё мнение насчёт Bootstrap, мой взгляд на то, почему его неправильно интерпретируют.

— А скажи пожалуйста, какие есть популярные и востребованные на рынке труда альтернативы Bootstrap?

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

Tailwind прирастает за счёт компонентов, а Bootstrap исправляет свои внутренние части, даёт какие-то инструменты для разработки. Например, в Bootstrap 5 появилось API для создания утилит.

Ещё есть UIKit, Material Kit. Фреймворков много, и все они строятся примерно на одних и тех же принципах. Есть Bulma, есть Foundation. Последний помогает кроме всего прочего красиво верстать письма.

Что изучать? Мне больше всего нравится Bootstrap. Если хочется иметь больше готовых компонентов, это Tailwind CSS, UIKit. Но их сложнее кастомизировать.

— Многие новички пугаются препроцессоров. В то же время если человек освоил препроцессоры, он уже вряд ли захочет возвращаться к работе с чистым CSS. Можешь для новичков сказать несколько мотивирующих (или не очень мотивирующих) слов: почему препроцессоры стоит освоить, чем они хороши? Сложно ли их использовать?

— Главное — понять, зачем нужен этот инструмент. Препроцессоры упрощают нам жизнь. Зачем бояться того, что нам помогает? Препроцессоры помогают быстрее делать многие вещи. Но сначала надо кое-что выучить.

Возьмём распространённый пример: у нас есть цветовая схема. Нам нужно создать классы, с помощью которых можно менять цвет текста. Допустим, мы работаем в рамках атомарного или объектно-ориентированного CSS. Сколько нужно сделать классов, если у нас на сайте 100 цветов? И что проще: написать пару строчек в препроцессоре, который за нас пройдётся по всем цветам и сделает нужные классы с нужным названием, или 100 раз руками скопировать код и переименовать класс? Тут ответ очевиден.

Именно такие задачи решает препроцессор. Он многие вещи делает за нас.

Ещё один пример: возьмём вложенность. Допустим, у нас есть селектор .page, а внутри него есть .page-button. Благодаря вложенности мы избегаем дублирования. Частая проблема CSS — неструктурированность. Это когда один кусок кода находится вверху, второй в середине и так далее. Препроцессоры помогают структурировать код.

Ещё препроцессоры помогают сократить количество кода. Например, мы часто используем центрирование через Flex. Для этого мы можем использовать свойства display: flex, justify-content: center, align-items: center. Если надо центрировать много элементов, нам приходится эти три строчки копировать и вставлять.

А потом мы решаем не центрировать элементы по вертикали. Теперь что нужно? Пройтись по всем элементам и удалить одно свойство. Что позволяет сделать препроцессор, причём, неважно какой — SASS, LESS, Stylus? Мы просто объявляем миксин или шаблонный селектор, указываем три свойства, а потом подключаем во всех нужных селекторах. Если вдруг что-то изменится, достаточно один раз исправить в объявлении нужное свойство, и оно будет работать во всех селекторах.

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

— С какими инструментами должен уметь работать, чтобы обрабатывать макеты и превращать их в вёрстку? Я имею в виду Photoshop, Figma, какие-то другие графические редакторы, инструменты типа Zeplin и тому подобные.

— Наверное, Figma всё увереннее становится стандартом за счёт своей кроссплатформенности. Если взять Photoshop, с ним на Linux будут проблемы. Sketch работает только под macOS. А Figma работает на всех операционных системах в любом браузере.

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

Этого достаточно, чтобы работать верстальщиком. А для того же Photoshop всё будет выглядеть примерно так же. В Zeplin всё то же самое. В Sketch, я думаю, тоже проблем не будет, это одна и та же функциональность.

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

— Пользуюсь Visual Studio Code от Microsoft. Мне удобна его кроссплатформенность, потому что у меня на стационарном компьютере установлена Windows, на ноутбуке Linux, на компьютере второй системой ещё один Linux. И везде без проблем работает Visual Studio Code.

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

Считаю, что нужно хотя бы на базовом уровне уметь работать с другими редакторами. Тот же Vim нужно знать на уровне «я могу напечатать, сохранить и, о боги, выйти из Vim». Это нужно хотя бы для ситуации «а что, вдруг...». Например, вам попался ноутбук без установленных редакторов, нужно срочно зайти на сервер и поправить вёрстку.

Из плагинов я использую Emmet. Он позволяет писать псевдокод и разворачивать его в HTML. Это удобно при работе с повторяющимися блоками. Также пользуюсь встроенной в Visual Studio Code системой автодополнения. В других редакторах тоже есть встроенные системы автодополнения или специальные плагины.

Обязательно использую какой-нибудь live server просто для того, чтобы запускать вёрстку и отслеживать изменения. Это можно сделать и с помощью Gulp. Но иногда мы просто создаём файл .html и .css и хотим видеть изменения без всяких сборок. Для этого подходят какие-то live servers. Их можно найти на npm, установить глобально или локально.

Также я использую и рекомендую всем использовать линтеры. У меня всегда в рабочей директории есть Stylelint, HTMLHint. Плагин Stylelint в Visual Studio Code всегда подсвечивает мне проблемы в коде. Это помогает исправлять на ходу какие-то ошибки, например, неправильный порядок свойств, ошибки в названии свойств и так далее. А HTMLHint проверяет валидность вёрстки.

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

Есть небольшой нюанс, из-за которого я считаю SASS с синтаксисом SCSS более удобным. Этот препроцессор совместим с обычным CSS. То есть вы можете взять любой файл .css. переименовать его в .scss, и он будет работать. С другими препроцессорами так не получится, в том числе с SASS с синтаксисом Sass.

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

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

Кстати, возвращаясь к препроцессорам. Я использую HTML-препроцессор Pug. Просто мне так удобно. Этот инструмент предупреждает ошибки, связанные с открытием и закрытием тегов. В Pug не нужно открывать и закрывать теги, всё строится на уровне вложенности. Если вы писали на Python или хотя бы видели код, то понимаете, о чём речь. Чтобы вложить один код в другой, надо использовать табуляцию.

Любимый CSS-фреймворк — Bootstrap. Я евангелист этого фреймворка. Бегаю везде и говорю, насколько он прекрасный. Где-то читаю доклады, пытаюсь показать, что Bootstrap далеко не для админок.

— Я знаю, что ты контрибьютишь в Bootstrap. Это правда?

— Да, есть такой опыт.

Слепые люди не видят сайт, они могут ориентироваться с помощью того, что вы как верстальщик им дали: о доступности

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

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

Какие здесь могут быть сценарии?

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

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

Как это проявляется? Представим стандартные интерактивные элементы, например, кнопки или ссылки. Предположим, у нас есть ссылка или кнопка «Подробне», которая ведёт вниз страницы. Как обычно делают такие элементы? Мы в атрибут href ставим решётку и id элемента, к которому нужно прокрутить страницу.

Но этот id попадёт в браузерную строку, а это ужасно не любят специалисты по SEO. Они просят сделать элемент обычным <div>, повесить обработчик и по клику перемещать человека в нужную область страницы. Это работает, если человек пользуется мышью. Но <div> — не интерактивный элемент. Мы не сможем попасть на него с помощью клавиши tab. Она отвечает за то, чтобы пользователь браузера перешёл к следующему интерактивному элементу.

Такие же проблемы бывают с формами, так как все любят стилизовать их, делать красивыми, но верстают не с помощью стандартных тегов типа, <input>, <label>, а просто там навесили, тут как-то JavaScript'ом обработали. С клавиатуры такие формы недоступны.

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

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

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

Слепые люди не видят сайт. Они могут ориентироваться с помощью того, что вы как верстальщик им дали. А вы можете им дать правильную семантическую вёрстку. Это к вопросу использования вместо . Вы можете правильно верстать формы, строить меню, соблюдать порядок заголовков. Это очень важно для людей, которые используют скринридер.

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

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

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

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

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

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

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

Из скринридеров можно использовать NVDA или какие-то браузерные расширения. Но расширения работают не очень хорошо, я предпочитаю десктопный вариант. Если брать другие инструменты, то в каждом браузере с «девтулзами» уже есть какие-то базовые вещи для проверки доступности. В FireFox есть отдельная панель, связанная с доступностью. В Chrome есть Lighthouse, который проверяет доступность. Также в Chrome есть расширение axe, нацеленное на работу с доступностью.

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

— Никита, уточняющий вопрос. Из инструментов ты назвал вещи, которыми можно проверять доступность. А как всё-таки верстальщик её обеспечивает? Я правильно понимаю, что это просто се��антическая вёрстка, и больше ничего в арсенале нет?

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

Ещё у W3C есть огромный документ — WCAG. Это гайдлан, в котором указано, как обеспечивать доступность контента. В нём можно прочитать, какой должен быть контраст, как его проверять, какие формулы для этого используются. Я использовал этот гайдлайн, когда писал статью о контрастности цвета. То есть в руководстве от W3C можно найти спецификации, которые объясняют доступность.

VR станет массовым, это добавит работы верстальщикам: о перспективах вёрстки

— Как ты думаешь, какой будет вёрстка через 10 или 20 лет? Например, сохранятся ли HTML и CSS или у нас будут новые языки разметки и стилей?

— Честно говоря, не думаю, что через 10 или 20 лет что-то глобально изменится. Понятно, что будет много небольших изменений. Думаю, у нас появятся новые способы взаимодействия. Условный VR через 20 лет станет более продвинутым и массовым. А чем более массовым он будет, тем больше работы будет у верстальщиков. Нужно будет делать веб-интерфейсы доступными для VR.

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

— Несколько лет назад верстальщиков пугали появлением новых гаджетов — от умных очков и часов, смартфонов с гибким экраном до дисплеев холодильников и кофеварок, под которые надо верстать по-новому. А как на самом деле влияет на вёрстку появление разнообразных девайсов с разными экранами?

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

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

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

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

— Если брать HTML, то каких-то революций я не наблюдаю и не жду. Конечно, я человек и не могу знать всё. Скорее, каких-то революционных изменений надо ждать со стороны CSS. Мы уже столкнулись с тем, что существующие стандарты и возможности CSS нас стесняют. Не зря ведь появляются препроцессоры, которые расширяют возможности CSS.

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

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

— Никита, спасибо большое за интересный разговор. Нам остаётся пригласить читателей изучать вёрстку в рамках программы «Верстальщик».

— Да, приглашаю. Почему я вообще считаю, что стоит попробовать то, что есть на Хекслете? Я стараюсь давать студентам глубинные вещи, погружаюсь не только в то, что работает, но и в то, почему и как оно работает. В том же курсе по Bootstrap описываются не только классы. Студент понимает, как строятся проекты с помощью Bootstrap, как делать кастомные компоненты. Поэтому приходите на Хекслет за фундаментальными знаниями!

— Ещё раз спасибо за разговор!

— Желаю читателям удачи!