МаCSSаракш. Размышления о стандартах CSS

Пролог, или Невероятное происшествие в парижском бюро мер и весов

Представьте ситуацию: вы приходите в магазин и просите килограмм муки. Продавец с порога огорошивает вас новостью, что вчера в международном эталоне килограмма была обнаружена неточность, поэтому, пока эталон уточняется, с сегодняшнего дня все переходят на старинные фунты и пуды. Вы, чертыхаясь, достаете калькулятор, пересчитываете килограмм в фунты, отвешиваете эту жуткую дробь и идете домой готовить пирог. Когда пирог уже готов, выясняется, что ваш калькулятор считал в русских фунтах, а продавец использовал английские — и рецепт оказался безнадежно испорчен. Вы идете в магазин ругаться (почему вам не уточнили, в каких фунтах надо было считать) и… видите в руках у продавца новенькие гири с маркировкой «1 килограмм»! Но по виду похожие на «дореформенные» пятикилограммовые.

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

Почему же не менее бредовые истории оказались возможны в вебе?

У веба ведь тоже есть свои стандарты. Или… не совсем стандарты?

1. Веб-стандарты: позвольте отрекомендовать?

Все веб-разработчики знают, что стандарты для веба создает специально обученная организация — W3C (WWW Consortium, Консорциум Всемирной Паутины). Продвинутые (по их собственному мнению) веб-разработчики знают, что «верстать по стандартам — хорошо, а не по стандартам — плохо», и что валидатор на сайте этого самого W3C «светится зеленым», когда «всё по стандарту». Продвинутые (по мнению опытных коллег) веб-разработчики знают, что на этом же сайте выложены спецификации почти всех веб-технологий, и именно в них объясняется, почему браузеры ведут себя так, как ведут. А если браузеры ведут себя по-разному — то кто из них прав, а кому пора отсылать багрепорт. Действительно продвинутые веб-разработчики (в природе почти не встречаются) какие-то из этих спецификаций даже читали:)

Вот страничка «All Standards and Drafts» — «Все стандарты и черновики». Подвоха пока не видно. Зато видно, что спецификаций действительно много — они даже разбиты по темам. Нас интересует подраздел «CSS». Раскроем его…

Вот так сюрприз! Под шапкой «законченная работа» видим две категории: «Рекомендации» и «Заметки группы». Ниже — черновики разной степени готовности: просто «Черновик», загадочный «Последний звонок» (с грозной пометкой крайнего срока рядом), «Кандидат в рекомендации»… В самом низу — устаревшие и отмененные документы, в основном датированные далекими 1990-ми. А где же, собственно, стандарты?

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

А впереди будет еще «страньше и чудесатее». Но прежде чем продолжать удивляться, давайте немного помечтаем.

2. Мечты об идеале

Чего логично ожидать от стандарта какой-либо технологии? На мой взгляд (не претендую на окончательную истину):

  1. Надежности и предсказуемости. Стандарт должен храниться в одном и том же месте и не должен меняться внезапно. Любые изменения должны легко отслеживаться. И не затрагивать того, что работает — без мегакрайней необходимости.
  2. Универсальности. Стандарт должен быть один для всех. На то он и стандарт.
  3. Реалистичности. Стандарт не должен содержать «взаимоисключающих параграфов», выдвигать абсурдных или заведомо невыполнимых требований.
  4. Актуальности и расширяемости. Нужна возможность оперативного включения в стандарт новых требований отрасли, путем выпуска новых версий, добавления новых модулей и т.п. Механизм перехода со старой версии на новую должен быть четким, прозрачным и безвозвратным. Новую версию должна в будущем сменять лишь еще более новая, а не «ожившая» старая (последнее кажется очевидным, но… похоже, не для W3C!).
  5. Открытости. Разработчики стандарта должны прислушиваться к мнениям и потребностям тех, кто непосредственно работает с этой технологией. Приоритеты в разработке стандарта должны диктоваться именно этим.

Если вы не согласны с этим списком (наверняка же я что-то упустил или что-то переоценил) — добро пожаловать поспорить в комментах! А пока вернемся к нашей реальности.

3. Жизненный цикл спецификации CSS

Внутри своей рабочей группы (в нашем случае — рабочей группы CSS) работа над спецификацией ведется всё время — от появления идеи до публикации окончательной редакции. На ее страничке «Текущая работа» можно оценить общее состояние дел, а все черновые варианты, над которыми идет работа в данный момент, можно найти здесь.

