Никита Дубко: каково будущее CSS и при чём здесь спецификации

Никита Дубко

---

Никита Дубко — руководитель службы разработки, пятый голос подкаста «Веб-стандарты» и автор @dev_tip.

---

Ссылки

В начале своего пути, во время становления веб-технологий, CSS включал разные варианты: XML-подобные форматы, форматы с каким-то странным синтаксисом. Плюс многие ставили прообразы CSS-правил в виде атрибутов прямо в HTML-код — и такой метод считался вполне валидным.

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

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

Как развивается CSS

Когда только вышла спецификация CSS 1.0, она была не очень точна и недостаточно однозначно описывала, как браузер должен отображать сайты. В итоге в теории всё работало правильно, но при взаимодействии с другими свойствами ломалось. Однако со временем появились web-platform-tests, которые эту проблему закрыли.

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

С появлением тестов разработчики браузеров, как и обычные разработчики, использующие TDD (Test Driven Development), стали добиваться того, чтобы тесты «позеленели» — то есть проходили с допустимым количеством ошибок.

Однако, несмотря на тесты, некоторые проблемы остались до сих пор — например, градиенты до сих пор в разных браузерах работают по-разному. Чтобы решить такие коллизии, нужно менять и уточнять спецификации. Когда-то мы в Sass и Less даже писали специальные миксины (примеси), которые подставляли нужный синтаксис под каждый браузер автоматически.

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

В современном CSS больше не выпускают «большого» стандарта, а постоянно дописывают отдельные CSS-модули, то есть получается некий «живой» стандарт. Текущим стандартом признаётся то, что опубликовано на официальных страницах W3C для каждого модуля. Отдельно есть снэпшоты стандарта, в которых указаны версии модулей, актуальных в конкретном году.

Это удобно: при таком подходе одни модули почти не развиваются, потому что все и так ими довольны, а по поводу функциональности и корректности работы других у индустрии есть свои ожидания. Из-за этого их активнее дописывают и чаще выпускают новые версии. Кстати, об этих ожиданиях можно судить по обсуждениям на страничках различных браузеров в GitHub.

Раз CSS развивается вместе с потребностями индустрии, то постоянно появляются новые крутые функции. Приведу несколько интересных примеров.

Работа с цветовыми пространствами

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

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

Гибкие адаптивные интерфейсы

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

Если раньше приходилось делать закругление уголков с помощью таблиц и разрезания PNG-файла на множество кусочков, то теперь можно использовать тот же border radius.

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

Каскадные слои и выражения от контейнера

Скоро в стабильных версиях браузеров появятся каскадные слои. Они позволяют управлять каскадом, а не просто воевать с ним. Также в разработке единицы измерения от контейнера — они как единицы vh и vw, только опираются на ширину контейнера-родителя.

HTTP/2

А ещё появился HTTP/2 с другим методом загрузки, позволяющим комбинировать несколько загружаемых файлов в один поток. Под новые механизмы загрузки уже подстраиваются и спецификации шрифтов.

Плитка Masonry

Ещё один яркий пример — плитка Masonry. Она давным-давно популярна и раньше делалась при помощи JS. Сейчас её можно эмулировать, используя возможности Grid.

Переменные CSS

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

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

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

Чем отличаются спецификации CSS

Условно существует три версии спецификации. Причём самый первый стандарт CSS был очень компактным — его спокойно можно было прочитать за вечер.

Потом появился CSS2, в котором было гораздо больше возможностей, добавились новые свойства — причём некоторые из них были написаны под конкретные браузеры. И со временем браузеры начали реализовывать свои свойства — в итоге появились «браузерозависимые» префиксы типа -webkit-text-stroke-outline-, -ms- или -moz-. Это создавало проблемы.

Например, когда Apple не хватало возможностей CSS, они просто добавляли в свой движок WebKit функции с экспериментальным префиксом -webkit-. Разработчики стали широко использовать подобные свойства и делать сайты исключительно для Safari. Позже на форке этого движка создали и Chrome.

Компании — создатели других браузеров захотели, чтобы разработчики использовали их префиксы, и не стали поддерживать префикс -webkit-. В результате многие функции в других браузерах просто «ломались»: с сайтов пропадали тени и border radius — оставался лишь текст на белом фоне.

Позже браузеры отказались от префиксов, но перед этим почти все всё-таки внедрили поддержку некоторых свойств с -webkit-. Их поддерживали Firefox, Internet Explorer, Edge и даже нативный движок Opera. Ирония в том, что эта поддержка противоречит самой идее префиксов: ведь они нужны для того, чтобы свойства работали только в одном браузере.

