Каскадные таблицы стилей (CSS) стали фундаментальной частью современного веб-дизайна и разработки. Несмотря на то, что CSS постоянно развивается и обновляется, его первоначальная спецификация и некоторые решения в дизайне оказались далеко не идеальными. Многие из этих недочётов формировали сложные и неоднозначные ситуации, с которыми сталкиваются разработчики до сих пор. Важно понять, какие ошибки были допущены на этапе создания CSS, чтобы понимать, как их можно обходить, а также учесть их влияние при проектировании новых веб-стандартов. Одна из распространённых проблем связана с пунктом, отвечающим за перенос и обтекание текста.
Свойство white-space имеет значение nowrap, которое на самом деле по своей логике могло бы называться no-wrap. Это маленькое несоответствие в наименовании сбивает с толку многих разработчиков, формируя непоследовательность в поведении и понимании. Кроме того, функциональность по управлению переносами могла бы быть выделена в отдельное свойство, а не смешиваться с white-space. Такая структуризация помогла бы сделать стили более прозрачными и удобными для понимания. Еще одна особенность — анимация в CSS.
Свойство animation-iteration-count, определяющее сколько раз проигрывать анимацию, по задумке могло называться проще — animation-count, что соответствовало бы аналогии с другими счетчиками, например, column-count. Хотя с точки зрения технической реализации это мелочь, единообразие в терминологии облегчает чтение и сопровождение кода. Вертикальное выравнивание, реализованное через vertical-align, вызывает вопросы особенно в контексте таблиц. Это свойство не следовало бы распространять на ячейки таблиц, а вместо этого применить новые свойства выравнивания из CSS3 с их более точной и продуманной семантикой. Связь vertical-align: middle зачастую вводит в заблуждение — это не классическое центрирование по вертикали, а скорее выравнивание текста по средней линии строки, что можно было бы выразить через названия типа text-middle или x-middle.
Такое переименование позволило бы избежать многих недоразумений и ошибок в вёрстке. Одним из наиболее запутанных вопросов в CSS является использование процентов в высоте элементов. В текущих спецификациях процентные значения часто считаются относительно undefined или auto, что приводит к неожиданным результатам и требует применения хака fill-available для корректного расчёта. При использовании процента как относительного значения от fill-available можно было бы добиться более логичного и предсказуемого поведения при задании высоты. Разработка таблиц, одной из самых ранних структур веба, оставила желать лучшего.
Таблицы по своей природе комплексны, и их layout в CSS далеко не всегда отвечает удобству и простоте. Идеальной была бы более «здравая» модель табличного layout, которая упростила бы управление колонками и строками, а также взаимодействие с другими свойствами CSS. Принцип коробочной модели, образующий основу вёрстки на CSS, также стал предметом критики. Свойство box-sizing определяет, как рассчитываются размеры элемента с учетом границ и отступов. Значение border-box по умолчанию было бы гораздо более удобным, позволяя разработчикам проще манипуляции с размерами блоков без необходимости постоянного пересчёта дополнений.
Работа со свойством background-size демонстрирует ещё одну область неоднозначностей. При указании одного значения свойство должно было бы дублировать его для второго параметра, а не подставлять auto по умолчанию. Аналогичная логика могла бы использоваться в функции translate(), где одновременное значение по горизонтали и вертикали делало бы позиционирование более предсказуемым и удобным. Еще одной тонкостью является порядок следования значений в свойствах, связанных с позиционированием, например background-position и border-spacing. В нынешнем стандарте сначала задаётся значение по оси X, а затем по оси Y, однако имело бы смысл менять этот порядок, начиная с вертикального смещения, чтобы согласовываться с четырёхнаправленными свойствами, такими как margin с их блоковыми и инлайн-направлениями.
Такое изменение облегчило бы понимание и использование этих свойств. Стоит отметить и выбор начальных значений свойств. Так, background-repeat в CSS по умолчанию повторяет изображение, что было уместно для 90-х, однако современный веб, с частым использованием баннеров и иконок, получил бы выгоду от значения no-repeat по умолчанию — это избавило бы от необходимости в каждом случае прописывать запрет на повторение. Шорткаты с четырьмя значениями, например margin или padding, задают значения для четырёх сторон. В нынешней реализации значения следуют по часовой стрелке, начиная с верхней стороны.
Однако эксперты отмечают, что более логичным и удобочитаемым был бы порядок против часовой стрелки, позволяющий ставить inline-start прежде block-end и inline-end, что лучше отражает физическую структуру документа. Интересным моментом является принцип работы z-index. Название z-index не совсем отражает суть — более понятным было бы z-order или depth, что четко указывает на «глубину» слоя. Также z-index в настоящее время работает не одинаково на всех элементах. Например, на flex-элементах он ведёт себя иначе, создавая непредсказуемость при наложении слоёв и усложняя процесс контроля визуального порядка.
Очевидной ошибкой является присутствие двух свойств — word-wrap и overflow-wrap — которые по факту дублируют функции. Было бы логично объединить управление переносом слов в одно свойство или же сделать overflow-wrap ключевым словом для white-space, аналогично nowrap, что упростило бы управление переносами в тексте. Автоматическое схлопывание вертикальных маргинов, когда верхний и нижний отступы соседних блоков объединяются, обладает рядом спорных положительных и отрицательных особенностей. Многие разработчики считают, что допускать такой эффект не следовало, поскольку это приводит к ряду загадочных ошибок и сложностей в расположении элементов на странице. Отказ от схлопывания или внедрение более предсказуемого механизма частичного схлопывания могло бы значительно облегчить жизнь фронтендерам.
Особое внимание стоит уделить и поведению таблиц и их взаимодействию с контекстами наложения. В идеале таблицы, как и другие немассивные блоки, например flex-контейнеры, должны были формировать псевдо-контексты наложения, что позволило бы им работать более независимо и корректно в сложных структурах DOM. Одним из тонких вопросов остаётся использование ключевого слова currentColor без дефиса. Согласно оригинальным спецификациям, ему следовало бы называться current-color, как и другим многословным цветовым ключевым словам. Такое название объясняло бы его значение более явно и соответствовало бы общей системе именования.
В плане цветовой палитры существующий набор цветовых имён, унаследованный из X11, совершенно произволен и не систематизирован. Для более профессионального и удобного использования следовало бы разработать предсказуемую систему обозначений цветов, что облегчило бы работу дизайнерам и разработчикам при выборе оттенков. Свойство border-radius, отвечающее за скругление углов, лучше было бы именовать corner-radius, что более однозначно указывало на то, какие именно части блока подвергаются изменению. Такое переименование уменьшило бы путаницу при работе с комплексными формами и создания визуальной гармонии. Для абсолютно позиционированных элементов в настоящее время характерно фиксирование по месту при задании противоположных смещений (например, left и right), тогда как логичнее было бы, чтобы эти элементы растягивались на доступное пространство.
Такой подход упростил бы вёрстку и отказался бы от множества хитрых обходных решений. Свойство hyphens, отвечающее за переносы слов, с технической точки зрения лучше было бы назвать hyphenate, отражая действие в глагольной форме. Исторически название сохранилось благодаря оппозиции со стороны других стандартов (XSL:FO), но для CSS такое имя было бы более интуитивным. В цветовом API CSS выбрали создание специальных функций rgba() и hsla() для защиты от прозрачности. Однако было бы логичнее добавить в rgb() и hsl() опциональный четвёртый параметр, позволяющий задавать альфа-значение в той же форме, что и основные параметры.
Это сделало бы синтаксис CSS более лаконичным и последовательным. Селекторы — ключевая часть CSS, и некоторые их обозначения оставляют желать лучшего в плане логики. Допустим, потомок лучше было бы обозначать символом » в виде двойной стрелки, а косвенный сосед — как ++, что создало бы более наглядные и логичные отношения между элементами, в духе ASCII-арт объяснения связей. Названия свойств с постфиксом -blend-mode (например, mix-blend-mode) могли быть более краткими, просто *-blend, сохранив при этом смысл, но упростив восприятие и запись кода. Синтаксис для юникодных диапазонов различается от общего синтаксиса CSS, что вносит путаницу и усложняет лексический разбор.
Использование более единообразного формата, как u0001-u00c8, и отказ от отдельных микросинтаксисов снизил бы сложность стандарта. Правила для font-family можно критиковать за непредсказуемость. Требование обязательного указания шрифтов в кавычках снизило бы риск ошибок и упростило парсинг, что особенно актуально при использовании имён шрифтов с пробелами или спецсимволами. Flexbox — мощный инструмент для построения адаптивных макетов — имеет запутанные правила при взаимодействии flex-basis и width/height. Предположительно, если явно не указан размер (width/height = auto), тогда можно использовать flex-basis, а в противном случае фиксировать размер элементов.
Это упростило бы понимание и позволило бы избежать нежелательного поведения с ограничениями min/max-width/height. Псевдокласс :empty мог бы называться :void, поскольку он не совсем точно отражает смысл: сейчас :empty выбирает элементы без потомков, но не учитывает наличие пробелов. Было бы логично, чтобы :empty выбирал только элементы, которые действительно пусты, а не содержащие пробельные символы. Возникают вопросы и с важностью импорта стилей через @import — в текущей реализации данные правила всегда вызывают загрузку по сети, даже для повторяющихся импортов, создавая ненужную нагрузку. Более продвинутая дедупликация и кеширование стилей снизили бы количество запросов и повысили производительность.
Множество проблем связано с будущей расширяемостью селекторов. Для предотвращения отказа всего селектора при незнакомой части, следовало бы разделять выражения по верхнему уровню через запятые, игнорируя только некорректные сегменты. Эта практика улучшила бы совместимость с новыми функциями CSS. Селектор :link мог бы изначально иметь семантику :any-link, покрывая не только ссылки на страницы, но и якоря, электронную почту и другие виды ссылок, что улучшило бы однородность стилей. Функциональный синтаксис для flex и прием единиц fr позволили бы передавать доли пространства с явным указанием, что упростило бы понимание и применение гибких размеров вместо священной магии bare numbers.
Название свойства display лучше бы переименовать в display-type — так бы сразу было понятно, что речь идет про тип отображения элемента, а не про его другие аспекты. Стилевые свойства списков list-style и list-item могли бы иметь более выразительные имена, например marker-style и marked-block, что точнее отражает их функцию и облегчает читабельность кода. Текстовое обрезание через text-overflow в настоящее время зависит от свойства overflow, что порой вызывает трудности и неожиданные эффекты. Логичнее было бы, чтобы text-overflow всегда применялся, независимо от overflow, обеспечивая предсказуемость поведения. Когда line-height задаётся в процентах, он сейчас интерпретируется неоднозначно.
Более логичной была бы конверсия в числовой формат, делающая его наследуемым в относительных единицах и удобным для типографики. Псевдоэлементы типа ::placeholder лучше называть ::placeholder-text, а псевдоклассы :placeholder-shown заменить на более лаконичные :placeholder, делая названия более интуитивными. Значение overflow: scroll, вызывающее всегда появление полос прокрутки, могло бы дополнительно формировать контекст наложения, что позволило бы лучше управлять визуальными слоями и взаимодействием с другими элементами. Правило size в CSS, как сокращение для width и height, реализовано скорее в контексте печатных страниц (@page), что сбивает с толку. Было бы удобнее иметь size как привычный шорткат в обычных стилях.
Отмечается, что смешивание ключевых слов и идентификаторов в свойствах grid усложняет синтаксический разбор. Использование функционального синтаксиса, например span(2), сделало бы специфичные значения более однозначными и управляемыми. Допуск комментариев буквально везде в CSS приводит к тому, что их сложно представить в объектной модели документа, что затрудняет создание редакторов и инструментов для динамического редактирования стилей. В HTML комментарии допускаются только в определённых местах, что значительно упрощает парсинг и визуализацию. Выравнивание элементов в Flexbox ориентировано на направление flex-flow, что затрудняет использование при смене направления текста (writing-mode).
Лучше было бы, если бы align- свойства опирались на writing-mode, что позволило бы использовать названия типа align-inline и align-block, делающие стили более универсальными и понятными. Название свойства shape-outside не отражает всё его поведение, ведь оно не обязательно влияет на обтекание контента, а скорее задаёт форму обтекания. Было бы логичнее добавить префикс wrap-, например wrap-shape, что позволило бы избежать неправильных ожиданий по работе свойства. Использование !important в CSS вызывает спорное восприятие, поскольку слово important написано так, что читается как «не important» из-за отрицательной конструкции. Возможно, следовало бы придумать другую форму усиления приоритета стилей, которая бы лучше передавала смысл без двусмысленностей.
Подводя итог, можно сказать, что CSS, как один из ключевых элементов веба, имеет ряд исторически сложившихся и часто спорных решений, которые отражаются в повседневной работе разработчиков. Несмотря на это, сообщество и стандарты продолжают развиваться, стремясь исправить и улучшить многие из этих аспектов. Понимание проблем и ограничений позволяет создавать более качественные и удобные в использовании стили, а также формировать будущее веб-разработки с учётом допущенных ошибок и полученного опыта.