А «для всего мира» спецификация W3C начинается с того, что рабочая группа выкладывает на сайт W3C первый публичный черновик (Working Draft, WD). Этот черновик уже можно обсуждать, вносить предложения по улучшению и решению спорных вопросов (в черновиках обычно много пометок красным — это они), предлагать свои альтернативы и т.п. Участвовать может любой желающий — достаточно написать письмо на www-style@w3.org.

На стадии WD могут начинать экспериментировать с реализацией этой фичи и браузеры. На этой стадии нужны префиксы — чтобы разные экспериментальные реализации не пересекались и друг другу не мешали.

По мере «взросления» черновика публикуется несколько промежуточных версий, всё более подробных и проработанных, с всё меньшим количеством красного текста. Порой сам синтаксис фичи много раз меняется, и браузерам, успевшим реализовать старый вариант, приходится переделывать реализацию чуть ли не с нуля (поэтому браузеры часто подолгу тянут с внедрением фичи, если только не они сами ее предложили). Но статус у всех этих промежуточных редакций один и тот же — WD, черновик. Что у самого первого (фактически «голой» идеи), что у того, который уже на 90% готов!

Наконец, когда вся рабочая группа CSS решает, что все спорные вопросы улажены и теоретически спецификацию можно считать готовой, она выпускает особую версию черновика — с пометкой, что это планируется его окончательная редакция, и указанием крайнего срока, до которого еще можно вносить замечания и уточнения. Такое «последнее китайское предупреждение», что кто не успеет со своими возражениями — тот опоздает. Как третий звонок в театре. Поэтому эта стадия называется Last Call Working Draft (LCWD) или просто Last Call (LC), что можно перевести как «последний звонок» (хотя точнее по смыслу — финальный черновик).

Сроку «подумать» после «последнего звонка» дают месяц-два. То ли ради перестраховки, то ли из-за бюрократии W3C обычно накидывает еще месяцев пару. После этого спецификация получает самый важный, пожалуй, статус — кандидат в рекомендации (Candidate Recommendation, CR). Это значит, что спецификация готова фактически, и браузеры могут смело ее реализовывать. Без всяких префиксов! А кто реализовал с префиксами — просто убирать их.

Когда минимум два браузера независимо друг от друга реализовали спецификацию, и эти реализации оказались полностью совместимы (а чтобы проверить совместимость реализаций, требуется разработать официальные наборы тестов), спецификация получает следующий статус — предложенная рекомендация (Proposed Recommendation, PR). И наконец, когда предложенную рекомендацию утвердит W3C-шное начальство, спецификация публикуется в окончательном статусе — рекомендация (Recommendation, Rec). По установленному в W3C рабочему процессу «рекомендация аналогична стандартам, публикуемым другими организациям».

Т.е. у W3C рекомендация — это и есть стандарт. После этого спецификация уже не меняется. Она может лишь устареть и со временем замениться новой.

Казалось бы, логичная цепочка. Пока спецификация в процессе разработки — она черновик, когда практически готова или совсем готова — она «почти стандарт» или «совсем стандарт». Но это в теории. А на деле нередко бывает так, что спецификация оказывается забракована уже на стадии CR. На которой браузерам можно внедрять ее без префиксов. И спецификация «откатывается» назад в LC («совсем последний» черновик). Когда внедрять без префиксов еще нельзя. Иногда такая чехарда CR LC CR и обратно происходит несколько раз. И «фичи», вроде бы давно признанные готовыми, внезапно опять формально оказываются экспериментальными!

Самый впечатляющий, пожалуй, пример — CSS Basic User Interface Module Level 3 (CSS3 UI). С января 2012 года его статус — финальный черновик (LC), хотя до того он был кандидатом в рекомендации (CR) аж с… 2004-го года! И это не исключительный случай.

4. Версии о версиях