Ещё с префиксами играли в Microsoft: в разных версиях IE разные свойства работали по-разному. Верстальщики древности с трепетом вспоминают Internet Explorer 6, который привнёс очень много новых фич, но при этом сломал половину старых. Был даже набор специальных костылей, смысл существования которых был исключительно в том, чтобы поддерживать корректное отображение сайта в Internet Explorer 6.

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

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

Кроме того, для кого-то 1% пользователей, использующих Internet Explorer, — это допустимая погрешность, а для какого-нибудь сервиса на 200 миллионов пользователей 1% — это два миллиона человек, население небольшой страны. И перестать поддерживать такое количество пользователей — просто нельзя.

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

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

Но в своих пет-проектах я уже давно использую только самые современные штуки, ведь моя целевая аудитория — это разработчики. А если разработчик сидит на старом Internet Explorer, я буду очень удивлён. Обычно они используют Chrome либо Firefox. А вот на работе я себе такого позволить, конечно, не могу.

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

Почему универсального кода для всех браузеров не существует

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

Самый популярный телефон, согласно статистике Google, — не iPhone, а Moto G4, у которого достаточно слабый процессор и Android давно не обновлялся. Люди живут с ним, хотя половина современных фич на этом устройстве не работает. А ведь для них тоже нужно верстать сайты и сервисы.

Так что главным способом увеличить процент доступности функций в браузере остаётся вёрстка по старым стандартам. И если верстать сайт на таблицах, то это будет работать везде, хотя, конечно, это ужасно неподдерживаемый код, на который тяжело натянуть тот же React.

Проблема как раз в том, что CSS очень сильно скакнул вперёд, поэтому различные новые штуки зачастую нет смысла применять сразу, как только они появились. Мы в подкасте «Веб-стандарты» обсуждали это несколько раз: например, появилась фича container queries, их очень хочется начать использовать, но по факту затягивать их в продакшен ещё рано. Пока сайт Can I use не покажет, что container queries работает в условных 95% случаев, внедрять его нет смысла.

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

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

В общем, мне кажется, нет универсального подхода ни в CSS, ни в JS. Всё равно приходится страдать и смотреть, сколько пользователей с какими браузерами к вам приходят.

Как устроена разработка стандартов и почему стандарты выгодны всем

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

Хотя Chrome и Firefox всё ещё периодически проводят «браузерные интервенции»: мы, мол, решили, что теперь будет так, хотя в спецификации этого нет. Связывают они это с безопасностью или с приватностью данных.

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

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

Тем не менее по каждому модулю есть рабочая группа, можно зайти и посмотреть их на сайте некоммерческой организации W3C (World Wide Web Consortium).

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

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

Кто входит в сам W3C, можно найти на сайте. Туда приглашены представители компаний, непосредственно связанных с вебом, — это Google, Mozilla, Apple, Adobe и другие крупные корпорации, которые заинтересованы в том, чтобы веб работал хорошо. А вообще, любая компания может подать заявку на то, чтобы поставить своего представителя в W3C — но за это необходимо платить членский взнос.

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

Например, один из экспертов — Лия Веру, которая выпустила популярную во всём мире книгу по CSS, прочитала кучу докладов о CSS и SVG, участвовала в разработке спецификаций, работает в MIT. Когда-то давно она фрилансила и была приглашённым экспертом в CSS Working Group. Сама Лия не писала спецификации непосредственно, но внесла большой вклад в их создание. Она «пушила» спецификацию Background & Borders, предлагала варианты синтаксиса и обсуждала их с разработчиками браузеров.

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

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

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

Кого именно пригласить на собрание, решает комитет. Но участник точно должен быть человеком, сделавшим заметный вклад и оказавшим непосредственное влияние на CSS и HTML. Обычно приглашают просветителей, авторов популярных книг, блогов. Это должно быть публично заметное, весомое участие в обсуждениях стандартов.

Как пишутся спецификации для CSS и HTML

Новая спецификация для CSS проходит длинный путь, который часто начинается с explainer. У разных браузеров есть свои репозитории с explainer на GitHub — а кто-то даже просто описывает идею и предлагает первоначальный синтаксис.

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

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

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

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

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

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

Как разработчики могут влиять на развитие спецификаций

