Коллектив Авторов - Цифровой журнал «Компьютерра» № 62 Страница 4

Тут можно читать бесплатно Коллектив Авторов - Цифровой журнал «Компьютерра» № 62. Жанр: Компьютеры и Интернет / Прочая околокомпьтерная литература, год неизвестен. Так же Вы можете читать полную версию (весь текст) онлайн без регистрации и SMS на сайте Knigogid (Книгогид) или прочесть краткое содержание, предисловие (аннотацию), описание и ознакомиться с отзывами (комментариями) о произведении.

Коллектив Авторов - Цифровой журнал «Компьютерра» № 62 читать онлайн бесплатно

Коллектив Авторов - Цифровой журнал «Компьютерра» № 62 - читать книгу онлайн бесплатно, автор Коллектив Авторов

Все говорят, что поддерживают HTML5, CSS3, различные API для JavaScript и другие интересные технологии. Некоторые кивают на других, указывая, что те что-то не поддерживают, выставляя себя в выигрышном свете.

И это даже может быть правдой, но, как говорится, не всей правдой.

Статусы, эксперименты и изменения

Прежде всего, веб-стандарты могут иметь разные статусы (Working Draft, Candidate Recommendation, Proposed Recommendation, W3C Recommendation). Тот или иной статус не делает стандарт менее или более стандартным. Ключевой вопрос — в стабильности и подверженности изменениям.

Как правило, считается, что стандарт в статусе 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? Ответ можно сформулировать по-разному, но в целом он, скорее всего, сводится к тому, что производитель браузера X посчитал технологию Y важной и перспективной. (Без уточнения, что считать важным и что перспективным, ладно?)

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

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

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

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

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

Экспериментальный набор функций должен реализовываться как экспериментальный, и я уверен: команда IE будет продолжать работу в этом направлении (см. HTML5Labs). Стабильный функционал будет становиться доступным в массовом продукте.

И ещё раз, так сказать, рефреном. Производители браузеров, безусловно, должны экспериментировать, делать пробные реализации новых стандартов, предлагать новые идеи и быть одним из двигателей развития веба. Должны ли все-все-все производители экспериментировать над каждым из стандартов? Вряд ли. Должны ли все-все-все производители реализовывать действительно важные и востребованные стабильные спецификации? Уверен, что да.

Качество поддержки стандартов

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

Вопрос, собственно, в следующем: когда кто-то начинает говорить, что он поддерживает стандарт Y, что он на самом деле имеет в виду? Что он начал реализовывать поддержку и что-то ещё может не работать или работать не так? Что реализовал полную поддержку? Что реализация будет работать на всех компьютерах одинаковым или сходным образом (и вообще будет работать)?

Попробуйте узнать, насколько ваш любимый браузер поддерживает CSS 2.1. Или почему различные браузеры, заявляющие поддержку Canvas, показывают различные результаты.

И дело тут не в том, кто круче, потому что крутость — понятие относительное и зачастую измеряемое неадекватными измерителями, вроде html5test.com или теcтов ACID.

Всё дело в совместимости, в идеале; у всех конечный результат должен совпадать. Проверить это и добиться этого можно только обширным согласованным тестированием. Важно, что такая работа ведется в W3C, — например, для CSS 2.1 это более 19000 тестов.

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

И да! Мы живём в интересное время: веб меняется и активно развивается прямо на наших глазах. Запасайтесь поп-корном.

К оглавлению

Интервью

Михаил Альперович (DigitalDesign) о неигрушечном применении iPad

Евгений Крестников

Опубликовано 28 марта 2011 года

- Почему именно iPad? Не проще ли посмотреть на устройства под Windows или Android?

- Мы начали работать с этими (мне понравилось выражение Стива Джобса) PostPC-девайсами именно с iPad, потому что это первый планшет хорошего качества, который приятно взять в руки и с которым удобно работать.

- Давно вы уже смотрели в сторону рынка планшетов?

- Как только они появились — это был год примерно 2002, если не раньше. Смотрели мы в основном со стороны, была попытка более плотно с ними познакомиться в конце 2008 года — у нас готовилось решение для руководства компаний с dashboard (информационными досками), и мы думали, что хорошо бы его сделать на планшете. Но подходящих устройств на рынке не было. Когда Джобс показал iPad, стало интуитивно понятно: это то, что нужно. Продукты сравнимого качества пока не пошли в массы, и вопрос выбора платформы не стоит.

Перейти на страницу:
Вы автор?
Жалоба
Все книги на сайте размещаются его пользователями. Приносим свои глубочайшие извинения, если Ваша книга была опубликована без Вашего на то согласия.
Напишите нам, и мы в срочном порядке примем меры.
Комментарии / Отзывы
    Ничего не найдено.