CSS 2.1 — последняя «монолитная» спецификация CSS. До нее были CSS 1 (до сих пор числится в «рекомендациях», но последняя редакция 2008 года предостерегает от нее в пользу CSS 2.1) и CSS2 (которую CSS 2.1 заменила). Спецификации под названием «CSS3» нет! Начиная с CSS 2.1, весь CSS разрабатывается не версиями, а «уровнями»: основа (сам CSS 2.1) считается 2-м уровнем, над которым надстраиваются функциональные модули сначала 3-го уровня, а затем 4-го (напр. модуль селекторов 4-го уровня, поскольку селекторы 3-го уровня — уже готовый стандарт) и последующих уровней. Причем развиваться они могут с разной скоростью, например, когда до CR «дозреет» модуль таблиц 3-го уровня (пока даже не написанный!), те же селекторы могут «прокачаться» уровня до 7-го. Так что сам по себе уровень модуля не говорит о его готовности ничего. И есть ли какой-либо смысл в «валидации CSS3» (проверке, входит ли свойство в словарь, определенный в модулях 3-го уровня), если часть этих модулей уже давно стандарт и вот-вот устареет, а часть еще не написана вообще?

Модули, добавляющие в CSS принципиально новую функциональность (напр. расширяющие сам базовый синтаксис) пристраиваются не «поверх», а «рядом» — с самого базового уровня, 1-го. Таков модуль CSS-переменных 1-го уровня. Да-да, не все модные новинки — «CSS3»! (Хотя… смотря что понимать под «CSS3» — см. добавление ниже.)

Что же мы имеем в итоге? Номер уровня — не показатель ни актуальности, ни готовности стандарта. Статус спецификации — показатель, но недостаточно надежный и информативный. Как же узнать, что является действующим и актуальным стандартом CSS на текущий момент?

Ближе всего к искомому — документ, лежащий по красивому адресу http://www.w3.org/TR/CSS/: «снимок», или «срез» CSS (CSS snapshot). Правда, сейчас там документ 2011 года, отражающий состояние дел 2010-го. И статус у него самый несерьезный — «заметка» (Working Group Note). Т.е. просто «пометки для себя». Так в W3C помечают то, что в стандарты не прошло и на это звание даже не претендует — грубо говоря, «отходы» процесса стандартизации. А жаль…

Вот и приходится следить за уже знакомой нам «Текущей работой». То, что в первых трех табличках зелененькое (и не собирается «желтеть», как было с упомянутым CSS3 UI) — скорее всего, можно считать если не стандартом, то наиболее близким к нему.

Добавление от 7.09.2012: буквально на следующий день после публикации этой статьи произошел показательный случай. Таб Аткинс, один из активистов рабочей группы CSS, написал в своем блоге заметку о CSS4, главная мысль которой — никакого CSS4 нет и не будет. На беду, в этой же заметке он написал, что «термин “CSS3” относится ко всему, выпущенному после CSS2.1», на что сразу же получил немало гневных возражений от других активистов рабочей группы CSS (в частности, от Сильвена Галино, по мнению которого «“модуль фонов и границ 4-го уровня относится к CSS3” — звучит как пьяный бред»). Если эта безверсионно-уровневая система приводит к такой путанице среди самих авторов спецификаций — представляете, каково же простым веб-разработчикам?..

5. Есть ли другой путь?

В принципе, есть. Это путь WHATWG, которым идет развитие «живого стандарта HTML», параллельно с HTML5 в W3C (хотя с недавних пор их пути начали расходиться). «Живость» стандарта означает то, что он в любой момент и готов, и не готов: ничто не мешает браузерам реализовывать спецификацию прямо в том виде, как есть (без всяких префиксов), но и ничто не заставляет их реализовывать сразу всю спецификацию целиком. Как следствие — никто не может гарантировать, что хотя бы 80% браузеров поддержат хотя бы 80% спецификации. И узнавать фактическое положение дел с поддержкой браузерами той или иной части стандарта придется на сторонних сайтах типа caniuse.com.

В чем этот путь точно превосходит W3Cшный процесс, так это в актуальности: спецификация всегда новейшая. Настолько, что реализация даже месячной давности может внезапно оказаться устаревшей (были прецеденты). С надежностью и предсказуемостью тут… так себе. И можно понять сопредседателя рабочей группы CSS, который резко возражает против перевода всей разработки CSS на этот путь. Особенно с учетом того, что в CSS сейчас и так куча модулей, разрабатываемых независимо, и редакторам спецификаций приходится прилагать немало усилий, чтобы согласовать эти модули друг с другом.