Я бы посоветовал разработчикам принимать активное участие в обсуждении спецификаций. Важно как можно больше публично говорить о необходимости такого процесса. Например, рассказывать в подкастах, писать статьи. Лично тегнуть в Twitter человека, который занимается стеком, не очень хорошая идея: слишком велик информационный шум, эксперты могут не заметить. Но понятно, что, если у вас аккаунт на 10 тысяч человек, вас заметят с большей вероятностью, чем аккаунт с 200 подписчиками.

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

Необязательно состоять в W3C, чтобы предложить свою идею. Можно изложить её в формате explainer и принести вендорам. Сейчас всё это лежит в Open Source, поэтому я не вижу никаких сложностей контрибьютить туда обычные проекты.

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

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

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

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

Как спецификации описывают доступность веба

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

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

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

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

Хотя есть фичи, внедрение которых немного ломает доступность. Например, программы категории screen reader развиваются медленнее, чем сами браузеры. А люди часто сидят на сайтах именно через эти screen reader, а не через те же Chrome или Firefox. Поэтому у них возникают проблемы с некоторыми веб-приложениями или сайтами. В этом случае нужно обновить ПО или купить новое устройство — тут как и с обычной вёрсткой: когда мы собираем сайт на крутых и современных технологиях, некоторые остаются за бортом, просто потому, что сидят со старых устройств.

Почему замены CSS не предвидится

Изначально у CSS было много аналогов, которые конкурировали между собой. Разработчики этих спецификаций утверждали, что их формат самый классный, но победили каскадные таблицы стилей.

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

Причём многие сайты уже не имеют никакой поддержки: они просто висят в интернете, собранные на какой-нибудь древней версии WordPress. Если сейчас кардинально изменить синтаксис CSS, то что делать с этими старыми сайтами? Браузеры не станут поддерживать и новую, и старую спецификацию — это двойная работа без особого смысла. Именно поэтому всех устраивает CSS.

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

И мне кажется, так будет продолжаться и дальше. Я бы не ставил на что-то новое: даже если придёт какой-нибудь AR/VR-веб, там всё ещё, как мне кажется, понадобится обратная совместимость с текущим вебом, а новые сущности будут оформляться какими-то новыми CSS-свойствами.

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

Почему no-code не заменит CSS

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

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

Плюс no-code-решения до сих пор не очень производительные — как раз потому, что универсальные. Как правило, производительность заточена на какие-то очень кастомные штуки: ручную разбивку на бандлы и так далее. А специальные команды занимаются производительностью.

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

Поэтому no-code и разработка будут сосуществовать. Конечно, мне сложно поставить себя на место начинающих веб-разработчиков, но, наверное, распространение no-code-решений может вытеснить какие-то вакансии. Иногда проще сделать сайт на Tilda или другом генераторе, чем нанимать Junior- или Middle-разработчика.

С другой стороны, бизнес всё больше осознаёт, насколько важен веб. При этом спрос на разработчиков тоже растёт с каждым годом. Например, в России запретили одну соцсеть для фотографий, а там многие пользователи делали витрины товаров. Что делать такому бизнесу? Видимо, придётся делать сайты.

Это дурацкая ситуация, на которую вам сложно повлиять, но вы будете вынуждены срочно искать человека, который соберёт вам сайт. И тут есть два пути: уйти на Tilda или найти команду, которая сделает недорогой интернет-магазин и будет его поддерживать.

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

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

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

Как будет развиваться CSS в ближайшее время

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

Container queries. Это возможность опираться на размеры родителя, а не на размеры вьюпорта. Для разработчиков виджетов это очень крутая новость. Когда это всё внедрится, в браузеры можно будет встраиваться не фреймами, а как угодно — всё будет зависеть от контейнера.

Родительский селектор. Лет десять назад говорили, что это невозможно и очень сильно замедляет парсинг CSS, делает невозможным построение дерева. Но выяснилось, что это всё-таки возможно. Это очень крутая штука, которая позволяет многие решения c JS перенести в CSS. Причём именно тогда, когда вам нужно знать, что происходит в вёрстке. Сейчас вам для этого нужно зачем-то подключать JS, который осуществляет какой-то анализ, парсинг, а потом ставит класс.

Изоляция CSS внутри слоёв. Тут речь идёт не совсем об изоляции, а скорее о том, как управлять уровнями каскада. Есть директива Layers, реализацию которой пишут прямо сейчас. Она помогает погружать CSS внутрь именованного или неименованного модуля, а потом подгружать этот модуль чуть раньше других. То есть управлять каскадом с точки зрения того, когда он подгружается в парсер.

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

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