HTML5 – это определенно будущее интернета.

 

Постепенно из обычного формата разметки текста HTML превращался в довольно сложный стандарт, на базе которого делали привычные нам страницы интернет-магазинов, банковские системы, онлайн-игры и т.д. Но возможностей стандарта HTML4.

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

 

Разработчики стандарта HTML тоже поняли свое упущение и решили: надо дать народу новый стандарт, чтобы все делали свое дело, не уходя из обычной платформы браузера во всякие Flash/Silverlight/JavaFX. Дополнительный плагин для отображения страницы — это уже по определению плохо. Пользователям это нужно ставить, обновлять, мириться с дополнит ельными тормозами. А сам браузер из основного окна в мир Сети стал ненужной прослойкой для запуска приложения на Flash’е или Silverlight’е. Сети срочно потребовался новый стандарт взамен устаревшего HTML4. Его и придумали, незатейливо обозвав HTML5. Это уже не только и не столько язык для разметки страниц и их форматирования, сколько руководство для разработчиков браузеров, какие возможности они должны предоставлять странице и выполняемому там коду. При этом вторгаясь совсем не в область разметки, поручили браузеру дать невиданные возможности скриптам. Отныне работа с видео и звуком, 2D- и 3D-графикой, анимацией, эффектами, сетью на низком уровне – все это должно быть доступным в обычном JavaScript.

 

Основная задача нового стандарта — расширение стандарта разметки веб-страниц для того, чтобы создавать красивые и функциональные сайты стало легче и проще. HTML5 развивается в двух направлениях. Первое — это расширение языка HTML для внедрения новых возможностей, которые раньше делались через грязные хаки и при помощи сплава CSS и JavaScript. В основном это всякие визуальные штучки вроде скругленных уголков, элементы ввода (веб-формы) и прочие украшательства. Второе — добавление в веб новых возможностей с таким расчетом, чтобы веб-приложение имело все те же возможности, что и обычное десктопное приложение, при этом от пользователя требовался бы только браузер без всяких плагинов и дополнений. Самый лучший этому пример – воспроизведение видео. Сейчас надо на JavaScript и Flash написать плеер, организовать далеко не тривиальную серверную часть, обеспечить все стандартные возможности (проигрывание, остановку, прогрессивную загрузку и т.п.). В HTML5 все это не нужно – в браузере достаточно вставь новый тег и все. Элементы управления плеера, сам код и даже видеокодек – все это стандартно и уже есть в браузере.

 

 

Возможности HTML5

Раньше веб-странички содержали или обычный текст, пусть и с форматированием, или же заранее подготовленные изображения в растровых форматах JPEG/GIF/PNG. Flash с его векторной природой и динамическим рисованием сделал просто революцию – стало возможно генерировать анимацию прямо на лету, реагируя на действия пользователя, масштабировать ее и накладывать различные эффекты. Обычный HTML был лишен такого счастья и мог оперировать только символами и объектами документа, но не отдельными графическими примитивами вроде линий или точек.

 

Canvas – это одна из самых ожидаемых и мощных возможностей в HTML5. Как выглядит работа с графикой теперь? Нужно создать специальный тег, внутри которого, в указанном прямоугольнике, имеется возможность работать напрямую с пикселями и графическими примитивами вроде фигур, линий, окружностей и т.п. И все это доступно для управления программным способом через JavaScript. Простейший пример использования canvas:

function draw() {

 

 

 

var canvas = document.getElementById(«canvas»);

if (canvas.getContext) {

var ctx = canvas.getContext(«2d»);

ctx.fillStyle = «rgb(200,0,0)»;

ctx.fillRect (10, 10, 55, 50);

ctx.fillStyle = «rgba(0, 0, 200, 0.5)»;

ctx.fillRect (30, 30, 55, 50);

}

}

 

 

 

 

 

 

Производители браузеров заявили, что уже умеют оптимизировать такие операции, передавая их на графическую карту. Теперь браузер будет кушать не только память и процессор, но и GPU. В последних версиях Google Chrome и IE 9beta для ускорения работы с графикой в элементе canvas используется аппаратная поддержка и DirectX API.

 

Новая фишка – WebStorage или DOM Storage – призвана разгрузить приложение, перенося часть данных на клиентскую сторону. Например, если есть онлайн-магазин, то данные о самых популярных товарах можно хранить сразу у клиента, лишь периодически его обновляя (и чем больше данных, тем заметнее выигрыш). Разработчики получают единый механизм доступа к данным, независимость хранилища от сайта, стойкость не только к закрытию вкладки или окна браузера, но и к полной перезагрузке компьютера. Сколько данных можно так хранить? По спецификации объем данных не ограничивается, но на деле IE разрешает до 10 Мб на домен, в Firefox чуть скромнее – до 5 Мб. Неожиданно, но в деле реализации спецификации хранилища Microsoft реально впереди всех остальных браузеров, так как реализует не только рекомендованные спецификации, но и увеличивает лимиты, добавляет полезные свойства. Например, IE8 – единственный, кто может сообщить, сколько же памяти реально занято данными, другие браузеры этого и близко не умеют. По спецификации хранилищ может быть два – session, когда данные актуальные только для текущей вкладки (но при этом можно уходить на другие сайты, данные сохраняются), и local – уже настоящее постоянное хранилище, привязанное к домену, где оно было создано (для поддоменов будут свои хранилища).

 

