Погружение в HTML5 Test. Погружение в HTML5 (2011, PDF) Пилгрим М

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

Отзывы:

Если погружаешься - не забудь костюм!

В интернете ходит мысль о том, что “Погружение в HTML5” это настольная книга для любого верстальщика и веб-разработчика. Я, конечно же, не прошла мимо и ознакомилась с ней. Могу сказать, что книга для настоящих фанатов веба. Это не обзор или скачки по верхам, а самое настоящее погружение! Следовательно, к нему нужно быть готовым.

Если вы совсем новичок - эта книга не для вас, иначе будет либо скучно, либо непонятно, а может быть и то, и другое одновременно. Прошедшие этот этап и утомившиеся банальными рассказами - всем сюда! Прекрасная идея, которая возникла у меня в голове и которой я воспользовалась - читать не только раздел, который вас интересует и каждую функцию/элемент в нем, но также параллельно и документацию в качестве дополнения. Знания станут более крепкими и стабильными. А теперь мои выводы относительно книги в целом.

Из плюсов:

1. Увидела, как всё выглядит “изнутри”;

2. Открыла для себя секрет цитаты “640 Кбайт хватит каждому”;

3. Большое количество “исторической информации” (вряд ли поможет на практике, но точно расширит кругозор);

Из минусов:

1. Таблицы поддержки функций HTML5 неактуальны, при необходимости лучше пользоваться онлайн-справочником.

2. Согласно веб-документации, микроданные безнадежно устарели и не используются в современных браузерах. Так что главу 10 можно смело пропустить, если только у вас нет интереса к механизму работы микроданных.

4. В русской версии книги от издательства “БХВ-Петербург” (2011), к сожалению довольно грубый перевод и встречаются опечатки. От фразы на ст. 68, гласящей “…не будет происходить утечки информации о реферререре” я просто плакала.

После прочтения книги до самой последней корочки, я уверена, что у вас всё еще будет желание узнать больше о веб-разработке. И в этом вам помогут и другие книги.
Подробнее на livelib.ru :

Понравилась статья или книга? Поделись с друзями:

Все книги представленные на сайте только в ознакомительных целях. Любое их использование Вами допускается только в ознакомительных целях. Если Вы планируете их использовать в дальнейшем, то Вы обязаны приобрести их у правообладателей. Администрация сайта не несет ответственность за их использование Вами

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

Определение поддержки функций HTML5

Все объекты DOM используют общий набор свойств. В браузерах, поддерживающих некоторые функции HTML5, некоторые объекты будут обладать уникальными свойствами. Беглый взгляд на модель DOM позволит вам выяснить, какие из функций HTML5 обеспечены поддержкой. Существует четыре базовых метода, которые позволяют выяснить, поддерживает ли браузер ту или иную функцию HTML5. Если идти по пути “от простого к сложному”, то эти методы формулируются так…

Видео в Web

Любой, кто за последние четыре года посещал сайт YouTube.com, знает о том, что в Web-страницы можно встраивать видеоролики. Но до начала работы над стандартом HTML5 стандартного метода достижения этой цели определено не было. Практически все видеоролики, которые вы когда-либо просматривали в Web, “пропускались” через какой-нибудь подключаемый модуль (плагин) от стороннего разработчика- будь то QuickTime, RealPlayer или Flash (YouTube использует Flash.) Эти подключаемые модули интегрируются с вашим браузером настолько хорошо, что вы можете даже не подозревать о том, что пользуетесь ими. По крайней мере, вы можете не подозревать об этом до тех пор, пока не попытаетесь просмотреть видео на платформе, которая не поддерживает этого плагина.

HTML5 определяет стандартный способ встраивания видео в Web-страницу с помощью элемента

Прошлое, настоящее и будущее Web-приложений для хранения данных

Постоянное локальное хранение информации - это та область, где полноценные клиентские приложения, обладающие встроенной поддержкой локального хранения информации, традиционно имели преимущество перед Web-приложениями. Для полноценных клиентских приложений операционная система, как правило, предоставляет уровень абстракций для хранения и извлечения таких специфичных для приложения данных, как настройки приложения и статус времени выполнения. Эти значения могут храниться в системном реестре (только для Windows), INI-файлах, XML-файлах или других компонентах системы, установленных для конкретной платформы. Если ваш клиент нуждается в локальном хранении других данных, а не только пар “ключ/значение”, вы можете встроить в него собственную базу данных, разработать собственный формат хранения данных или выработать целый ряд других решений.

Исторически сложилось так, что Web-приложения были лишены этих удобных возможностей. Cookie-файлы были изобретены на ранних этапах развития Web, и, естественно, их можно использовать для локального хранения небольших объемов данных. Но они имеют три крупных недостатка:

• cookie-файлы включаются в каждый запрос HTTP и, таким образом, замедляют работу вашего Web-приложения бесполезной пересылкой данных туда и обратно;
• cookie-файлы включаются в каждый запрос HTTP, поэтому данные постоянно пересылаются через Интернет в незашифрованном виде (за исключением тех случаев, когда все ваше приложение работает через SSL);
• cookie-файлы имеют ограничение по размеру (до 4 Кбайт для каждого файла). Этого уже достаточно, чтобы существенно замедлить работу вашего приложения, но явно мало для того, чтобы предоставлять реальную пользу.

А теперь давайте посмотрим, что нам требуется в реальности:

• большой объем пространства, чтобы клиентское приложение могло хранить свои данные, которые должны сохраняться между обновлениями страницы;
• возможность сохранения данных без необходимости их передачи на сервер.

До появления HTML5, все попытки добиться этих целей по различным причинам оказывались неудовлетворительными.

Что представляет собой автономное Web-приложение? На первый взгляд, кажется, что это - какое-то терминологическое недоразумение. Во всяком случае, противоречие кажется очевидным. Web-страницы - это то, что мы скачиваем и визуализируем. Скачивание подразумевает наличие сетевого соединения. Как мы можем что-то скачать, если у нас на данный момент нет соединения с Интернетом? Естественно, сделать этого мы не можем. Но при наличии соединения возможность скачивания появляется. Именно по этому принципу и работают автономные приложения HTML5.

В простейшей своей форме автономное Web-приложение представляет собой список URL - файлов HTML, CSS, JavaScript, изображений и ресурсов любого другого типа. Домашняя страница автономного Web-приложения указывает на этот список, который называется файлом манифеста (manifest file), который представляет собой просто текстовый файл, расположенный где-либо на Web-сервере. Web-браузер, который реализует автономные приложения HTML5, прочтет список URL из файла манифеста, загрузит ресурсы, кэширует их локально и будет автоматически сохранять локальные копии по мере их изменения. Когда вы пытаетесь получить доступ к Web-приложению при отсутствии сетевого соединения, ваш Web-браузер автоматически переключается на использование локальных копий.

Начиная с этого момента, большую часть работы должны выполнить вы, как Web-разработчик. В DOM есть флаг, который сообщает вам, в каком режиме вы находитесь в данный момент - онлайн или в автономном. Существуют события, которые срабатывают при изменении вашего статуса соединения (когда вы только что были в автономном режиме, а через минуту переключились в режим онлайн, и наоборот). Но если ваше приложение создает данные или сохраняет свой статус, то локальное сохранение данных при переключении в автономный режим и их синхронизация при подключении к удаленному серверу - это ваша задача. Иными словами, HTML5 позволяет переводить ваши Web-приложения в автономный режим. Что вы будете делать после этого - целиком и полностью зависит от вас.

Зачем нужно вручную управлять адресом в браузере? В конце концов, переход по новому URL можно осуществлять с помощью простой ссылки; таким способом Web работает. И Web продолжит работать таким способом. Данный API не делает попытки “подавить” Web. Как раз наоборот. Web-разработчики нашли новые интересные способы управления Web без какой-либо помощи со стороны появляющихся стандартов. HTML5 history API разрабатывался с тем,
чтобы гарантировать то, что URL останутся полезными даже в приложениях, перегруженных скриптами.

Если судить по большинству упоминаний HTML5Test (далее h5t ), то большинство пользователей данного теста более заинтересованы в конечном результате (сумме баллов), как некотором показателе, на который можно ссылаться и по которому можно сравнивать, нежели во внутренней сути получаемого результата.

В простонародье это зовется пузомерками, а как метко подметили примерно год назад в Lenta.ru (см. ниже) - «у кого HTML5 длинее».

Примеры

Давайте с Ленты.ру и начнем, вот отсылка на тест годовалой давности, когда он только появился:

Мы проверили браузеры на совместимость с новейшим веб-стандартом .
В Сети в марте появился сайт html5test.com , который, как это и следует из названия, проверяет, насколько тот или иной браузер готов работать с новым и чрезвычайно перспективным веб-стандартом HTML5.

Передо мной также лежит номер Computer Bild #02(125)/2011, в котором устроено «масштабное» тестирование браузеров («мега-тест на 18 страниц»):

Большинство веб-страниц написано на языке гипертекстовой разметки HTML. Чтобы корректно отобразить страницу, браузер должен считать все содержащиеся в ее исходном коде теги. В этой строке указано, сколько из 384 страниц браузер отобразил без ошибок.

300 из 384 страниц - это результаты HTML5 Test, что означают оставшиеся 84, не указано. :)

В качестве дополнительных интересных деталей:

• Как это модно (и, вероятно, удобно) сегодня, тест разрабатывается в рамках специального проекта на Github . Там же можно найти информацию об открытых и уже исправленных багах или спорных моментах теста.
• На странице теста Niels благодарит Henri Sivonen за возможность использования его тестов парсинга HTML5 и других людей, внесших свой вклад.

Связь с организациями, продвигающими веб-стандарты

В отличие от того же Acid3, h5t не ассоциирован с какой-либо организацией, разрабатывающей или продвигающей веб-стандарты. Вот что пишет автор теста:

Пожалуйста, имейте в виду, что HTML5 test не связан с W3C или рабочей группой HTML5.

Насколько мне известно, ни один производитель браузеров не имеет в официальных коммуникациях отсылок к h5t как критерию поддержки HTML5. (Ок, за исключением от евангелиста Mozilla Paul Rouget про IE9 vs. Fx4.0.)

Как работает h5t?

Внутреннее устройство теста можно проследить как непосредственно по коду страницы, так и по исходникам на github . В отличие от Acid3, h5t не предполагает генерации какой-либо красивой картинки, - только общий результат в виде количества баллов и детали по тестам.

Тест состоит из:

• Страницы теста (разметка и стили)
• Движка для проведения тестирования, сбора результатов и их отображения на странице
• Непосредственно наборов тестов и тестов внутри них.

Движок для тестирования

Движок для тестирования состоит из нескольких ключевых функций (объектов):

• startTest - запускает процесс тестирования.
  Интересная деталь: для получения статистики html5test аккумулирует результаты прохождения тестов пользователями через API BrowserScope .
• test - содержит список наборов тестов, проходится по каждому набору и собирает результаты
  Упрощенно, запуск тестирования выглядит следующим образом:

  test.prototype = {
  suites: [ { title: null , sections: [
  testParsing, testCanvas, testVideo, testAudio, testElements,
  testForm, testInteraction, testMicrodata, testOffline, testSecurity ]
  },
  { title: "Related specifications" , sections: [
  testGeolocation, testWebGL, testCommunication, testFiles, testStorage,
  testWorkers, testDevice, testOther ] }
  ],

  Initialize: function (e, t, c) {
  var r = new results(e, t);

  for (g in this .suites) {
  r.createSuite(this .suites[g].title);

  for (s in this .suites[g].sections) {
  new (this .suites[g].sections[s])(r);
  }
  }

  C(r);
  }
  }
  

  
  

  Каждая из функций с наборами тестов получает ссылку на объект с результатами, в который нужно внести результаты тестов.

• results - формирует внешнее представление на основании полученных результатов
• section, group и item - логическое представление группировок тестов (используются при формировании и выводе результатов)
• вспомогательные данные и функции:
  • iOS и Android - нужно в одном из тестов (см. ниже)
  • isEventSupported - проверяет, поддерживает ли браузер соответствующее событие
  • getRenderedStyle - вытаскивает из элемента результирующий стиль

В целом, механизм достаточно гибкий для свободного добавления новых тестов, исправления текущих и других интересных манипуляций. (Если захотите использовать в своих нуждах, см. копирайт в самом начале страницы с тестами.)

Наборы тестов

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

Внутренее устройство тестов можно различаться, но общая структура набора хорошо прослеживается на таком примере:

