Справочник по CMS Atomax version 2.0
 

Как попробовать HTML5?


Следующая статья: 

Содержание

Испытываем HTML5

Не буду скрывать - HTML5 как эталона еще как бы нет. Многие части его противоречивые и сырые. Производители Веб браузеров задумываются по - различному, реализовывают то, что желают, и как сами считают необходимым. Дескать, нет еще эталона, потому сиди, пользователь, молчи в тряпочку и ожидай, пока мы все создадим! И ожидать этого вашего HTML5 годами. Но если ты разработчик, либо просто решил повытрепываться, то вот для тебя пара коротких рецептов, как добавить поддержку НТМL5 - plugins на свою страничку уже на данный момент, не дожидаясь поддержки от браузера.

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

Для начала необходимо сверстать странички по всем правилам, а чтоб можно было использовать новые элементы разметки, и браузеры без их поддержки не бранились, идеальнее всего сходу применить готовый шаблон - HTML5 Boilerplate, который содержит внутри себя огромное количество уже готовых фиксов и заменителей для браузеров без нативной поддержки нового эталона. Если хочешь проверить, что поддерживает браузер пользовательа, то для тебя понадобится библиотека Modernizr, которая тестирует браузер на поддержку огромного количества различных библиотек и выдает это в виде API либо просто как характеристики элемента body. Увидь, что скрипт только тестирует наличие либо отсутствие поддержки, а не эмулирует недостающий функционал.

Для выводов обычный векторной графики и рисования можно применить Raphael, сделанный, кстати, одним известным программером. Библиотека может работать как с SVG, так и с VML, и прячет от пользовательа все внутренности прорисовки. А поменять canvas поможет разработка от Гугл - exCanvas, с которой даже тупой Internet Explorer 7 сумеет отрисовывать все, что ты ему прикажешь.

Как хранить данные HTML5

Хранить данные можно с помощью Sessionstorage (единственный из скриптов, который честно эмулирует все WebStorage API) либо более знакомого нам jStore (плагин к jQuery), который хотя и употребляет собственный API, но что поделать. Хочешь воспроизводить видео и выстроить второй YouTube (хорошо, чего уж там, PornTube тоже сойдет) можешь использовать плеер Video for Everybody, который добавляет поддержку тега <video> с помощью Javascript - библиотеки и Flash - проигрывателя.

Всякие рюшечки в формы добавить? Просто с помощью библиотеки WebForms2, работающей во всех браузерах.

WebSocket - самая бедная часть, поэтому как всеполноценно ее эмулирует только один проект. Разработка web - sockets - js употребляет маленькую javascript - обертку над Flash. На сей день это наилучшее решение, умеющее проходить даже через различные умные и не очень proxy и файерволы. Для обмена сообщениями меж различными фреймами, в том числе и с различных доменов подойдет библиотека easyXDM. Если очень захотелось уже на данный момент использовать новейшую модель селекторов либо же другие библиотеки из CSS3, тут на помощь придет selectivizr и css3pie. добавляющий характеристики скругления уголков блоков и остальные радости жизни.

По сути для реально крутых приложений этого недостаточно. Об этом отлично знают и понимают в W3C? потому хранению данных уделено настолько огромное место в текущей спецификации HTML5. Так, на удовлетворенность разработчиками, не считая обычного (и тупого] хранения строк, пусть и неизменного, можно возлагать и на Web SQL Database - попытку предоставить в распоряжение скрипту свою свою всеполноценную SQL базу данных (как правило это SQLite).

Веб либо оффлайн

Ранее работать с web сайтами было можно, даже не имея доступа в Веб - открыл для себя нужные странички и читай, хоть на весь денек, отключившись от модема. С нынешними интерактивными web сайтами такое уже не получится. Для многих действий пригодится устойчивая связь с сервером проекта, ведь ты хочешь одномоментно созидать, что твои друзья делают рядом. Но ведь случается, что веб просто отрубается, правильно? Ранее браузер мог даже не увидеть краткосрочных отключений, максимум это угрожало тем, что не отправляются формы. Современному же приложению в браузере нужно точно знать, есть у него выход в Веб либо нет. И, как опытнейший разработчик, могу для тебя сказать: выяснить это не так и просто. Для облегчения этой задачки в HTML5 появились новые действия - offline либо online, которые оповещают твою программку о перебоях в соединении. Это здорово помогает, к примеру, при написании текстов - если нет веба, то заместо отправки заполненной формы на сервер довольно пользоваться одним из предложенных хранилищ данных (DOM Storage) и сохранить в него все, что ты так тщательно набивал, а уже позже, когда появится доступ в Сеть, выслать это на сервер. Многие сервисы работы с документами либо почтой нуждаются в таком уже на данный момент, и им приходится всячески извращаться, чтоб выяснить то, что в HTML5 будет доступно одной строчкой!

document.body.addEventListener("offline", function () { alert('Чувак, звони провайдеру, твоя сетка свалилась!')); ), false};

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

Уже на данный момент это можно испытать в Firefox 3.5 и выше.

Web Workers - солнце светит, рабы пашут

