HTML5: да придет спаситель — статья для журнала Хакер
Статья написана специально для журнала Хакер и опубликована на сайте журнала (в несколько сокращенной и отредактированной версии). Ниже я публикую свой оригинальный вариант, без правок или ограничения на объем материала.
Интернет устарел и об этом все знают! Сначала думали, что все обойдётся, но когда в Сети появились толпы людей, которых не интересовали скучные технические отчеты и документация, это стало очевидно. Сеть требовала красоты и функциональности – изображений, анимации, видео и аудио. Чтобы показать на странице все, что взбредет в голову дизайнера, приходиться очень напрягаться и разработчикам браузеров и составителям стандартов. Так, из обычного формата разметки текста, HTML превращался в мультимедийного гиганта, на базе которого делали страницы интернет-магазинов, банковские системы, он-лайн игры и твои любимые порносайты. Возможностей стандарта HTML 4 уже мало, но как по мне, он устарел сразу в момент создания. Первыми фишку потребностей народа просекли в Macromedia, давно купленной гигантом Adobe, выпустив сначала Shockwave, а потом и Flash, теперь уже именуемой платформой (раньше это был всего лишь плагин к браузеру и уродский простенький язык программирования анимации).
Flash дал то, что всем так хотелось – видео, звук и анимацию, возможности программировать графику и создавать более-менее реальные приложения. Для особо одаренных есть возможности объединить javascript и Flash (замечу, очень по уродливому и ненадежно), таким образом дополняя упущения разработчиков браузера. Видео заполонило мир, Youtube, Фейсбук и вКонтакте стали самыми популярными сайтами - ага, из-за флеша, потому что без видео и приложений, которые почти все флешевые, они нафиг не нужны.
Но разработчики стандарта HTML тоже просекли фишку - надо дать народу новый стандарт, чтобы все делали свое дело не уходя из обычной платформы браузера во всякие Flash/Silverlight/JavaFx. А то иш ты, наплодили своих плагинов, соревнуются в разных фишках, хотя, по честному, все это костыли и предназначение у них лишь одно, пофиг какая технология, лишь бы видео и звук был. Ладно, еще 3D графику и будет круто! Пользователям это нужно ставить, обновлять и вообще, браузер из основного окна в мир сети стал ненужной прослойкой для запуска приложения на флеше или сильверлайте (а разработчики это давно смекнули, потому добавили возможность работы вообще вне браузера - Adobe AIR и Desktop-режим в Silverlight).
Короче, ну ты понял – сети потребовался новый стандарт взамен устаревшего HTML. Его и придумали, незатейливо обозвав HTML5. Это уже не только и не столько язык для разметки страниц и их форматирования, но и руководство для разработчиков браузеров, какие возможности они должны предоставлять странице и выполняемому там коду. Javascript хоть, хорошо, оставили как основной скриптовый язык. При этом вторгаясь в совсем не HTML область, поручили браузеру дать невиданные возможности скриптам. Отныне работа с видео и звуком, двух и трехмерной графикой, анимацией, эффектами, сетью на низком уровне – все это должно быть доступным в обычном JavaScript.
Если кратко – HTML5 это расширение стандарта разметки веб-страниц для того, чтобы создавать красивые и функциональные сайты легче и проще. HTML5 развивается в двух направлениях – первое, это расширение языка HTML для внедрения новых возможностей, которые раньше делались через грязные хаки и при помощи сплава CSS и JavaScript. В основном, это визуальные всякие штучки вроде скругленных уголков, элементы ввода (веб-формы) и прочие украшательства. Второе – добавление в веб новых возможностей с таким расчетом, чтобы все, что может обычное десктопное приложение, было возможно и в рамках обычного сайта, при этом от пользователя требуется только браузер, без всяких плагинов или других приблуд. Самый лучший этому пример – воспроизведение видео (привет, Youtube). Сейчас надо на JavaScript и Flash написать плеер, организовать далеко не тривиальную серверную часть, обеспечить все стандартные возможности (проигрывание, остановку, прогрессивную загрузку и т.п.). Морока ещё та. HTML5 тебе говорит, что это все не нужно – пусть браузер этим занимается, а ты просто вставь новый тег <video> и все, элементы управления плеера, сам код и даже видеокодек – все это стандартное и сразу в браузере есть.
Если по первому пути ты можешь в инете найти очень и очень много описаний, обсуждений, да чего уж там, сейчас многие браузеры уже покажут тебе фичи, например, краткие теги и объявление типа документа (DOCTYPE), более сильное разграничение между разметкой логической структуры документа и его оформления (эти все новые теги типа <head>, <article>, <aside> и прочие). Но если тебя интересует создание чего-то серьезного, стоит отбросить все и сосредоточится на самом интересном – на расширении функциональных возможностей веб-приложений. Некоторые уже сейчас работают, даже в крупных сервисах, вроде Gmail и YouTube. Вот это действительно интересно и стоит того, чтобы познакомиться поближе. А игры с разметкой давай оставим неудачникам, которые стали верстальщиками…
В чем сила HTML5, брат?
Раньше веб-странички содержали или обычный текст, пусть и с форматированием, или же заранее подготовленные изображения в растровых форматах JPEG/GIF/PNG, изредка приправленные анимацией. Flash с его векторной природой и динамическим рисованием сделал просто революцию – стало возможно генерировать анимацию прямо на лету, реагируя на действия пользователя, масштабировать ее и накладывать различные эффекты. Обычный HTML был лишен такого счастья и мог оперировать только символами и объектами документа, но не отдельными графическими примитивами вроде линий или точек. Ну что же, теперь это все в прошлом. Canvas – это одна из самых ожидаемых и мощных возможностей в HTML5. Ты просто создаешь специальный тег, внутри которого, в указанном прямоугольнике, имеешь возможность работать напрямую с пикселями и графическими примитивами вроде фигур, линий, окружностей и т.п. И все это доступно для управления программным способом через JavaScript. Если ты пробовал программировать еще в DOS или интересовался, как делают игры, то должен представлять, какие чувства вызывает необходимость рисовать по пикселям и выводить каждую линию. Но раньше то и этого не было. Если разработчики вовремя подсуетиться и выпустить развитые библиотеки для рисования, можно сказать, что флеш, наконец, обречен.
Canvas, конечно, не такой уж и новый, уникальный. Давно есть возможность рисовать, используя разные ухищрения, вроде специального языка VML в браузерах от Microsoft или свободных формат SVG в Mozilla или Safari. И хоть многие говорят, что SVG гораздо богаче и продвинутое тупого canvas, но не верь им! Это совсем разное – SVG это векторный формат, основанный на XML и обрабатывается так же как и вся страница путем парсинга, хотя потом можно создавать элементы находу. Для сложных рисунков это будет стоить браузеру большого расхода памяти и процессорной мощности – в векторном формате изобразить сложный и красивый рисунок очень накладно. Зато можно сколь угодно масштабировать, вертеть и преобразовывать. Так что для графиков и простых вещей SVG подходит, но если необходимо рисовать качественную графику и одними лишь линиями не обойдешься, здесь canvas очень кстати. Тем более все производители браузеров заявили, что уже умеют оптимизировать такие операции, передавая их на графическую карту. Теперь браузер будет кушать не только память и процессор но и GPU, ведь в последних версиях Google Chrome и IE 9beta для ускорения работы с графикой в элементе canvas используется аппаратная поддержка и DirectX API.
Простейший пример использования 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);
}
}
<body onload="draw();">
<canvas id="canvas" width="150" height="150"></canvas>
</body>
Что имеешь, не хранишь, загружая - плачешь.
Если ты пробовал делать что-то посложнее домашней страницы, наверняка сталкивался с ситуацией, что лучше бы хранить на странице, у клиента, какую-то информацию, чтобы сто раз не гонять ее по сети с сервера. Раньше единственным вариантом было просто тупо загнать ее в JavaScript переменную, но она жила лишь пока страница была открыта в браузере. Закрыл страницу и все безвозвратно исчезало, если возвратился на сайт, то все приходилось загружать сначала, даже если ничего не изменилось. Cookie с задачей хранения данных не справлялись, единственное, что они могли предложить – хранение идентификатора, который тебе приходилось уже привязывать на сервере к данным пользователя. Да и много ли насохраняешь в 4 Кб, а именно столько можно хранить в одной «печеньке»? К тому же они посылаются на сервер с каждым HTTP запросом, что непомерно раздувает сетевой траффик.
WebStorage или DOM Storage призван разгрузить приложение, перенося часть данных на клиент. Например, у тебя магазин в сети, то данные о самых популярных товарах можно хранить сразу у клиента, лишь периодически его обновляя (и чем больше данных, тем заметнее выигрыш). Разработчики получают единый механизм доступа к данным, независимость хранилища от сайта, стойкость к закрытию не только вкладки или окна браузера, но и от полной перезагрузки компьютера. Хотя по спецификации объём данных не ограничивается, на деле IE разрешает до 10 Мб на домен, в Firefox чуть скромнее – до 5 Мб. Неожиданно, но в деле реализации спецификации хранилища Microsoft реально впереди всех остальных браузеров, реализуя не только рекомендованные спецификации, но и увеличивая лимиты, добавляя полезные свойства, например, IE8 единственный, кто может сообщить, сколько же памяти реально занято данными, другие браузеры этого и близко не умеют.
По спецификации хранилищ может быть два – session, когда данные актуальные только для текущей вкладки (но при этом можно уходить на другие сайты, данные сохраняются), и local – уже настоящее постоянное хранилище, привязанное к домену, где было создано (для поддоменов будут свои хранилища).
Работать с хранилищами данных проще простого – это, по сути, модная нынче NoSQL (мы уже писали об такой архитектуре) база данных. Можно положить (set), получить (get) и удалить (remove) значение переменной, данные при этом могут быть любыми, главное, чтобы это были строки или приводимые к ним форматы. Можно также удалить все (clear) и узнать объем (length). Работать с хранилищем можно так же, как с обычным хешем в javascript.
Например, сохраним список друзей пользователя:
window.localStorage[myfriend] = JSON.stringify([{name:”Вася”,email:”vasja@xakep.ru”},{name:”Alex”, email:”aleks@xakep.ru”}]);
На самом деле, для реально крутых приложений этого недостаточно. Об этом хорошо знают и понимают в W3C, поэтому хранению данных уделено столь большое место в текущей спецификации HTML 5 и даже в ее расширениях, еще не вошедших в проект, но уже частично поддерживаемых браузерами.
Так, на радость разработчиками, кроме простого (и тупого) хранения строк, пусть и постоянного, можно надеяться и на Web SQL Database – попытку предоставить в распоряжение скрипту свою собственную полноценную SQL базу данных (обычно это SQLite). Несмотря на плавающий статус этого проекта (он не вошел в текущий вариант HTML 5 и предлагается как отдельный стандарт), он уже давно реализован в плагинах, например, Google Gears, Adobe AIR, а также во многих мобильных устройствах (например, на платформе Appcelerator Titanium). Ну а тем, кому и этого мало, дополнительно предоставляется еще и индексированная база для облегчения полнотекстового поиска - Indexed Database API, предложенная Oracle и пока реализованная только в альфа-версии Firefox 4 и Сhromium. На самом деле вещь очень полезная была бы, если бы была – с ее помощью можно реализовать любые сервисы для работы с данными пользователя, например, локальный поиск по истории посещений, закладках и почтовых сообщениях, не требуя серьезной логики от серверной части. Однако пока эти стандарты самые туманные и судьба их окончательно не решена.
Интернет? Нет, оффлайн!
Раньше работать с сайтами можно было даже не имея доступа в сеть – открыл себе нужные страницы и читай, хоть на весь день отключившись от модема. С сегодняшними интерактивными сайтами такое уже не получится – для многих действий понадобиться устойчивая связь с сервером проекта, ведь ты хочешь мгновенно видеть, что твои друзья делают рядом. Но ведь случается, что Интернет просто отрубается, верно? Раньше браузер мог даже не заметить кратковременных отключений, максимум что было – формы не отправлялись. А вот современному приложению в браузере надо точно знать, есть у него выход в инете или нет. Оказалось, что это не так и просто узнать. Для облегчения «осознания себя» в HTML5 появились новые события - offline/online, которые оповещают твою программу о перебоях в соединении. Это здорово помогает, например, при написании текстов – если нет интернета, то вместо отправки заполненной формы на сервер достаточно воспользоваться одним из предложенных хранилищ данных (DOM Storage) и сохранить все, что ты так кропотливо набивал, а потом уже, когда появиться доступ в сеть, отправить это на сервер. Многие сервисы работы с документами или почтой нуждаются в таком уже сейчас, и им приходится всячески извращаться, чтобы узнать то, что в HTML5 будет доступно одной строкой!
Например:
document.body.addEventListener("offline", function () {
alert(‘Чувак, звони провайдеру, твоя сетка упала!’));
}, false);
Но что делать, если твой сайт может прекрасно жить и без инета, лишь бы были те несколько файлов, без которых ну просто никак не обойтись? Легко, достаточно использовать application cache или offline resource. Это механизм, когда ты в специальном файлике (манифесте) описываешь ссылки на все нужные странице файлы, которые нужны чтобы работать без связи с сервером, и они будут загружены и заботливо сохранены браузером, чтобы быть наготове на случай обрыва связи. В отличие от настроек кеширования, это работает более гарантировано и браузер не может пропустить указанный файл, все они будут загружены и сохранены. Подобным образом работают некоторые клиенты для почты, особенно на мобильных устройствах – когда есть связь, они загружают максимум писем, а когда отключаешься – можно спокойно ходить по ссылках без проблем получая всю функциональность. Уже сейчас это можно попробовать в Firefox 3.5 и выше.
WebWorkers - сонце светит, рабы пашут
В инете просто куча сайтов, на которые заходишь и понимаешь, что можно выбросить в топку твой 4-х ядерный камень и 8 Гб оперативки – все это сжирает один сайт! Ну ладно, не все так печально, обычно причиной тормозов является не к ночи помянутый Flash, но разработчики знают – JavaScript в браузере не предназначен для серьезных вычислений. Только в последних версиях браузеры научились выделять скрипты в отдельные потоки (первым это взял на вооружение Chrome, что позволило ему назваться самым быстрым браузером на планете), тем не менее, в рамках страницы все скрипты работают в одном потоке, даже если процессор может выполнять их несколько одновременно. Асинхронным, то есть исполняющимся параллельно был и есть только один специальный системный объект XMLHTTPRequest, который может делать запросы на сервер, не прерывая основную работу. Но что же делать, если сегодня ты уже хочешь не просто загружать фото на свою страничку, а требуешь возможности ее обработать, создавать коллажи или фотожабы, да и просто убрать красные глаза. И все это на той же страничке, без необходимости отправлять фото на сервер. А делать это все приходится на старом добром javascript.
Приближая возможности веба к обычным приложениям, следовало развязать руки разработчикам, дав возможность загрузить клиентскую машину по максимуму. Так появилась спецификация WebWorkers, впервые реализованная «в коде» еще Google Gears. По сути, это возможность выделить некоторый участок кода (набор функций), которые будут исполняться в отдельном фоновом потоке, никак не мешая обработке основной страницы, не тормозя отрисовку DOM-дерева и другим операциям. Конечно, воркеры имеют множество ограничений, дабы не наглели. Они не могут обращаться к переменным основной страницы или к DOM-дереву страницы, не видят ее переменные. Разрешена только загрузка с удаленных узлов и общение с родительским процессом, где они были созданы через механизм обмена сообщениями (обычными строками или JSON-данными).
Пример работы с воркерами:
var worker = new Worker("my_xaking_script.js");
worker.onmessage = function(event) {
alert(‘Computing finished, result: ‘ + event.data)
};
worker.postMessage("5");
В воркере (файл my_xaking_script.js) может быть любой код JS, не взаимодействующий с DOM, а чтобы он мог общаться с внешним миром, достаточно объявить обработчик события onmessage, который срабатывает, когда воркеру посылают данные для обработки. Результат возвращается через вызов метода postMessage, который связывает код с основной страницой.
Ещё одна фича HTML5 – теперь не надо извращаться для передачи данных между основным документом и скриптом, загруженным во фрейме или iframe, который очень широко используется во многих системах, например, редакторах или comet-серверах. Спецификация Cross-messages позволяет наладить простую и очень быструю пересылку строк между разными фреймами (по сути, реализация IPC внутри браузера).
Можно смело возлагать на такой скрипт трудоемкие расчеты, например, в стратегических или RPG играх, фоторедакторах и прочее, где раньше едва справлялся Flash или просто тупо вис браузер. Спецификация воркеров вышла на удивление простой и гибкой, да так, что многие серверные приложения взяли ее на вооружения, реализуя таким образом многопоточность (например, серверный JavaScript NodeJS). Плагины для Firefox, которые также могут быть написаны на чистом JS, могут использовать WebWorker для вынесения ресурсоемких обработок в другой поток.
Для иллюстрации практической пользы от воркеров, легендарный javascript гуру Джон Резиг, создатель jQuery, портировал из С на JavaScript алгоритм поиска коллизий в SHA-1 хеше (в рамках конкурса, организованного Ruby-хостером Engine Yard). Сам код ты сможешь найти на нашем DVD, но прирост скорости от использования многопоточности, в разных браузерах составил от 2 до 5 раз. А это очень даже отличный результат, мне кажется.
А может, хватит?
Ты думаешь, на этом нововведения в HTML5 закончились? Нет, там еще много чего припасено. Например, сейчас во всех браузерах перетаскивание чего либо мышью (Drag-n-Drop) приводит к ощутимым тормозам. Особенно этим славиться IE (а где ж он не тормозит то?), поэтому все сложные веб-сайты, где много информации, работают в страничном интерфейсе, не пытаясь наследовать десктоп с таскающимися окнами. Теперь же обещают, что Drag-n-Drop будет нативный и ускоряться браузером, поэтому даже с огромным DOM-деревом и кучей CSS стилей все будет летать. В добавок обещают приделать возможность таскать не только элементы в пределах окна а и немного выйти за область браузера, разрешив загружать файлы прямым перетаскиванием прямо с рабочего стола или другого приложения. Вообще, в спецификации обсуждается предоставление большей свободы в плане работы с локальными данными, например FileReaderAPI, который позволит коду напрямую читать файлы с диска юзера (конечно, не все и не везде). И хотя начальные варианты поддержи уже появились в последних сборках Firefox, это API до конца не обрело свое место в стандарте.
О революционном просто решении добавить наконец то в веб то, чего всегда не хватало – нативную поддержку WebSockets (двусторонней постоянной связи с сервером, почти настоящие TCP сокеты), мы уже рассказывали подробнее в прошлых номерах (ссылка на статью о Comet). На сегодня это одна из самых обсуждаемых фич, в последних релизах большинства браузеров уже есть, кроме злощастного IE9.И пусть редакции стандарта на WebSockets могут изменяться и быть порой несовместимыми между собой, дырявыми в плане безопасности – без сомнения именно они будут главным локомотивом движения веб-сайтов в сторону приложений.
В истории Сети попыток добавить настоящее 3D на сайты уже было десятки, с середины 90-х годов. Разрабатывались специальные языки (вроде реально мертвого уже VRML), делались плагины и библиотеки, начиная от полностью новых (Blink 3D, Wildtangent), заканчивая расширениями привычных апплетов Java (Java3D) и Flash. Ничего не пошло, пока не решили – а зачем придумывать что-либо самому, если все уже придумано (и украдено) до нас? Взяли индустриальный стандарт OpenGL (его особенно обожает легендарный Джон Кармайк, создатель Doom и Quake) и портировали с некоторыми изменениями его API прямо в JavaScript, приспособив и немного укротив (реальный OpenGL сильно низкоуровневый язык). Стандарт назвали незамысловато – WebGL, сейчас он лучше всего поддерживается в Chrome. Конечно, здесь, как и в canvas элементе, видеокарте есть где разгуляться и обещается, что графика будет ускорена по полной программе. Однако эта часть еще не входит в спецификацию и развивается сторонними компаниями. Но уже одно обещание единого графического API для работы с настоящим честным 3D и на любимом JavaScript – это подвиг! А как применить мы уже сами придумаем – будем писать игры, выводить крутецкие графики и диаграммы, рисовать карты. Для игр, кстати, уже сделали и развивают настоящий честный игровой движок CopperLicht.
Программист ты или г…?
Не буду скрывать – HTML5 стандарта еще нет, многие части его противоречивы и сырые. Производители браузеров думают по разному, реализовывают то, что хотят и как сами считают нужным - нет еще стандарта, потому сиди, юзер, молчи в тряпочку, пока мы сделаем! И ждать этого вашего HTML5 годами. Но если ты разработчик, или просто решил похвастаться, то вот тебе пара кратких рецептов, как добавить поддержку HTML5 фич на свою страницу уже сейчас, не дожидаясь поддержки от браузера. Конечно, это все костыли – где-то эмулируется через Flash, где-то через сторонние библиотеки или CSS, но зато уже сейчас и во всех браузерах. Последние версии скриптов ты найдешь на нашем диске.
Для начала нужно сверстать страницы по всем правилам, а чтобы можно было использовать новые элементы разметки и браузеры без их поддержки не ругались, лучше всего применить сразу готовый шаблон – HTML5 Boilerplate, который содержит в себе множество уже готовых фиксов и заменителей для браузеров без нативной поддержки нового стандарта.
Если хочешь проверить, а что поддерживает браузер пользователя – здесь тебе пригодиться библиотека Modernizr, которая тестирует браузер на поддержку множества разных фич и выдает это в виде API или просто как свойства элемента body. Заметь, что скрипт только тестирует наличие или отсутствие поддержки, а не эмулирует недостающий функционал.
Для выводов простой векторной графики и рисования можно применить Raphael, созданный, кстати, нашим программистом. Библиотека может работать как с SVG, так и VML для непонимающих браузеров и скрывает от тебя все внутренности рисования. А заменить canvas поможет разработка от гугла – exCanvas, с которой даже тупой IE7 сможет рисовать все, что ты ему прикажешь.
Хранить данные можно при помощи Sessionstorage (единственных из скриптов, который честно эмулирует все WebStorage API) или более знакомого нам jStore, который плагин к jQuery, хотя и использует свой API, но что поделать.
Хочешь воспроизводить видео и построить второй Youtube (ладно, чего уж там, Porntube тоже сойдет) – можешь использовать плеер Video for Everybody, который добавляет поддержку тега <video> при помощи JS-библиотеки и Flash-проигрывателя.
Всякие рюшечки в формы добавить? Легко при помощи библиотеке WebForms2, работающей во всех браузерах.
WebSocket самая бедная часть – полноценно ее эмулирует только один проект, web-sockets-js, использующий небольшую JS-обертку над Flash-ем. На сегодня это лучшее решение, умеющее проходить даже через разные умные и не очень прокси и фаерволлы (с чем у стандарта WS большие проблемы).
Для обмена сообщениями между разными фреймами, в том числе и с разных доменов подойдет библиотека easyXDM.
Если очень захотелось уже сейчас использовать новую модель селекторов или же другие фичи из CSS 3, здесь на помощь придет selectivizr и css3pie, добавляющий свойства скругления уголков блоков и прочие радости жизни.
Как жить дальше то?
HTML5 очень крут, он позволяет на вебстраницах с легкостью делать то, что раньше было доступно только суровым C++ программистам на десктопах. Сразу все, конечно, на голову не свалится, новые возможности постепенно внедряются в браузеры и не надо думать, что раз стандарт в далеком будущем, то нечего о нем думать уже сейчас. Жаль только, что при серьезном подходе, если ты хочешь сделать, чтобы всем браузерам было хорошо, то будут тебе проблемы, и пивом здесь не так просто отделаться. Ведь каждый браузер хоть и поддерживает HTML5 уже и сейчас, но, зараза, каждый свою часть, и обязательно так, чтобы не особо пересекаться с другими. Вот и выходит, что под каждого пользователя надо что-то свое подстраивать. Но оно того стоит, ведь сеть давно перешагнула рамки просто статических текстов и даже эпоха динамических сайтов Web 2.0 уже затихает, поговаривают о Web 3.0, а основа веба все еще убогий HTML.
Напоследок универсальный совет от автора – если тебя запарило использовать все эти костыли, но поставить нормальный браузер пока нельзя, используй Google Chrome Frame и радуйся всем последним веб-стандартам просто в своем любимом IE!
HTML vs xHTML vs HTML5 vs HTML 5
За язык разметки веб-страниц и другие стандарты вроде CSS, сейчас отвечает World Wide Web Consortium, Консорциум Всемирной Паутины или сокращенно W3C. В него входят представители различных компаний ( включая Microsoft ) и отдельные эксперты. И как всегда, жизнь оказывается намного быстрее и богаче любых планов всяких там органов. Поэтому, когда консорциум только выпустил XHTML 1.0 и начал планировать следующий вариант, названный XHTML 1.1, основываясь на модном тренде на XML, часть из специалистов сразу посчитала его мертворожденным и устаревшим. Тем более, что если придерживаться стандарта, то ни один из браузеров не смог бы отобразить такую страницу. Зачем и кому такое нужно, вероятно, не знал никто. А знающие люди посмотрели по сторонам, увидели что софт активно идет в сеть и уже не только люди смотрят страницы, но и хотят больше активности и разнообразия. И что бедные разработчики, будучи скованными по всех фронтах убогостью стандартов и ограничениями браузеров, пытаются применить все, что есть, дабы дать пользователям хоть минимальную свободу и интерактивность в реальном времени. Так от консорциума откололась группа назвавшая себя непроизносимой аббревиатурой WHATWG (Web Hypertext Application Technology Working Group). Изначально они развивали два стандарта - Web Forms 2.0 и Web Apps 1.0, призванные улучшить работу веб-форм и приблизить возможности веб-страниц к обычным приложениям. Позже эти стандарты были объединены в один – HTML5 (обрати внимание, без пробела).
Позже свершилось чудо – признав, что W3C со своим планом относительно XHTML 2 потихоньку скатывается в маразм, главный отце Сети, Тим Бернерс-Ли, признает, что попытка перевести всех и сразу на XML обречена на провал. И вот наконец в 2009 году началась работа над окончательным вариантом спецификации HTML 5, основанной как на мертворожденном XHTML 2, так и на многих наработках гораздо более прогрессивного HTML5. Внутренняя борьба и склоки по отдельным моментам там все еще продолжаются, новые и новые драфты иногда несовместимы между собой – но это все обычный процесс, конца которому пока не видно, хоть и обещают в 2012 году перевести стандарт в состояние «candidate recommendation». Посмотрим…
Ссылки:
Таблица тегов в HTML5 - http://www.w3schools.com/html5/html5_reference.asp
Все, что ты хотел узнать, но боялся нагуглить - http://www.html5rocks.com
Хороший учебник canvas - https://developer.mozilla.org/En/Canvas_tutorial
Processing.js - http://processingjs.org Специальный язык для работы с графикой
Введение в WebWorkers - http://webo.in/articles/all/2009/25-computing-with-web-workers/
Learning WebGL – все для программирования 3D в браузере - http://learningwebgl.com/blog/
Настоящий 3D движок для игр в браузере - http://www.ambiera.com/copperlicht
Большое количество примеров - http://html5demos.com/
Поддержка HTML5 и CSS 3 в разных браузерах - http://www.findmebyip.com/litmus