Но и у тех, кто критикует теперешний процесс W3C за медлительность, есть веские резоны. Если W3C не выпускает стандарт де-юре, браузеры создают его де-факто — прогресс не стоит на месте, новинки внедряются в каждом релизе, а релизы нынче чуть ли не ежемесячно. И если в начале 2000-х «вылизывать» спецификацию годами, сглаживая «острые углы» и противоречия, было еще кое-как можно, то теперь это равнозначно тому, что место общего единого стандарта займет «отсебятина» лидера гонки. Такое мы уже видели в 90-х, в эпоху господства IE. Что ни говори, но 13 лет «утряски» спецификации CSS2.1 (c 1998 по 2011-й!) — очевидный перебор. Веб столько терпеть не станет. А объемы спецификаций только растут…

Но поспешность в таком деле, как разработка стандартов, тоже вредна. Не поспеши W3C в 1998-м году утвердить спецификацию CSS2 — заведомо нереалистичную, от которой тут же отказались все браузеры — возможно, не пришлось бы 13 лет доводить ее «до ума».

6. А что, если…

…как-нибудь соединить обстоятельность и основательность W3Cшного процесса с оперативностью и динамизмом «живого стандарта»?

Вот вышеупомянутый «слепок» CSS — тот самый, который в «текущей работе» помечен как «новейший стабильный CSS» —  что мешает ему стать «живым стандартом»? По большому счету это просто список модулей, признанных рабочей группой достаточно «созревшими» для реализации браузерами. Факт наличия модуля в этом списке важнее формального статуса самого модуля: даже если модуль откатился из кандидата в рекомендации к «последнему звонку», разработчиков браузеров это не запутает. Там же можно будет прояснить подлинный статус формально «готовых», но фактически устаревших модулей (как с тем же CSS3 UI) и перечислить «рискованные» фичи. И будет всё актуальное состояние CSS доступно по одному адресу — как, наверное, и планировалось!

Что-то подобное уже давно происходит со спецификацией WCAG 2, у которой есть статичная «основная часть» и постоянно обновляемые практические рекомендации, развивающиеся вполне по логике «живого стандарта». Оправдан ли такой подход для CSS? Добро пожаловать в комменты с любыми мнениями и аргументами!

P.S. Это тоже может быть интересно:

5 Комментарии

  1. psywalker

    Илья, спасибо за статью! 

    Самое обидное, что на полках пылятся, как правило, те модули, которые неинтересны браузерам с точки зрения спроса и поэтому они стремсятся реализовать только "модные" фичи, которых требует конечный пользователь, а о веб-разработчиках совсем не заботятся:( Я говорю о модулях раскладок, которые очень помогли бы верстальщикам в их ремесле. 

  2. cyber_ua

    когда читаеш спецификацию возникает ощущение что:

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

    потому что иногда когда ее читаешь , просто повесится хочется, в данный момент говорю про js , так как css спецификацию открываю редко.
    Иногда даже поиск по сайту w3c это настоящий хардкор.

    1. SelenIT (Автор записи)

      По стандарту JS в свое время отлично проехался Дуглас Крокфорд (правда, по иронии судьбы, за этот стандарт отвечала другая организация хомячков — JS всё-таки не только для веба). Справедливости ради, к 5-й редакции (во многом усилиями того же Крокфорда) из него вылепили что-то более-менее пристойное.

      Но c W3C, начиная с юзабилити сайта и заканчивая ориентацией в горах отменяющих и переопределяющих друг друга спек с одинаковым формальным статусом (я уж молчу о навигации по архивам рассылки www-style и пр.) — это действительно «не для слабонервных» :)

      1. cyber_ua

        обычно стараюсь использовать https://developer.mozilla.org/en-US/  , но блин в прошлый раз когда я лазил по w3c моя клава чуть не вылетела через окно=)
        P.s щас начал учить C# , блин даже в microsoft свою спецификацию сделали читабильной , мало того еще и перевели…

  3. SelenIT (Автор записи)

    Занятно, что со времени публикации статьи утекло столько воды, что поменялся сам рабочий процесс W3C — с августа 2014-го статус Last Call («последний шанс для обратной связи», который в статье в шутку переведен как «последний звонок») фактически упразднен и совмещен со статусом кандидата в рекомендации (так что вместо чехарды LC—CR—LC будет несколько итераций CR). Правда, некоторые спецификации по инерции еще пишутся по старому процессу. Но вот путаница между уровнями модулей и «версиями» осталась, те же селекторы 4-го уровня массово популяризируют как «CSS4». А вот документ по ссылке http://www.w3.org/TR/CSS/, к сожалению, так и не изменился…

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Получать новые комментарии по электронной почте. Вы можете подписаться без комментирования.