HTML5: экспериментальный и готовый к использованию

Автор: Topol Среда, Май 2nd, 2012 Нет комментариев

Рубрика: Операционные системы

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

Сейчас, когда многие технологии HTML5 до сих пор находятся в стадии разработки, наш долг дать разработчикам возможность выбора и избежать ложных суждений вокруг поддержки стандартов. Браузер Internet Explorer 9 имеет встроенную поддержку HTML5 для разработчиков и потребителей. Мы также предлагаем программистам проект «HTML5 Labs» для доступа к экспериментальным технологиям, которые все еще находятся в разработке. С четким разделением этих технологий от основного продукта мы можем избежать многих негативных последствий.

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

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

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

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

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

Это взгляд со стороны на непростые решения в сфере технологий на стадии разработки, каков риск безопасности, ведь в любой момент ваш сайт может отказать в работе.

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

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

Комментарий #2 писал:
Ничего из этого не выйдет. Это только осложнит дело, ведь «Firefox до сих пор не реализовал полную поддержку HTML5″.

Следующий комментарий ссылается на все те же факты — нестабильность и проблемы с совместимостью в качестве аргументов для обсуждения с другого ракурса:

Комментарий #7 писал:
Мы добавим префикс, если будем уверены на 100%, что изменения только к лучшему. Мы в курсе того, что другие браузеры будут обновляться по мере выхода исправлений.

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

Другие комментарии ссылаются на другие прецеденты обоих путей развития действия, при этом отмечая «WebSockets не выйдет из статуса драфта еще в течение нескольких лет». Комментарий очень правильно раскрывает темпы внедрения новых технологий. Обсуждение продолжается и появляется очень циничное замечание «Тот, кто впереди, всегда найдет решение. Мы (Mozilla) постоянно ориентируемся на WebKit. Я уверен, мы не перестанем этого делать».

Ключевым моментом в обсуждении является тот факт, что разработчики могут ожидать некорректной работы своих серверов с реализацией новых версий WebSockets в браузерах. Сотрудник Google, работающий над WebSockets, добавляет, что лучшая стратегия — просто продолжать ломать стереотипы. Человек с Mozilla обеспокоенно отвечает:

Комментарий #27 писал:
Мы предполагаем, что разработчики будут иметь совершенные знания обо всем, что происходит в Интернете, каков статус различных стандартов и если что-либо изменится, какие у этого будут последствия. С учетом моего личного опыта это приводит нас к опасным предположениям.

Иногда кто-то поднимает вопрос безопасности, а другой человек делает замечание о том, что оно того в корне не стоит. Некто придерживается позиции обязательного соответствия стандартам и их следованию, на что следует ответ:

Комментарий #73 писал:

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

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

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

WebSockets является лишь одной из многих молодых технологий. Слишком быстрое развитие и вечно меняющийся план создают неудобства. Данное видео лишь драматизирует недовольство разработчиков. Это недовольство является результатом включения незавершенной технологии в состав выпущенного продукта.

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

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

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

Готовые к употреблению технологии будут отвечать нуждам разработчиков, жизнеспособные альтернативы также останутся в силе. CSS3 включает в себя огромное количество технологий, браузер IE9 уже заручился поддержкой готовых к употреблению функций. Некоторые составные CSS (например, CSS3 Gradients) до сих пор в стадии разработки, некоторые нашли для себя превосходную альтернативу, к примеру, использование скриптов вместо CSS3 Transitions и CSS3 Animations. Для прочих технологий эти правила также применимы. WebWorkers введет сложную многопоточную концепцию программирования JavaScript и потребует больше работы над прототипом (как в случае с WebSockets) для полного изучения модели веб-программирования и предпочтений разработчиков.

Есть множество технологий, которые могут пойти по тому же пути, что и WebSockets. Их место в прототипах, а не в готовом продукте, от которого сложится первое и самое важное впечатление. WebSockets и IndexedDB — это первые прототипы, вошедшие в данную программу. Некоторые экспериментальные составные CSS3 являются потенциальными кандидатами в прототипы, наряду с другими технологиями (например, File API). Этим процессом мы довольны и будем продолжать работать в том же духе с сообществом.

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

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

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

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

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

Еще в марте, когда мы выпустили предварительную версию IE9, мы поняли, как любим HTML5 и с каким рвением хотим сделать так, чтобы все работало. Один из аспектов — задействовать все ресурсы компьютера для исполнения HTML5 в целях лучшей производительности. Другой аспект — работа с сообществом и органами по стандартизации. Нам очень важно, чтобы разработчики не теряли время на бесконечное переписывание сайтов, так же как и потребители избежали трудностей при навигации.

Источник: thevista.ru

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

Чтобы оставлять комментарии Вы должны быть авторизованы.

Похожие посты