HTML5, готовый для применения и экспериментальный

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

При наличии многих, все еще активно развивающихся технологий HTML5, наш подход состоит в предоставлении разработчикам лучшего выбора и в исключении ситуации «выбора из двух зол» при определении поддерживаемых стандартов. В браузер IE9 включена поддержка той части HTML5, которая готова для применения в сайтах и от которой зависят разработчики и пользователи. Также мы предложим разработчикам сайт «HTML5 Labs» для знакомства с экспериментальными технологиями, все еще находящимися в стадии разработки. Четко отделяя прототип реализации от основного обозревателя, мы можем избежать многих негативных последствий.

В продукте IE9 мы предлагаем ключевые компоненты HTML5, которые готовы для применения на сайтах. IE9 предоставляет поддержку веб-шаблонов реального мира, которые разработчики используют сегодня, а также шаблоны HTML5, которые, как мы ожидаем, скоро будут широко использоваться. Это сделано потому, что мы хотели бы исправить совместимость в веб, обеспечивая разработчиков согласованной моделью программирования с единой разметкой. Целью же является поддержка новых замечательных возможностей, которые в идеальном случае совместимы или скоро будут совместимы со всеми браузерами.

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

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

WebSockets

Прежде всего, WebSockets– хорошая идея.

Это одновременно и технология и разрабатываемый набор стандартов. Эта технология зачастую включается в обсуждения HTML5. C помощью WebSockets можно делать некоторые изящные вещи, которые другим способом сделать очень трудно, очень медленно или же вообще невозможно. Видео с некоторыми допустимыми сценариями можно найти на сайте http :// www . websockets . org / , который не имеет отношения ни к одной организации, работающей над стандартом, а принадлежит компании, предложившей эту технологию.

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

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

Взгляните на ошибку номер 602028 в Bugzilla, системе отслеживания проблем компании Mozilla. Для людей, не интересующихся деталями, самое время пропустить часть текста до следующего раздела.

Впервые об этой ошибке было сообщено 5 октября 2010 г. Первоначально ошибка предлагала что «пока в окончательном протоколе WebSockets не устранены проблемы» Firefox должен ввести «задание префиксов». В одном из первых комментариев по этой ошибке немедленно была зафиксирована позиция (несогласия), выявлены проблемы совместимости, с которыми столкнутся разработчики, создавая сайты, работающие со многими браузерами по технологии, находящейся в стадии разработки:

Безусловно нет… Задание префиксов в Gecko никому ничего не даст… Это только причинит вред, так как «Firefox не реализует HTML5». Комментарий 2

Последующий комментарий ссылается на те же факты – проблемы неустойчивости и совместимости – как на аргумент в обратном направлении.

Причина, по которой мы хотим ввести префиксы, состоит в том, что мы на 100 % уверены, что они изменяться. Мы также знаем, что в других браузерах они также будут модернизированы. Нам бы не хотелось, чтобы их путали с… чем-то не являющимся экспериментальным и лучший способ сделать это – добавление префиксов.

Эта новая версия не будет совместима с существующими реализациями. Комментарий 7

Другие комментарии продолжают ссылаться на прецеденты для обоих образов действий (здесь и здесь), добавляя «WebSockets не выйдет из состояния демонстрационного ПО в течение нескольких лет». Это веский комментарий о темпе принятия технологии. Обсуждение продолжается несколько цинично: «представление того, кто-на-верху, может побить все иные соображения… Мы [Mozilla] … постоянно глотаем пыль WebKit. Я бы держал пари, что так выйдет и на этот раз».

Ключевым моментом обсуждения является то, что разработчики «ожидают, что их серверы [sic] разрушаться, когда новые версии WebSockets будут реализованы в браузерах». Сотрудник Google, работающий над WebSockets продолжает: «наилучшей стратегией является просто сохранение первопроходцев». Работник Mozilla отвечает своей обеспокоенностью, что при этом

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

Это происходит, когда кто-то поднимает проблему безопасности, а другой делится наблюдением, что это может не иметь значения «если можно сбросить флаг “поддержка HTML 5” на маркетинговых слайдах». Первый продолжает, что стандарт необходимо создать и что они должны следовать ему, на что другой отвечает:

Это будет великолепно. За исключением того, что пока нет стандарта, а только серия рабочих черновиков, с несовместимыми протоколами установки связи, и отсутствием плана … который просто не является причиной для серверов, использующих старые протоколы установки связи наплевать на новые. Комментарий 73

Негативные последствия

Во-первых, работа над WebSockets сегодня продолжается и Microsoft участвует в обсуждениях. Никто не должен трактовать последние новости, как конец WebSockets.

В одной технической публикации утверждается, что «история WebSockets иллюстрирует некоторые подводные камни стиля и темпа разработки веб-стандартов», и что «включение поддержки спецификации [которая] не готова» это просто последнее препятствие. В заголовке статьи говорится о «риске незавершенных стандартов», в то время как другая статья говорит об «начинающих существование стандартах WebGL и WebSockets», а комментарий от руководителя Mozilla здесь ссылается на «умозрительные возможности».

WebSockets – это просто одна из многих и многих незавершенных, развивающихся и теоретических технологий. Поспешность с реализацией, когда эскизы сильно меняются, создаст чувство неудовлетворения. Это видео (предупреждение: оно содержит ненормативную лексику) инсценирует ситуацию с недовольством разработчика. Это недовольство является результатом поддержки незавершенных, развивающихся и теоретических возможностей основным продуктом.