Работать с хранилищами данных проще простого – это, по сути, модная нынче NoSQL база данных. Можно положить (set), получить (get) и удалить (remove) значение переменной, данные при этом могут быть любыми, главное, чтобы это были строки или приводимые к ним форматы. Можно также удалить все (clear) и узнать объем (length). Работа с хранилищем осуществляется так же, как и с обычным хешем в JavaScript. Например, сохраним список друзей пользователя:

[code]window.localStorage[myfriend] = JSON.stringify([{name:”Name_1”,email:”info@programmer.uz”},

{name:”Name_2”, email:”info@programmer.uz”}]);[/code]

 

В HTML5 появились новые события – offline/online, которые оповещают программу о перебоях в соединении. Это здорово помогает, например, при написании текстов – если нет интернета, то вместо отправки заполненной формы на сервер достаточно воспользоваться одним из предложенных хранилищ данных (DOM Storage) и сохранить в него все, а уже потом, когда появиться доступ в Сеть, отправить это на сервер. Многие сервисы работы с документами или почтой нуждаются в таком уже сейчас, и им приходится всячески извращаться, чтобы узнать то, что в HTML5 будет доступно одной строкой!

[code]document.body.addEventListener(«offline»,

function () {

alert(‘Offline’));

},

false);[/code]

 

А если проекту достаточно всего лишь пару файлов для оффайновой работы, то можно использовать application cache или offline resource. Это механизм, когда в специальном файле (манифесте) описываются ссылки на все нужные странице файлы, необходимые для того, чтобы работать без связи с сервером. Они автоматически будут загружены и сохранены браузером, чтобы быть наготове на случай обрыва связи. В отличие от настроек кэширования, это работает более гарантированно, и браузер не может пропустить указанный файл — все они в обязательном порядке будут заблаговременно загружены и сохранены. Уже сейчас это можно попробовать в Firefox 3.5 и выше.

 

Приближая возможности веба к обычным приложениям, следовало развязать руки разработчикам, дав возможность загрузить клиентскую машину по максимуму. Так появилась спецификация WebWorkers, впервые реализованная «в коде» еще Google Gears. По сути, это возможность выделить некоторый участок кода (набор функций), которые будут исполняться в отдельном фоновом потоке, никак не мешая обработке основной страницы, не тормозя отрисовку DOM-дерева и другие операции. Конечно, воркеры имеют множество ограничений. Они не могут обращаться к переменным основной страницы или к DOM-дереву страницы, не видят ее переменные. Разрешена только загрузка с удаленных узлов и общение с родительским процессом, где они были созданы через механизм обмена сообщениями (обычными строками или JSON-данными). Простой пример:

[code]var worker = new Worker(«my_script.js»);

worker.onmessage = function(event) {

alert(‘Computing finished, result: ‘ + event.data)

};

worker.postMessage(«5»); [/code]

В воркере (файл my_script.js) может быть любой код JS, не взаимодействующий с DOM, а чтобы он мог общаться с внешним миром, достаточно объявить обработчик события onmessage, который срабатывает, когда воркеру посылают данные для обработки. Результат возвращается через вызов метода postMessage, который связывает код с основной страницей.

 

Cейчас во всех браузерах перетаскивание чего-либо мышью (Drag-n-Drop) приводит к ощутимым тормозам. Разработчики HTML5 обещают, что Drag-n-Drop будет нативный и ускоряться браузером, поэтому даже с огромным DOM-деревом и кучей CSS-стилей все будет летать. Вдобавок появится возможность таскать не только элементы в пределах окна, но и немного выйти за область браузера, разрешив загружать файлы прямым перетаскиванием прямо с рабочего стола или из другого приложения. Это уже сейчас можно попробовать в Google Chrome, приложив аттач к письму Gmail с помощью Drag’n’Drop’а. Вообще, в спецификации обсуждается предоставление большей свободы в плане работы с локальными данными, например, FileReaderAPI, который позволит коду напрямую читать файлы с диска юзера (конечно, не все и не везде). И хотя начальные варианты поддержки уже появились в последних сборках Firefox, это API до конца не обрело свое место в стандарте.

 

В истории Сети с середины 90-х годов пытались добавить настоящую 3D-графику на сайты. Разрабатывались специальные языки (VRML), создавались плагины и библиотеки, начиная от полностью новых (Blink 3D, Wildtangent) и заканчивая расширениями привычных апплетов Java (Java3D) и Flash. Ничего не пошло, пока не решили – а зачем вообще что-то придумывать, если все уже придумано до нас? На том и решили. За основу взяли индустриальный стандарт OpenGL и портировали с некоторыми изменениями его API прямиком в JavaScript. Так на свет появилась технология WebGL, которая сейчас лучше всего поддерживается Chrome.

 

 

Добавить комментарий