В Веб просто куча web сайтов, на которые заходишь и понимаешь, что можно выкинуть в топку твой 4 - х ядерный камень и 8 Гб оперативки - все это сжирает один web сайт! Предпосылкой тормозов нередко является Flash, но не он один. Разработчики знают, Javascript в браузере не предназначен для суровых вычислений. Исключительно в последних версиях браузеры научились выделять скрипты в отдельные потоки (первым это взял на вооружение Chrome, что позволило ему назваться самым резвым браузером на планетке). Все же, в рамках странички все скрипты работают в одном потоке, даже если микропроцессор может делать их несколько сразу. Асинхронным, другими словами исполняющимся параллельно был и есть только один особый системный объект XMLHTTPRequest, который может делать запросы на сервер, не прерывая основную работу. Но что все-таки делать, если сейчас ты уже хочешь не просто загружать фото на свою страницу, а требуешь способности ее обработать, создавать коллажи либо photoshop, ну и просто убрать красноватые глаза? И все это на той же странице, без необходимости отправлять фото на сервер.

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

Обычный пример HTML5

var worker = new Worker("my_script.js");

worker.onmessage = function(event) { alert('Computing finished, result: ' + event, data) );

worker.postMessage("5");

В воркере может быть хоть какой код JS не взаимодействующий с DOM, а чтоб он мог разговаривать с наружным миром, довольно объявить обработчик действия onmessage. который срабатывает, когда воркеру отправляют данные для обработки. Итог ворачивается через вызов способа postMessage, который связывает код с основной страничкой.

Можно смело ложить на таковой скрипт трудозатратные расчеты, к примеру, в стратегических либо RPG - играх, редакторах фото и там, где ранее чуть справлялся Flash либо просто глупо вис браузер. Спецификация воркеров вышла на удивление обычный и гибкой, да так, что многие серверные приложения взяли ее на вооружения, реализуя таким макаром многопоточность (к примеру, серверный Javascript NodeJS). Плагины для Firefox. которые также могут быть написаны на чистом Javascript, могут использовать WebWorker для вынесения ресурсоемких обработок в другой поток. Для иллюстрации практической полезности от воркеров, знаменитый Javascript - гуру Джон Резиг, создатель jQuery, портировал из С на Javascript метод поиска коллизий в SHA - 1 хеше (в рамках конкурса, организованного Ruby - хостером Engine Yard). Сам код ты сможешь отыскать на нашем DVD, но прирост скорости от использования многопоточности в различных браузерах составил от двух до 5 раз. А это, как мне кажется, даже очень хороший итог.

Нововведения в HTML5

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

О революционном решении добавить, в конце концов, в интернет то, чего всегда не хватало - нативную поддержку WebSockets (двухсторонней неизменной связи с сервером, практически истинные ТСР - сокеты), я уже говорил подробнее в прошедших статьях. На сей день это одно из самых обсуждаемых новшеств, которое уже реализована в последних релизах браузера (не считая злополучного Internet Explorer 9). И пусть редакции эталона на WebSockets могут изменяться и быть иногда несопоставимыми меж собой, дырявыми в плане безопасности - вне сомнения конкретно они будут основным локомотивом движения web web сайтов в сторону приложений.

В истории Сети с середины 90-х годов пробовали добавить реальную 30 - графику на web сайты. Разрабатывались особые языки (вроде уже погибшего VRML), создавались плагины и библиотеки, начиная от стопроцентно новых (Blink 3D, Wildtangent) и заканчивая расширениями обычных апплетов Java (Java3D) и Flash. Ничего не пошло, пока не решили - а для чего в общем что - то выдумывать, если все уже выдумано (и украдено) до нас? На том и решили. За базу взяли промышленный эталон OpenGL (его в особенности любит знаменитый Джон Кармайк, создатель Doom и Quake) и портировали с некими переменами его API прямиком в Javascript. Так на свет появилась разработка WebGL, которая на данный момент идеальнее всего поддерживается Chrome. Тут, как и в canvas - элементе, есть где разгуляться видеоплате. Обещается, что графика будет ускорена по полной программке. Но эта часть еще не заходит в спецификацию и развивается посторонними компаниями. Но уже одно обещание одного графического API для работы с реальным добросовестным 3D и на возлюбленном Javascript - это подвиг! Как применить - это мы уже сами придумаем, будем писать игры, выводить классные графики и диаграммы, отрисовывать карты. Для игр, кстати, уже сделали и развивают добросовестный игровой движок CopperLicht.

HTML5 - это точно будущее веба

Технологии, которые входят в этот эталон, позволяют с легкостью делать на web страничках то, что ранее было доступно только жестоким С++ программерам на desktop. Сходу все, естественно, на голову не упадет, новые способности равномерно внедряются в браузеры. Но не стоит мыслить, что раз эталон в дальнем будущем, то ничего из его способностей нельзя использовать на данный момент. Многие браузеры поддерживают новаторства HTML5, но вот только одна засада - каждый норовит воплотить это по - собственному.














© 2008–2018. Korvin Industries. Все права защищены.
 

Я выбираю Хостинг: