Перевод статьи Effective Standards Work, Part 1: The Lay Of The Land с сайта infrequently.org для css-live.ru, автор — Алекс Рассел
Нас слишком часто не устраивает процесс стандартизации в вебе. Этот цикл статей рассматривает, какие силы в этом участвуют, как мы улучшаем ситуацию, и как можно эффективнее направлять развитие новинок.
«Почему браузеры не соблюдают стандарты!» — задумчиво бормочет разработчик (заводя баг на chrbug.com). «Ведь смысл стандартизации — чтобы всё работало одинаково, в конце-то концов». Если что-то попало в Стандарт, то все его единообразно реализуют… верно?
Может быть. Из-за путаницы вокруг того, как создаются стандарты и интероперабельность, разгорались многие из худших споров, что я видел за свои ~12 лет в разработке новинок для веб-платформы.
Не все начинания с моим участием были удачными (напр. ES4). Наделав почти всех мыслимых ляпов, я заслужил почетную обязанность оберегать от подобных ошибок своих коллег, инженеров Chrome, в качестве «технического руководителя по веб-стандартам». Я не пишу об этом много, поскольку любое сказанное слово можно понять неправильно; в стандартах изначально замешано много «политических» вопросов. Но во имя прогресса я посчитал этот цикл из двух статей приемлемым риском.
Некоторые проблемы веба решаются на стороне пользователя. Некоторые требуют изменений платформы. По историческим и практическим причинам изменения веб-платформы должны фиксироваться в веб-стандартах. Этой нормы придерживаются и сообщество веб-разработчиков, и разработчики браузеров. Браузеры — товары взаимозаменяемые, и между ними немалая конкуренция. Как результат, у всех участников есть причины ценить совместимость и интероперабельность (переносимость кода). Разработчикам выгодно, когда благодаря интероперабельности у их продуктов и сервисов оказывается шире охват. Браузерам интероперабельность выгодна, поскольку пользователи отказываются от тех браузеров, в которых существующие сервисы и контент недоступны. Поэтому новинки должны двигаться в сторону стандартизации. На функции, внедренные без соответствующего предложения стандарта, глядят критически. Деловых людей, привыкших воспринимать «проприетарный» как что-то положительное, может поразить, насколько веб-сообщество ненавидит нестандартные функции.
Издалека со стороны может показаться, что всё новое «происходит» в W3C, или в WHATWG, или в ECMA, или в IETF. Некоторые предполагают, что новинки, стандартизируемые в этих организациях, в них же и возникли — что они изначально так и проектировались в ходе обсуждений в комиссиях. Если браузер реализует то, что говорит стандарт, то наверняка именно участием в работе над стандартом он и влияет на изменения.
Теория стандартов
На практике всё работает совсем не так, да и не должно так работать проектирование функциональности. Наоборот, новинки и модификации поступают в организации по разработке стандартов («ОРС») от разработчиков и создателей браузеров в виде продуманных предложений. Важно отделять проектирование от создания стандарта. Проектирование — процесс попыток решить проблему с помощью новой функциональности. Стандартизация — процесс документирования консенсуса.
Процесс разработки функциональности — это увлекательное исследование без плана и системы, и начинается оно там, где есть доверие и надежда. Для него нужно, чтобы те, у кого проблемы (веб-разработчики), и те, кто может их решить (разработчики браузеров), обсуждали всё больше и больше вопросов. Глубокое изучение пространства возможных решений — отбрасывая по пути негодные идеи десятками — это главное. Добиться согласия насчет постановки задачи — уже немалый труд. Формальные процессы стандартизации этим не занимаются.
Из-за скучных причин типа прав интеллектуальной собственности, антимонопольных законов и особенностей управления в ОРС, официальные рабочие группы (напр. в W3C) нередко заявляют о своих планах что-то выпустить за годы до того, как они действительно это выпустят. Некоторым ОРС нужны «признаки жизни» от потенциальных реализаторов (обычно 2 или больше), чтобы продвинуться дальше в своих рабочих процессах. У IETF для этого есть знаменитая формулировка «работающий код и приблизительный консенсус». Если делать всё правильно, то сначала надо предложить ясную постановка задачи и потенциальные решения, по ним должно быть хотя бы частичное согласие, и только ближе к концу процесса проектирования в дело вступают формальные стандарты.
Короче говоря: ОРС и их формальные рабочие группы на ранних стадиях проектирования функциональности ни при чем.
Они не могут сказать, решает ли предложенный вариант важную проблему, и хорошо ли он ее решает. Задача ОРС — утверждать форму спецификации и консенсус по поводу отдельных слов в ее тексте. Рабочие группы и ОРС не оценивают, подходит ли функция для своей задачи или нет.
Если проект прошел утверждение в комиссии, это почти ничего не говорит о его качестве. Многие достойнейшие и рассудительнейшие люди как один впадают в ярость, когда от этих процессов ждут предсказания будущего, а не документирования консенсуса. Без разработчиков, которые могут попробовать функцию в деле и дать обратную связь, рабочие группы быстро скатываются в неактуальность. Ну а кто укажет им, что они неправы? Там же работают эксперты, в конце концов!
Лучше всего воспринимать ОРС как усилители: они получают сырой входной сигнал, фильтруют его, чтобы он не разнес колонки и барабанные перепонки, если включить полную громкость, а затем с помощью своих процессов передают его. Откуда сигнал берется, этим процессам неизвестно.
Могу заверить, что такие истории не затерялись, но притягательного в них мало. Есть причины, по которым участники не рассказывают о них — надоевшие темы, фантомные боли от проигранных в шаге от победы споров и профессиональные обязательства перед другой стороной. Смелые документалисты иногда пытаются, но всё-таки драмы про стандарты — не самая захватывающая разновидность сюжета.
Когда о прошлом не рассказывают и опытом неудач не делятся, новичкам становится сложнее сориентироваться. Идее, будто «прогресс исходит из организаций по стандартам», противопоставить толком нечего, и ни одна ОРС не собирается отказывать новым членам. Некому сказать разработчикам, чтобы они не искали у ОРС готовых ответов. Царит путаница.
Расстановка сил
Проектирование функциональности начинается с исследования проблем, не зная ответов, тогда как участие в рабочих группах влечет за собой тщательное «просеивание» множества предложенных решений и включение лучших предложений в итоговый документ. Поздние итерации могут происходить и здесь, но любое изменение без обратной связи от разработчиков опасно — а в задачи рабочих групп не входит собирать такую обратную связь, тем более отдавать ей приоритет.
Даже когда консенсус в первом приближении достигнут, стандартные процессы не в силах заставить кого-либо что-либо реализовать, даже участников рабочей группы! Добровольные стандарты (преобладающие в компьютерном мире) — не предписания. Разработчики реализаций внедряют стандарты, поскольку клиенты требуют интероперабельности для защиты от рыночного произвола крупных игроков.
Это так важно, что можно повторять и повторять: факт появления чего-либо в веб-стандарте никого не обязывает к реализации, даже тех, кто реализовал предыдущую версию. Это вытекает из фундаментальных взаимоотношений между браузерами, разработчиками и пользователями.
Разработчики браузеров контролируют свои бинарники до бита, потому что необходимость угодить конечным пользователям для них превыше всего. Никак иначе безопасных, заслуживающих доверия браузеров не сделать. Стандарт может гласить, что window.open() создает новый контекст просмотра, но на практике браузеры блокируют попапы. Chrome даже формализовал эту идею «вмешательств».
Предотвращать злоупотребление — это одно, но, может быть, с новыми функциями всё иначе? Браузер может добавить десятки проприетарных возможностей, но если разработчики не примут их на вооружение, пользователям от них не будет толку. Частый критерий пригодности новинки для разработчиков — ее интероперабельность, под которой подразумевается «охвачу ли я всех нужных мне пользователей, если моему приложению потребуется эта функция?». Это значит, что разработчики часто отказываются использовать новинки, если те еще не появились во всех важных для них движках.
И наоборот, неподдерживающие браузеры видят в малоиспользуемых функциях скорее затраты, а не потенциальную выгоду. Это особенно так, когда альтернатива — улучшить производительность существующей функции. Для разработчиков браузера верный способ заслужить похвалу — улучшить работу существующего контента, и тем самым напрямую помочь пользователям, выбравшим ваш браузер. Другими словами, менеджеры интуитивно предпочитают заведомо беспроигрышные улучшения своих продуктов, а не умозрительные нововведения, от которых конкуренты могут выиграть не меньше (а то и больше). Просветленные мудрецы, думающие обо всей экосистеме — редкость, хотя несколько их недавно осчастливили веб своим присутствием.
Наконец, хотя это и немаловажно, дефицит солидарности становится угрозой для всей отрасли. Разработчики браузеров не зарабатывают на жизнь созданием сайтов, так что внутренних стимулов улучшать ситуацию у них тоже нет. Отсюда тянутся корни многих эпических битв в веб-стандартах за продвижение «очевидно» недостающей функции.
Примечание: когда у пользователей нет фактического выбора движка, напр. на iOS, вся экосистема ломается. Без нормальной конкуренции ничто не мешает игрокам урезать вложения в структуру, и платформа становится менее динамичной и хуже отвечает потребностям. При этом теряют все, но это классические чистые издержки, отчего их так трудно распознать и обратить на них внимание.
Этот статус-кво трудно переломить. У каждого игрока есть весомые (если пустить их в ход) причины не реализовывать новинки. Каждый из них может стопорить прогресс, пока не окажется последним (или предпоследним, если игроков в экосистеме 4 и больше), кто ее еще не реализовал. До этого момента не видно и жалоб разработчиков, и очень легко нагнетать страхи и сомнения по поводу еще не прижившейся новинки, при этом не собираясь ее реализовывать (этакое «тихое вето»). И более того, зарубать идеи, удачность которых не очевидна и которым не хватает движущей силы — одна из задач ОРС и формальных рабочих групп.
На вид эта ситуация, пожалуй, безнадежна. Медленный прогресс многих важных, но слишком уж затянувшихся улучшений (отзывчивые изображения, CSS-переменные, ES6-классы, промисы и async/await, веб-компоненты, потоки и т.д.) поневоле заставит любого вменяемого наблюдателя задуматься. Стоит ли и пытаться?
Огромное положительное влияние, меняющее всю веб-платформу, вселяет в меня веру, что ответ будет «Да». Во второй части я поделюсь подробностями о том, как команда Chrome научилась по-новому думать о разработке функциональности и стандартов и как это поможет ускорить прогресс всему веб-сообществу.
Читайте часть 2, «Трудный путь к компромиссу»
Сердечные благодарности Эндрю Беттсу, Брюсу Лоусону и Марико Косаке за вычитку черновиков и исправление многих из моих бесчисленных ошибок.
P.S. Это тоже может быть интересно:
