В настоящее время быстрая смена версий – явление вполне нормальное. Все давно привыкли к тому, что числа в названиях спецификаций и продуктов, их реализующих, растут с умопомрачительной скоростью. И на этом фоне немного странно видеть, как за аббревиатурой HTML уже второе десятилетие неизменно следует цифра 4.
|
Рис. 1. |
Причина столь необычной для современного мира стабильности в том, что с появлением XML специалисты консорциума W3C явно несколько охладели к HTML. В начале третьего тысячелетия нередко можно было услышать, что HTML изжил себя и должен уступить место новому языку разметки. Однако убедить в этом разработчиков оказалось не так просто. В результате HTML не только остался жив, но и успешно развивается. В 2004 г., не надеясь дождаться от W3C новых проектов, ведущие производители браузеров основали сообщество WHATWG (Web Hypertext Application Technology Working Group), главной задачей которого стало развитие языка HTML и API для создания веб-приложений.
Универсальность или потеря индивидуальности?
Если попытаться выяснить, какой элемент чаще всего используется для создания структуры современных веб-страниц, то единоличным лидером, конечно же, окажется <div>. С его помощью формируются «шапка» и «подвал» документа (иногда их называют верхним и нижним колонтитулами), навигационная панель, блок для отображения статьи и многие другие составные части: как общеупотребительные, ставшие стандартом de facto, так и уникальные, придуманные автором и реализованные в единственном экземпляре. Хорошо ли это? Как говорил главный герой известной пьесы, «в Германии иметь фамилию Мюллер – все равно что не иметь никакой». Можно ли назвать понятным код веб-страницы, в котором бесчисленное множество раз повторяется дескриптор <div> и лишь время от времени встречается <span> – такой же универсальный и такой же обезличенный элемент символьного уровня? Авторы HTML 5 ответили на этот вопрос твердым «нет», поскольку в разработанной ими спецификации появились новые элементы, предназначенные для описания структуры документа, – это <header> и <footer>, формирующие «шапку» и «подвал», <nav>, который создает раздел, состоящий из гипертекстовых ссылок и применяемый для навигации, <article>, оформляющий фрагмент текста в виде отдельной статьи, и ряд других. Конечно, никто не собирается упразднять <div> и <span>, но отныне им придется несколько потесниться, уступив место своим более удобочитаемым собратьям. Структура веб-документа, написанного на языке HTML 5, скорее всего будет выглядеть так, как показано на рис. 1.
Привычная операция
Процедура перетаскивания элементов в настольных программах настолько привычна всем, что пользователи выполняют ее, не задумываясь, автоматически. Да и разработчикам она не доставляет больших хлопот: уже давно почти все заботы о ее реализации взяли на себя инструментальные средства. В веб-приложениях ситуация несколько иная. Во-первых, документ, позволяющий перемещать свои компоненты с помощью мыши, пока что скорее исключение, чем правило, а во-вторых, чтобы организовать перетаскивание средствами JavaScript, приходится прилагать значительные усилия. Однако данный вопрос не остается без внимания разработчиков, вследствие чего в новой версии HTML предусмотрена поддержка новых событий, определяющих процесс перетаскивания и взаимодействие перемещаемого элемента (dragged element) с принимающим объектом (drop listener):
- dragstart – инициализация процедуры перетаскивания;
- drag – собственно перемещение, т. е. движение мыши с нажатой кнопкой;
- drop – свидетельство о том, что перетаскиваемый элемент был успешно получен принимающим объектом;
- dragenter, dragover и dragleave – соответственно вход перетаскиваемого объекта в область, занимаемую принимающим объектом, перемещение его по ней и выход за ее пределы.
Как реализовать процедуру перетаскивания в приложении – тема для отдельного руководства, этот вопрос невозможно рассмотреть в обзорной статье даже вкратце. Стоит лишь заметить, что введение новых событий, несомненно, упростит соответствующий код. Вместо того чтобы оперировать понятиями нажатия, отпускания кнопки мыши и перемещения курсора, можно использовать более высокоуровневые события. Помогут в работе и интерфейсы DragEvent и DataTransfer, определенные в HTML 5. Однако и новые средства не делают задачу организации перетаскивания тривиальной, так что дальнейшие усовершенствования инструментария, бесспорно, будут приветствоваться разработчиками.
Чтобы браузер не «зависал»
Развитые («богатые») интернет-приложения (RIA) уже давно перестали быть новинкой. Разработчики пытаются добиться, чтобы интерфейсы их веб-сервисов как можно более походили на интерфейсы программ для настольных систем. Однако чем «богаче» приложение, тем бoльшая часть кода должна быть перенесена с сервера на клиентскую машину в виде сценариев в составе HTML-документа и выполняться в среде браузера. Не исключено, что при этом для решения некоторых задач потребуется значительное время. И тут возникает весьма неприятный эффект: пока JavaScript-сценарий занят вычислениями, браузер не реагирует на действия пользователя.
Проблема серьезнее, чем может показаться на первый взгляд. Если верить психологам, пауза в работе не просто нежелательна, она губительна. За очень короткое время пользователь успевает перенестись из «виртуального» мира текущей задачи в повседневную реальность, а для того чтобы вернуться обратно, потребуется немалое волевое усилие. Так как же исключить столь вредное явление? Если расположить код на стороне сервера, пауза возникнет из-за естественной задержки ответа, связанной с прохождением пакетов по сети. Если же код будет выполняться на стороне клиента, он на это время может «отключить» браузер. Решение предлагает HTML 5. Механизм, называемый Web Workers, позволяет перенести часть кода, выполняемого в среде браузера, в отдельный поток. Время, требуемое для решения задачи, не уменьшится, однако пока сценарий будет занят, остальные элементы веб-страницы останутся доступными и пользователь сможет продолжать работу.
Где я? Что со мной?
На второй вопрос браузер, пусть даже поддерживающий HTML 5, ответить пока не в состоянии, но первый, благодаря geolocation API, уже вполне в его компетенции. Вообще-то задача определения текущих координат пользователя решена давно. GPS-навигаторы уже стали продуктом массового потребления, а для кого-то, вероятно, и предметом первой необходимости. С появлением HTML 5 определение местоположения становится неотъемлемой функцией любого браузера. В составе давно известного объекта navigator появилось свойство geolocation, которое предоставляет доступ к функции getCurrentPosition(). Ей в качестве параметра передается функция обратного вызова, которая, возможно, впоследствии получит управление. Почему «возможно», а не «наверняка»? Дело в том, что разработчики geolocation уважают право пользователя на конфиденциальность, поэтому определение координат осуществляется только с его согласия. При вызове getCurrentPosition() браузер предупредит пользователя (к примеру, Firefox при этом отображает в верхней части окна специальную панель), и только с его разрешения функция обратного вызова получит объект, описывающий местоположение компьютера. Свойства данного объекта позволяют узнать географическую широту и долготу, высоту над уровнем моря и даже дату и время определения координат.
Я могу рисовать
|
Рис. 2. |
Объект canvas давно известен. Он реализован во многих системах программирования, это один из первых объектов, с которыми знакомятся новички, делающие робкие попытки самостоятельного написания кода. Разместить с помощью HTML 5 на веб-странице «холст» для рисования чрезвычайно просто. Для этого надо включить в ее состав дескриптор <canvas>, указав посредством его атрибутов ширину и высоту элемента. Затем следует получить доступ к объекту холста, для чего используется любой из известных подходов, например вызов функции getElementById(). Завершается подготовка к работе извлечением графического контекста посредством функции getContext(), принадлежащей объекту canvas. Теперь можно рисовать на холсте линии, геометрические фигуры, заливать контуры цветом, одним словом, выполнять благодаря JavaScript то, что позволяют делать многие другие языки. Но что же тут особенного? Ведь изображение можно расположить на сервере и включить его в HTML-документ с помощью дескриптора <img>. Разница, однако, весьма существенна. Предположим, вам надо разместить на веб-странице простой рисунок (не фотоснимок!), включающий несколько прямоугольников, соединенных стрелками. Размер файла, в зависимости от размера картинки и формата, будет варьироваться от десятков до сотен килобайт (интересно, что формат PCX, обеспечивающий для подобных изображений максимальную степень сжатия без потери качества, браузерами не поддерживается). Используя элемент canvas, нужное изображение можно без проблем нарисовать в браузере. Для этого достаточно лишь нескольких строк кода. Но это еще не все. Связав вызов функций рисования с событиями мыши, можно реализовать элементарную «чертежную доску» и рисовать на ней в интерактивном режиме. Пример веб-страницы с холстом для интерактивного рисования (рис. 2) доступен по адресу http://htmlfive.appspot.com/static/draw.html. Просмотрев исходный код страницы, вы оцените, насколько он прост.
А нужны ли плагины?
Наверное, самым решительным шагом авторов HTML 5 стало введение дескрипторов <video> и <audio>, предназначенных для включения в HTML-документ соответственно видео- и аудиоинформации. Если несколько лет назад видеоролик в составе веб-страницы был некой экзотической новинкой, то сегодня отсутствие таковых на сайте выглядит даже как-то несерьезно. Реакцию разработчиков на стремительное распространение медиаклипов мы наблюдаем сегодня. Суть ее можно выразить лозунгом: «Долой плагины!». Согласно новой спецификации видео- и аудиоролики должны включаться в состав веб-страницы посредством дескрипторов, очень похожих на известный элемент <img>. Отличие лишь одно, но очень важное. Если в <img> файл с изображением задается с помощью атрибута src, то в <video> и <audio> для этой цели предусмотрен вложенный элемент <source>. Он, в свою очередь, поддерживает ряд атрибутов, посредством которых задается URL видео- или аудиофайла, MIME-тип данных, содержащихся в нем, и кодек. Казалось бы, незначительная деталь, не заслуживающая внимания. Это не так! Дело в том, что в <video> или <audio> может содержаться несколько элементов <source>, описывающих альтернативные источники одних и тех же данных. И если, например, браузер не поддерживает один из кодеков, он остановит свой выбор на другом.
Можно ли возразить против такого решения? Вряд ли среди создателей веб-страниц и пользователей найдется много противников. Беспокоит другое: что будет в случае появления новых форматов видео- и аудиоданных? Ведь спецификация HTML 5, по сути, перекладывает ответственность за их воспроизведение на плечи разработчиков браузеров. Они обязаны будут отслеживать новинки в этой области и оперативно реагировать на них. Остается надеяться, что дополнительная нагрузка окажется по плечу производителям клиентских веб-программ.
Если пропало соединение
Когда-то основным средством, обеспечивающим доступ к Интернету, было коммутируемое соединение. Многие пользователи мечтали о технологиях, которые позволили бы им быстро скопировать нужные документы, освободить для домочадцев телефонную линию, а затем спокойно разбираться с данными. Эти времена уже в прошлом. Редко можно встретить настольный компьютер, не имеющий более или менее постоянного подключения к Глобальной Сети. Казалось бы, инструменты для автономной работы не актуальны, однако это не так. Интерес к ним еще больше возрос благодаря распространению портативных устройств: ноутбуков, мобильных телефонов и карманных ПК. Если пользователь такого гаджета временно выйдет из зоны устойчивой связи, возможность продолжить работу в автономном режиме окажется неоценимой.
Материальным выражением заботы создателей HTML 5 о пользователях мобильных устройств стала технология AppCache and Database. Теперь разработчик может указать файлы, которые необходимо хранить в кэше для того, чтобы работу с ресурсом можно было продолжать и при отсутствии соединения. Для этой цели используется файл манифеста, который имеет простой формат и подключается к документу посредством атрибута manifest дескриптора <html>. Обнаружив манифест, браузер помещает указанные в нем файлы в кэш, после чего пользователь получает возможность хотя бы ограниченное время работать без постоянного обмена информацией с сервером. Заметим, что специальный кэш (AppCache), созданный по указаниям манифеста, отличается от обычного, в который автоматически помещаются все данные, полученные браузером. Если содержимое обычного кэша со временем считается устаревшим и удаляется, то на информации в AppCache фактически стоит гриф «хранить вечно». Данные, содержащиеся в нем, могут быть удалены только по требованию пользователя.
Грамматический разбор – дело не личное
Если спросить разработчика браузера о том, на каких принципах строятся синтаксические анализаторы, входящие в состав современных веб-клиентов, он вряд ли сможет ответить. Конечно же, специалист в деталях расскажет, как производится разбор в том продукте, над которым работает он сам, но об остальных не сможет ничего утверждать по одной причине: до недавнего времени подходы к анализу кода документа ничем не регламентировались – разработчики сами решали, как строить программы грамматического разбора. С появлением HTML 5 такой «анархии» пришел конец. В новой спецификации указано, что веб-страница должна быть представлена в виде древовидной структуры DOM, которая позволит легко манипулировать ее элементами. И похоже, что в решении этого вопроса создатели HTML 5 немного поторопились...
Никто не спорит, что DOM – чрезвычайно удобный и эффективный инструмент для небольших веб-страниц, но он перестает быть таковым, если размер документа превосходит некоторый предел, зависящий от быстродействия компьютера и доступного объема памяти. Дело в том, что представление документа в виде дерева DOM – весьма ресурсоемкая операция, причем количество потребляемых ресурсов растет быстрее, чем размер обрабатываемого файла. Не в этом ли причина излишней «прожорливости» современных браузеров?
Что же произойдет, если придется работать с документами действительно большого объема? Этим вопросом, похоже, никто не задавался. А может быть, имеет смысл задуматься об альтернативном варианте разбора? Например, если объем исходного файла превосходит заранее определенное критическое значение, переключаться на использование технологии SAX? Если раньше для того, чтобы реализовать решение, снижающее потребность браузера в ресурсах, достаточно было доброй воли разработчика, то теперь появилось новое препятствие: спецификация. Тот, кто посягнет на нее, автоматически объявит себя нарушителем. Конечно, если его решение окажется успешным, можно будет говорить о том, что «победителей не судят», что спецификация – не догма и требует пересмотра. Но в случае неудачи моральные и материальные потери неизбежны.
Прощайте, апплеты
Невзирая на то что в HTML 5 предусмотрены новые средства, общее количество дескрипторов данного языка практически не изменилось. Некоторые элементы стали достоянием истории. Ничего не поделаешь, новое приходит на смену старому, это естественный процесс. Однако немного грустно, что среди элементов, исключенных из состава языка, оказался и <applet>. Конечно, есть и другие возможности включить апплет в состав веб-документа, но дело не в этом. Решение разработчиков HTML 5, по сути, возводит в ранг закона реально сложившуюся ситуацию. Появившись полтора десятка лет назад, апплеты громко заявили о себе, некоторое время были чрезвычайно популярны, затем стали использоваться все реже, и, наконец, – финал... В чем же дело? Они не оправдали возложенных на них надежд? Причина скорее в другом: обстоятельства попросту не позволили апплетам достойным образом реализовать заложенные в них возможности. Язык Java, поначалу предназначенный для программирования мобильных устройств и написания кода, копируемого по сети, вырос в громадный набор технологий, решающих глобальные задачи, а апплеты остались на обочине прогресса. Увы.
Решение очевидно
Должна ли спецификация HTML 5 обеспечивать совместимость с более ранними версиями данного языка? Наверное, этот вопрос из разряда риторических. Если в один прекрасный момент все браузеры каким-то волшебным образом окажутся перепрограммированными и перестанут поддерживать HTML 4, это будет означать не что иное, как полный крах существующего Веба. Очевидно, что имеющиеся на сегодняшний день документы должны корректно отображаться в новых реализациях ПО. Справедливо и обратное: новые документы должны отображаться в выпущенных ранее клиентских веб-программах так, чтобы свести к минимуму потери информации, связанные с отсутствием поддержки дополнительных выразительных средств. Именно на такой позиции стоят разработчики HTML 5, и альтернативные идеи, вероятнее всего, даже не рассматривались.
Но если новые элементы языка HTML не противоречат существующим, то они должны были уже давно попасть в поле зрения разработчиков. Действительно, так и есть. «Война» браузеров, особенно бурно разгоревшаяся в период стабильности спецификации HTML, превращается, пусть на время, в своеобразную «гонку». С появлением новой спецификации выяснилось, что лидирующее положение на рынке может занять тот, кто раньше других качественно реализует ее возможности. Как же на практике обстоит дело с поддержкой средств HTML 5? Чтобы ответить на этот вопрос, надо проделать огромную работу по анализу текущего состояния каждого из популярных браузеров, но, к счастью, эта работа уже выполнена и результаты ее опубликованы по адресу http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(HTML5). Авторы обзора разумно сосредоточили свое внимание на «движках», лежащих в основе всевозможных браузеров. Из приведенных данных видно, что лидером являются Presto и, следовательно, реализованный на его базе Opera. Последнее место занимает Trident, хотя его новая версия (для Internet Explorer 9) пока находится на самых ранних стадиях разработки. Gecko (Firefox) и WebKit (Safari и Chrome) идут почти «нога в ногу», хотя последний все же незначительно опережает своего конкурента. Но, главное, каждый продукт развивается и, какие-то заметные изменения вполне могут произойти даже к моменту публикации данной статьи.
Про DCIM у забезпеченні успішної роботи ІТ-директора