function testFiles (results) { this .initialize(results) }
testFiles.prototype = {
name: "Files" ,
count: 2,

Initialize: function (results) {
this .section = results.getSection(this .name);
for (var i = 1; i <= this .count; i++) { this ["t" + i](); }
},

T1: function () {
this .section.setItem({
title: "FileReader API" ,
url: "http://dev.w3.org/2006/webapi/FileAPI/#filereader-interface" ,
passed: "FileReader" in window,
value: 10
});
},

T2: function () {
this .section.setItem({
title: "FileWriter API" ,
url: "http://www.w3.org/TR/file-writer-api/" ,
passed: "FileWriter" in window,
value: 10
});
}
};

* This source code was highlighted with Source Code Highlighter .

Все тесты выполнены в виде отдельной функции ti , в процессе тестирования при инициализации набора браузер проходится по всем таким методам, описанным внути набора.

Каждый метод внутри себя добавляет в собираемые результаты (объект results передается из движка тестирования) информацию о прохождении или непрохождении теста, количество баллов, полагающееся за этот тест, и дополнительную мета-информацию (от ссылок на спецификацию до формилировок о частичности или полноте прохождения тестов).

Более сложные тесты (например, для веб-форм), используют немного более сложные структуры для группировки результатов, но суть остается той же.

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

Что проверяет h5t?

Список того, что конкретно проверяет h5t с отсылками (не всегда корректными) на спецификации или фрагменты спецификаций можно найти непосредственно на странице теста, поэтому нет большого смысла его дублировать здесь. Гораздо важнее понять, что происходит там внутри и что стоит за каждой тестирующей функцией.

Давайте начнем с того, что посмотрим, как отдельные проверяемые блоки распределяются по тесту и переводятся в баллы, и как это все взаимосвязано со стандартом HTML5.

Состав

Первое, что бросается в глаза, это то, что значительная часть «проверяемых» элементов на сегодня не входит в спецификацию HTML5:

Какие-то из этих элементов были исключены из спецификации HTML5 и выделены в отдельные стандарты (например, HTML Microdata), какие-то никогда в эту спецификацию не входили (например, FileAPI).

Отдельные вещи к веб-стандартам прямого отношения не имеют вообще (кодеки -за поддержку даются дополнительные бонусные баллы).

Наконец, WebGL является сторонней спецификацией, не имеющей прямого отношения к HTML5 (использует Canvas для вывода результатов рендеринга).

Пропорции

Второй важный момент, на который определенно стоит обратить внимание, заключается в распределении баллов между между различными спецификациями и внутри спецификации HTML5.

Так, огромное количество баллов (90 из 400) отводится под новые элементы для форм - почти четверть от общей суммы или треть от баллов, отводимых на непосредственно HTML5. Веб-формы, безусловно являются важной составляющей в новой спецификации, но навряд ли сегодня эту составляющую можно назвать доминирующей по востребованности (подробнее см. ниже).

На работу с видео отводится примерно столько же баллов, сколько на все новые семантические элементы HTML5. На Canvas отводится заметно меньше, чем на Audio.

Какие-то тесты и проверки весят 1 балл, какие-то по 10. Фактически, распределение баллов между тестами и проверками - это полная воля и фантазия автора теста.

Статусы

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

Если начинать копать внутрь, то первое, что всплывает на поверхности - это текущий черновой статус большинства спецификаций:

• HTML5 - Working Draft, ожидается, что в мае будет WD LC
• HTML MicroData - WD
• Geolocation - Candidate Recommendation (единственное исключение из всей обоймы)
• Web Messaging и Server Sent Events - WD LC
• Web Sockets API - WD (оставляем за рамками обзора переменчивость протокола)
• File API - WD, недавно только перешагнувший рубеж первой версии черновика
• Web Storage - WD
• Indexed DB - WD
• Web SQL Database - работа прекращена, но автор позволяет набирать баллы тем, кто не поддерживает Indexed DB
• Web Workers - WD LC
• Local Devices - нет в спеке от W3C, полтора месяца назад исключено из спецификации от WHATWG и заменено на API
• DOM Range/Text Selection - отдельное свойство другой спецификации
• CSSOM View Module/Scrolling - отдельное свойство перенесенное в другую спецификацию (редакторскую версию)

