Компьютерра: Компьютерра PDA N104 (26.03.2011-01.04.2011)

Как правило, считается, что стандарт в статусе Working Draft (WD) является нестабильным, неокончательным и может меняться на основании отзывов от индустриальных экспертов и производителей браузеров. Могут быть и исключения, связанные с особенностями того или иного стандарта. Например, спецификация HTML5 очень большая и отдельные её части достаточно стабильны, а какие-то детали ещё обсуждаются. Есть примеры, когда стандарт "откатывается" до предыдущего статуса по процедурным особенностям, как это происходит с CSS 2.1, который тоже формально находится в статусе WD (Last Call). Бывает так, что развитие стандарта прекращается в пользу другого, как это случилось с WebSQL Database.

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

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

Но когда на арену выходит маркетинг, появляются нюансы. Оказывается, что для продвижения (или давления на конкурентов) выгоднее говорить, что браузер X поддерживает технологию Y, нежели что браузер X поддерживает экспериментальную технологию Y или что браузер X экспериментально поддерживает технологию Z - смотря в каком месте вы хотите расставить акценты.

Возьмите, к примеру, File API. Штука, безусловно, замечательная. Удобно ли обвинять IE9 в том, что он не поддерживает этот стандарт? Конечно, удобно. Надо ли при этом говорить, что стандарт находится на раннем этапе развития, в рабочих группах активно обсуждаются отдельные детали (вплоть до переименования и изменения методов) и что не следует ввязываться в создание промышленного решения, базирующегося на текущей реализации в том или ином браузере, то есть, скорее всего, его придётся переделывать при следующем обновлении? Об этом можно и умолчать. Маркетинг же.

Я стараюсь хорошо думать о людях, и мне хочется верить, что когда кто-то говорит о том, что IE9 не поддерживает, скажем, Web Sockets, то он действительно опечален этим фактом, так как для его конкретного приложения предоставляемый функционал был бы чрезвычайно удобен. Могу ли я на это рассчитывать? И стоит ли, утверждая поддержку веб-сокетов в браузере X, также говорить о том, что для их работы нужно проделать несколько фокусов с настройками (а всё потому, что в этом браузере, возможно, веб-сокеты были выключены для обычных пользователей из-за обнаруженных потенциальных уязвимостей в протоколе)? Может быть, также, говоря о поддержке нового стандарта, стоит указывать все случаи изменения протокола несовместимым образом? Наверное, стоит. Но ведь можно же и умолчать.

И, кстати, для IE9 есть экспериментальная реализациявеб-сокетов.

Я бы мог и продолжить. Например, ведётсяочень интересное обсуждение текущего состояния AppCache (Offline Web Applications). Но мне бы очень не хотелось, чтобы всё это воспринималось как попытка оправдать IE9 в том, что он что-то поддерживает, а что-то нет.

Вопрос не в конкретных стандартах или их количестве, а в общем подходе.

Давайте начнём с обратного: почему браузер X вдруг начинает поддерживать технологию Y? Ответ можно сформулировать по-разному, но в целом он, скорее всего, сводится к тому, что производитель браузера X посчитал технологию Y важной и перспективной. (Без уточнения, что считать важным и что перспективным, ладно?)

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

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

В какой-то степени на важность и востребованность влияет маркетинг. Когда кто-то (или многие) начинает очень громко кричать, какой он молодец, что сделал что-то очень классное, а другие производители не очень хорошие, потому что этого не сделали, волей-неволей маркетинговые ребята приходят к разработчикам и говорят, что "надо".