Вопрос заключается в том, как найти баланс реализации этих разрабатываемых технологий (для того, чтобы решать проблемы разработки) с потребностями веб-разработчиков (которые не хотят переписывать код снова и снова, чтобы получить новые возможности), и с потребностями пользователей (которые ожидают, что сайты и браузеры будут просто работать). Сегодня iPhoneи iPad 4.2 поддерживают WinSockets. Firefoxи Operaнедавно отключили свои реализации из-за (среди прочего) вопросов безопасности и совместимости.

Альтернативный подход, так как WebSockets не единственная технология

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

Существует множество других разрабатывающихся технологий, которые далеки от завершения. Так как они на сегодняшний день не готовы и, соответственно, не будут готовы к тому моменту, когда мы выпустим IE9, эти развивающиеся стандарты будут восприимчивы к таким же проблемам и негативным последствиям, с которыми столкнулась технология WebSockets. Некоторые технологии находятся в переходном состоянии и приводятся в соответствие с другими (или от них отказываются в пользу других). Анимация SMIL и SVG-шрифты, хотя и используются в тестах Acid 3, близки к вылету в пользу CSS-анимации и WOFF-шрифтам. Спецификация WebSQL, например, была снята со стадии рекомендации на самой последней конференции TPAC в связи с выходом IndexedDB, как более перспективной. IndexedDB сама находится в стадии развивающегося и незавершенного стандарта, наряду с WebSockets, File API и WebGL (как замечено в упоминавшейся выше статье Ars Technica).

Готовность к применению на сайтах рассматривается в широком контексте потребностей разработчиков сегодня и завтра, жизнеспособных альтернатив, а также процесса становления стандарта. Например, CSS3 содержит огромный набор технологий. IE9 уже реализует многие модули CSS3, готовые к применению. Некоторые другие CSS-модули (например, градиенты CSS) пока еще развиваются и не завершены. У других модулей есть великолепные альтернативные варианты, имеющие возможности по взаимодействию, подобно использованию сценариев вместо CSS3 Transitions и CSS3 Animation. Для других технологий, таких как web workers, также применимы другие соображения. Технология web workers вводит понятия сложного многопоточного программирования в JavaScript, и требует всестороннего прототипирования (так же, как и WebSockets) для полного изучения влияния на разработчиков и расширенную модель веб-программирования.

Многие технологии могут легко пройти путь WebSockets. Разработчикам и пользователям лучше отойти от дел, если эти технологии выдвинуться вперед как явные прототипы, а не в продукте, от которого зависит множество людей. WebSockets и веб-хранилище IndexedDBявляютсяпервыми прототипами в новой программе. Некоторые экспериментальные CSS3- модули являются возможными кандидатами на прототипы, наряду с другими технологиями (например, FileAPI). Это процесс, в котором мы рады участвовать вместе с сообществом.

Заглядывая вперед

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

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

IE9 предлагает поддержку наиболее существенных веб-шаблонов из реального мира, которые разработчики применяют сегодня, а также шаблонов HTML5, которые, как мы ожидаем, станут широко использоваться. По значимости и применимости в реальном мире мы отбираем технологии с самым широким влиянием на пользователей браузера (т.е. CSS перед MathML). По поддержке мы отбираем обеспечение разработчиков последовательной моделью программирования, которая допускает такую же разметку. Цель – обеспечить новые замечательные возможности способом, который, в идеале, гарантирует или скоро сможет гарантировать одинаковое функционирование во всех браузерах.

Такой подход (вместе с поддерживающими его вопросами, вроде наборов тестов и «той же разметки» как цели) получил серьезную поддержку разработчиков. Он также привел к некоторым удивительным заголовкам новостей в прошлом году, подобных «Только Microsoft обеспечивает веб-стандарты» в статье «Сотрудник Mozilla, который проклял Apple и Google за надругательство над HTML5» издания The Register.

В контексте незавершенной технологии, измерения того, насколько различные браузеры поддерживают HTML5 с помощью тестов производительности, не дают точного представления. В частности многие из этих тестов (например, Acid 3) включают разные частичные коллекции незавершенных стандартов, при том, что они исключают глубокие или широкие оценки качества реализации. Ключевыми вопросами для тестов являются, как задать границы, насколько точными и строгими являются индивидуальные тесты, насколько полным является покрытие. Тела стандартов, находящиеся в процессе разработки (подобно W3C и ECMA) являются замечательной площадкой для разработки надежных, высококачественных тестов.

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

Возвращаясь в март прошлого года, когда мы выпустили первую предварительную версию платформы IE9, можно сказать, что нам уже тогда было ясно, что технология HTML5 понравилась так сильно, что мы захотели, чтобы она действительно заработала. Один из аспектов включает использование всех возможностей ПК для рендеринга HTML с наилучшей производительностью. Другим аспектом является работа с сообществом и телами стандартов для наборов тестов. Создание уверенности, что разработчики сумеют избежать разочарования от потраченного понапрасну времени на переписывание сайтов снова и снова при появлении технологических изменений, а пользователи сумеют избежать разочарований от сайтов, которые легко выходят из строя, и есть самое важное.

Спасибо,

Дин Хачамович (Dean Hachamovitch)