Второе, что не менее важно, - это ранний статус и изменчивость многих спецификаций: на картинке выше можно видеть частоту выхода обновлений спецификаций по каждому из стандартов в течение последних трех лет. Местами, как уже сказано выше, изменчивость такова, что тест уже не соответствует реальному состоянию дел на ниве веб-стандартов .

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

Давайте посмотрим детальнее на содержание каждого из тестов.

Блок HTML5

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

Парсинг 5 tests | 11 points | 2 bonus points

В данном блоке тестов проверяются некоторые правила парсинга документов и, в частности, разбора различных экзотических и некорректных вариантов разметки, соответствующие спецификации HTML5.

1. Поддержка 1 point
Проверяет, что «с установленным doctype браузер работает в Strict mode». Внутри делается проверка, что document.compatMode == "CSS1Compat". Данное свойство характеризует то, в каком режиме сейчас работает браузер (Quirks vs. Strict).

Реально, при наличии любого корректного doctype браузер должен работать в Strict-режиме, то есть данная проверка не имеет прямого отношения к HTML5, т.к. Strict mode с будет включен даже в IE6, который заведомо не поддерживает HTML5.

2. HTML5 Tokenizer 5 points
Проверяются различные экзотические случаи задания названий, атрибутов и содержания элементов - всего 19 проверок на правильный парсинг внутреннего содержания html-элемента:

• "";
• "
  "
• "
  "
• "
  "
• ""
• "\u000D"
• "〈〉"
• "ⅈ"
• "𝕂"
• "∉"
• ""
• ""
• ""
• "<!---->"
• "<!---->"
• "-->"
• "-->"

Хотя, наврядли, вам придется сталкиваться в жизни с большинством из этих случаев, важно отметить, что в спецификации HTML5 действительно особое внимание отведено парсингу документов и правильной обработке подобных примеров.

(Фактически и почти буквально, эти тесты базируются на мозилловских тестах парсинга HTML: http://hsivonen.iki.fi/test/moz/detect-html5-parser.html)

3. HTML5 Tree building 5 points
Продолжение темы парсинга документа - динамичное создание различных элементов с тем же оригинальным источником тестов:

• Tag inference / автоматическое создание тегов (в данном случае проверяется, что динамически созданный элемент html имеет внутри head и body элементы).
• Implied / ожидаемый col-элемент в таблице
• Парсинг списков
• Поддержка Foster parenting
• Adoption agency algorithm / парсинг некорректных вложений вроде "AB

  C D"

• HTML namespace

Замечание : этот и предыдущий тесты - единственные во всем h5t, которые проверяют детали реализации того или иного функционала и претендуют на проверку интероперабельности парсинга документов.

(Повторю, что в отличие от остальных тестов, тесты проверки парсинга заимствованы у Henri Sivonen , который известен в том числе тем, что был сильно вовлечен в разработку HTML5-парсера для Firefox 4. Т.е. фактически, это тесты, придуманные в ходе разработки Fx4, поэтому неудивительно, что он их замечательно проходит. Ключевой особенностью подобных подборок является то, что оставаясь корректными, они не могут претендовать на 100% или близкое покрытие проверяемого функционала. Другими словами, это выборочное тестирование интересных автору вариаций кода.)

Поддерживает ли браузер SVG или MathML на самом деле не проверяется

Неожиданно, тест заваливает Opera, исторически имеющая одну из лучших поддержек SVG. Настоящая поддержка MathML есть только в Firefox. Chrome этот тест проходит, даже не имея поддержки самого MathML (можно проверить на тестовых примерах Mozilla).

Замечание : формально, внутренее содержание svg- и math-элементов и правила парсинга/отображения описываются отдельными спецификациями. Спецификация HTML5 говорит, что документ должен поддерживать вставку SVG-контента через

Canvas 3 tests | 20 points

Данный блок тестов проверяет поддержку Canvas. На самом деле, как видно из описания ниже, проверяется только факт поддержки браузером тега canvas и выдачи правильного контекста для манипуляций из JavaScript.
К сожалению, какой бы то ни было существенной проверки уровня поддержки canvas и совместимости реализаций данный блок не производит .

Video 7 tests | 31 points | 8 bonus points

Данный блок призван проверить поддержку в браузере нового тега