Погружение в HTML5 Test

    (Это вторая статья из серии статей, посвященных обзору различных тестов браузеров. Ранее в серии: Погружение в ACID3.)

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



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


    Примеры


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

    Передо мной также лежит номер Computer Bild #02(125)/2011, в котором устроено «масштабное» тестирование браузеров («мега-тест на 18 страниц»):
    Большинство веб-страниц написано на языке гипертекстовой разметки HTML. Чтобы корректно отобразить страницу, браузер должен считать все содержащиеся в ее исходном коде теги. В этой строке указано, сколько из 384 страниц браузер отобразил без ошибок.

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

    Вот Компьютерра рассказывает про Mozilla Fennec:
    Тест на поддержку HTML5 Fennec проходит, получая неплохой результат в 207 баллов, в то время как Safari на iOS получает лишь 185.

    Печально, но Хабр тоже не отличается большим разбором в отношении к тестам. Вот только одна из недавних отсылок в посте про новый движок парсинга в Opera:
    Ragnarök также набирает 11 из 11 (плюс 2 бонусных бала) на несколько не полном (и следовательно вводящем в заблуждение) html5test.com (два бонусных бала за внедренный SVG и MathML в HTML5)

    Подвох заключается не только в том, что в Opera давным-давно поддерживается SVG, но и в том, что нативной поддержки MathML в Opera как раз нет (есть частичная через CSS for MathML Profile).

    Черный ящик


    Фактически, h5t используется как некоторый черный ящик, «проверяющий поддержку тем или иным браузером стандарта HTML5», на который очень многие ссылаются и которому всецело доверяют:



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



    И тут начинается самое интересное: что означает каждая из лампочек, почему одни лампочки больше, а другие меньше, почему не все лампочки горят, и, в конце концов, насколько лампочки соответстуют заявленной цели проверки поддержки HTML5?

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

    В общем, давайте разбираться со всем по порядку.

    Кто придумал h5t?

    Автора HTML5Test зовут Niels Leenheer. Как пишет Niels в своем блоге, он работает графическим дизайнером и веб-программистом, периодически вносящим вклад в различные open-source проекты, включая Geeklog, Nucleus CMS, Zenphoto, Mozilla, KHTML и WebKit — от обоев и иконок до отдельных патчей (подробнее о вкладе в каждый из проектов см. тут http://rakaz.nl/code).

    В качестве дополнительных интересных деталей:
    • Как это модно (и, вероятно, удобно) сегодня, тест разрабатывается в рамках специального проекта на 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 );
        }
      }

      * This source code was highlighted with Source Code Highlighter.


      Каждая из функций с наборами тестов получает ссылку на объект с результатами, в который нужно внести результаты тестов.
    • 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. Поддержка <!doctype html> 1 point
    Проверяет, что «с установленным doctype браузер работает в Strict mode». Внутри делается проверка, что document.compatMode == "CSS1Compat". Данное свойство характеризует то, в каком режиме сейчас работает браузер (Quirks vs. Strict).

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

    2. HTML5 Tokenizer 5 points
    Проверяются различные экзотические случаи задания названий, атрибутов и содержания элементов — всего 19 проверок на правильный парсинг внутреннего содержания html-элемента:
    • "<div<div>";
    • "<div foo<bar=''>"
    • "<div foo=`bar`>"
    • "<div \"foo=''>"
    • "<a href='\nbar'></a>"
    • "<!DOCTYPE html>"
    • "\u000D"
    • "&lang;&rang;"
    • "&apos;"
    • "&ImaginaryI;"
    • "&Kopf;"
    • "&notinva;"
    • '<?import namespace="foo" implementation="#bar">'
    • '<!--foo--bar-->'
    • '<![CDATA[x]]>'
    • "<textarea><!--</textarea>--></textarea>"
    • "<textarea><!--</textarea>-->"
    • "<style><!--</style>--></style>"
    • "<style><!--</style>-->"

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

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

    3. HTML5 Tree building 5 points
    Продолжение темы парсинга документа — динамичное создание различных элементов с тем же оригинальным источником тестов:
    • Tag inference / автоматическое создание тегов (в данном случае проверяется, что динамически созданный элемент html имеет внутри head и body элементы).
    • Implied <colgroup> / ожидаемый col-элемент в таблице
    • Парсинг списков
    • Поддержка Foster parenting
    • Adoption agency algorithm / парсинг некорректных вложений вроде "<i>A<b>B<p></i>C</b>D"
    • HTML namespace

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

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

    4. SVG in text/html 1 bonus point Проверяет, что браузер умеет распознавать SVG-контент, вставленный в документ, по соответствующему namespace.
    5. MathML in text/html 1 bonus point Проверяет, что браузер умеет распознавать MathML-контент, вставленный в документ, по соответствующему namespace.
    Поддерживает ли браузер SVG или MathML на самом деле не проверяется

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

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

    Canvas 3 tests | 20 points


    Данный блок тестов проверяет поддержку Canvas. На самом деле, как видно из описания ниже, проверяется только факт поддержки браузером тега canvas и выдачи правильного контекста для манипуляций из JavaScript.
    1. <canvas> element
    5 points
    Проверяет, что у созданного элемента canvas есть метод getContext.
    2. 2d context
    10 points
    Проверяет, что поддерживается объект CanvasRenderingContext2D и вызов метода getContext(“2d”) возвращает экземпляр этого объекта.
    3. Поддержка текста
    5 points
    Проверяет, что у полученного контекста есть метод fillText.
    К сожалению, какой бы то ни было существенной проверки уровня поддержки canvas и совместимости реализаций данный блок не производит.

    Video 7 tests | 31 points | 8 bonus points


    Данный блок призван проверить поддержку в браузере нового тега <video>. Дополнительно он проверяет поддержку различных кодеков, что не имеет никакого отношения к спецификации HTML5, но представляет некоторый интерес.
    1. <video> элемент
    20 points
    Проверяет, что созданный видео-элемент поддерживает метод canPlayType.
    2. Поддержка треков
    10 points
    Проверяет, что браузер распознает track-элемент.
    3. Поддержка постеров
    1 point
    Проверяет, что видео-элемент поддерживает постеры.
    4. Поддержка MPEG-4
    2 bonus points
    Проверяет, что браузер говорит, что он умеет проигрывать видео в соответствующем кодеке.
    5. Поддержка H.264
    2 bonus points
    Проверяет, что браузер говорит, что он умеет проигрывать видео в соответствующем кодеке.
    6. Поддержка Ogg Theora
    2 bonus points
    Проверяет, что браузер говорит, что он умеет проигрывать видео в соответствующем кодеке.
    7. Поддержка WebM
    2 bonus points
    Проверяет, что браузер говорит, что он умеет проигрывать видео в соответствующем кодеке.
    Детальной проверки уровня поддержки video-элемента или track-элеманта внутри видео данный блок тестов не производит.

    Audio 6 tests | 20 points | 5 bonus points


    Аналогично блоку проверки поддержки видео, данный блок проверяет поддержку нового тега <audio>. Дополнительно он проверяет поддержку различных аудио-кодеков.
    1. <audio> элемент
    20 points
    Проверяет, что созданный аудио-элемент поддерживает метод canPlayType.
    2. Поддержка PCM
    1 bonus point
    Проверяет, что браузер говорит, что он умеет проигрывать аудио в соответствующем кодеке.
    3. Поддержка MP3
    1 bonus point
    Проверяет, что браузер говорит, что он умеет проигрывать аудио в соответствующем кодеке.
    4. Поддержка AAC
    1 bonus point
    Проверяет, что браузер говорит, что он умеет проигрывать аудио в соответствующем кодеке.
    5. Поддержка Ogg Vorbis
    1 bonus point
    Проверяет, что браузер говорит, что он умеет проигрывать аудио в соответствующем кодеке.
    6. Поддержка WebM
    1 bonus point
    Проверяет, что браузер говорит, что он умеет проигрывать аудио в соответствующем кодеке.
    Проверки уровня поддержки audio-элемента данный блок тестов не производит.

    Замечание: некорректность проверки кодеков в подобных тестах определяется не только тем, что требование поддержки тех или иных кодеков не определено в спецификации HTML5, но и тем, что это не всегда является (постоянной) характеристикой браузера. Например, IE9 с установленными кодеками WebM от Google получает дополнительных 3 бонусных балла.

    Элементы 8 tests | 38 points


    Данный блок проверяет поддержку различных новых элементов и атрибутов.
    1. Вставка невидимых данных
    4 points
    Проверяется наличие свойства dataset у элементов.
    2. Элементы секций
    7 points 
    (по баллу на каждый элемент)
    Проверяет, что браузер умеет создавать блоковые элементы section, nav, article, aside, hgroup, header и footer.
    3. Поддержка аннотированных блоков (почему-то называется группировкой)
    2 points 
    (по баллу на каждый элемент)
    Проверяет, что браузер умеет создавать блоковые элементы figure и figcapture.
    4. Текстовая семантика
    6 points 
    (по баллу на каждый элемент)
    Проверяет, что браузер умеет создавать элементы описания текстовой семантики:
    • mark
    • ruby, rt, rp
    • time
    • wbr
    Замечание: по последнему тесту есть интересный момент: балл для каждого из элементов mark и ruby/rt/rp дается за т.н. «полную поддержку» элемента, которая, по мнению автора, заключается в правильных значениях стиля элементов по умолчанию. На самом деле:
    • Для mark значения по умолчанию для цвета фона и текста описаны в спецификации как типичные (и разумно могут различаться от одного UA к другому)
    • Для ruby/rt/rp проверяемые значения задаются в разрабатываемом модуле CSS3 Ruby, но никак не в спецификации HTML5.
    5. Интерактивные элементы
    6 points 
    (по баллу на details и summary и по два command и menu)
    Проверяет, что браузер умеет создавать соответствующие элементы: details, summary, command и menu.
    Замечание: внутренняя проверка создания элементов для details и summary не вполне корректна. Для первого — нужно проверять, что он является HTMLDetailsElement, а не HTMLElement (и этот тест должны проваливать все браузеры). Для второго специального DOM-интерфейса не предусмотрено, поэтому тест будет проходиться даже, если браузер создает HTMLElement, но говорит, что не знает, что это за элемент. Более того, правильная проверка должна также учитывать, что summary-элемент имеет смысл только в контексте элемента details.
    6. hidden-атрибут
    1 point 
    Проверяет, что у элементов есть hidden-атрибут.
    7. contentEditable
    10 points 
    Проверяет, что у элементов есть contentEditable-атрибут.
    Замечание: интересно, что iPhone и Android формально поддерживают contentEditable (в наследство от Webkit), но реально его не поддерживают, поэтому для них за этот тест баллы не даются.
    8. API для документа (почему-то называется динамической вставкой)
    2 points 
    (по баллу на каждый пункт)
    Проверяет, что у элементов есть свойство outerHTML и метод insertAdjacentHTML.
    Замечание: к сожалению, также, как и для атрибутов выше, в данном случае не проверяется функционирование указанных свойств и методов — оценивается только их выставление в DOM.

    Формы 3 tests | 90 points


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

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

    Относительно веб-форм, особенно новых элементов ввода, есть много неоднозначных моментов, которые еще будут требовать утряски, и, прежде всего, это касается внешнего вида и взаимодействия с пользователем:
    • Внешний вид элементов не описывается спецификацией, поэтому фактически отдается на откуп разработчикам браузеров. (Схожая проблема есть и у элементов управления аудио/видео, которые во всех браузерах различные.) То, что внешний вид не описываются детально в спецификации, — правильно, потому что в зависимости от особенностей устройства элементы ввода, их UI и UX для пользователя могут различаться (например, на мобильных устройствах). Но вместе с тем, даже на десктопах абсолютной однородности в этом вопросе пока не наблюдается.
    • Стилизация — попробуйте задать единообразный стиль для элементов управления, особенно новых, в которых стили зашиты в коде браузера.
    • Локализация (например, см. контрол выбора времени или даты) — принципиальный вопрос, на сегодня не имеющий однозначного решения. Да, это задача производителей браузера, но на сегодня она не решена.
    Сегодня некоторые браузеры уже начали поддерживать часть или многие из рассматриваемых ниже элементов, и проходят тест, показывая выдающиеся результаты. К сожалению, на практике, это вводит в заблуждение относительно полноценности реализации и возможности использования новых форм в реальных проектах, расчитанных на широкую аудиторию. Увы.

    1. Типы элементов ввода 58 points
    Серия тестов, проверяющих возможность установить у input-элемента тот или иной тип, валидацию и дополнительные возможности в отдельных случаях.
    search
    2 points
    Поддержка типа
    tel
    2 points
    Поддержка типа
    url
    2 points 
    Поддержка типа (баллы), валидация
    email
    2 points 
    Поддержка типа (баллы), валидация
    Даты и время
    24 points 
    (по 4 балла на каждый тип)
    Проверяется для datetime, date, month, week, time, datetime-local:
    • Поддержка типа (баллы)
    • Кастомный стиль для элемента (баллы)
    • Защита от некорректного ввода
    • Поддержка max и min атрибутов
    • Поддержка step, stepDown и stepUp атрибутов
    number, range
    8 points 
    (по 4 балла на каждый тип)
    Проверяется
    • Поддержка типа (баллы)
    • Кастомный стиль для элемента (баллы)
    • Защита от некорректного ввода
    • Валидация
    • Поддержка max и min атрибутов
    • Поддержка step, stepDown и stepUp атрибутов
    color
    4 points 
    Проверяется
    • Поддержка типа (баллы)
    • Кастомный стиль для элемента (баллы)
    • Защита от некорректного ввода
    • Валидация
    checkbox
    1 point 
    Проверяется поддержка indeterminate свойства.
    select
    1 point
    Проверяется поддержка required-атрибута.
    fieldset
    2 points 
    Проверяется, что fieldset содержит свойство elements и атрибут disabled.
    datalist
    2 points 
    Проверяет, что браузер умеет создавать datalist и у input есть list-атрибут.
    keygen
    2 points
    Проверяет, что браузер умеет создавать keygen (баллы) и у него есть свойства challenge и keytype.
    output
    2 points 
    Проверяет, что браузер умеет создавать output-элемент.
    progress
    2 points 
    Проверяет, что браузер умеет создавать progress-элемент.
    meter
    2 points
    Проверяет, что браузер умеет создавать meter-элемент.

    2. Поля 20 points
    pattern, required
    2 points
    (по баллу на каждый атрибут)
    Проверяет наличие атрибутов pattern и required в элеметах input.
    Ассоциации контролов и форм
    8 points
    Проверяет
    • работу свойства control у label-элементов
    • привязку внешних input к форме
    • наличие свойств formAction, formEnctype, formMethod, formNoValidate и formTarget в форме
    • привязку label к элементам ввода (свойство labels)
    Другие атрибуты
    4 points
    Проверяет наличие атрибутов autocomplete, autofocus, placeholder и multiple в элементах input.
    CSS-селекторы
    4 points
    (по баллу на каждый селектор)
    Проверяет поддержку псевдоклассов для элементов ввода: valid, invalid, optional и required.
    События
    2 points
    (по баллу на каждое событие)
    Проверяет поддержку событий input и change.
    3. Формы 12 points
    Валидация
    8 points
    Проверяет наличие метода checkValidity в input.
    События
    2 points
    (по баллу на каждое событие)
    Проверяет поддержку событий forminput и formchange.
    Отправка событий
    2 points
    (по баллу на каждое событие)
    Проверяет поддержку методов dispatchFormInput и dispatchFormChange.
    Замечание: последняя проверка делается с откровенной ошибкой, поэтому не срабатывает даже в тех браузерах, которые данные методы поддерживают. В бета-версии теста обе проверки событий удалены вслед изменениям спецификации, а баллы перераспределены в пользу селекторов выше.

    User Interaction 2 tests | 15 points


    Данный блок включает проверку двух возможностей: Drag&Drop и History API.

    1. Drag &Drop 10 points
    Проверяет поддержку атрибута draggable в элементах.

    Замечание: интересно, что поддержка D&D была еще в четверых версиях Netscape и Internet Explorer. В IE5 она была значительно расширена, и впоследствии также реализована в Safari. Позже, в ходе работы над HTML5 эта реализация D&D была реверс-инжинирована Яном Хиксоном и описана в новом стандарте.

    Основная суть Drag&Drop — в специальных событиях, отмечающих отдельные этапы процесса переноса элементов и перенос данных вместе с элементами через специальные объекты. В общем, D&D в IE5+ есть, но h5t об этом не знает (в отличие от Modernizr), т.к. выносит вердикт только по конкретному не поддерживаемому в IE новому атрибуту.

    2. Session History 5 points
    Проверяется наличие свойства history и метода pushState в нем.

    Web Applications 3 tests | 19 points


    Проверяет поддержку Application Cache (для оффлайновых приложений) и специальных методов в Navigator (для получения информации о получаемых данных).
    1. Application Cache
    15 points
    Проверяется наличие свойства applicationCache в window.
    2. ProtocolHandler
    2 points
    Проверяет наличие метода registerProtocolHandler в navigator.
    3. ContentHandler
    2 points
    Проверяет наличие метода registerContentHandler в navigator.

    Security 2 tests | 10 points


    Проверяет работу с iframe.
    1. sandbox
    5 points
    Проверяет наличие sandbox-атрибута в iframe.
    2. seamless
    5 points
    Проверяет наличие seamless -атрибута в iframe.
    Замечание: т.к. речь идет о такой критичной вещи, как безопасность, то простая проверка наличия этих атрибутов не представляет особой ценности без действительной проверки того, как браузер их обрабатывает, ибо они предполагают довольно интересные сценарии установки ограничений и расширения слияния с окружением, соответственно.

    Блок MicroData 1 test | 15 points


    Оценивается поддержка спецификации HTML Microdata. Проверка включает один тест, сверяющий:
    • поддержку атрибутов itemValue и properties
    • поддержку метода getItems

    Блок Geolocation 1 test | 15 points


    Проверяется поддержка Geolocation. Проверка включает один тест, изучающий наличие свойства geolocation в navigator.

    Блок WebGL 1 test | 15 points


    Оценивается поддержка WebGL. Проверка включает один тест, проверяющий поддержку хотя бы одного из множества контекстов для элемента canvas: 'webgl', 'ms-webgl', 'experimental-webgl', 'moz-webgl', 'opera-3d', 'webkit-3d', 'ms-3d', '3d'. :)

    Блок Communication 3 tests | 25 points


    Проверяет поддержку ряда спецификаций, описывающих сетевое взаимодействие.
    1. Cross-Document Messaging
    5 points
    Проверяет наличие метода postMessage в window.
    2. Server-Sent Events
    10 points
    Проверяет наличие объекта 'EventSource' в window.
    3. Web Sockets
    10 points
    Проверяет наличие объекта 'WebSocket' в window.
    Замечание: как известно, эволюции веб-сокетов не позавидуешь — периодически меняется протокол (иногда несовместимым образом), а из-за угроз безопасности поддержку самих веб-сокетов иногда выключают. Тест также не учитывает экспериментальную реализацию веб-сокетов для IE.

    Блок Files 2 tests | 20 points


    Проверяет поддержку File API (одной из самых сырых (свежих) спецификаций среди всех проверяемых).
    1. FileReader API
    10 points
    Проверяет наличие объекта 'FileReader' в window.
    2. FileWriter API
    10 points
    Проверяет наличие объекта 'FileWriter' в window.
    Замечание: Аналогично случаю с веб-сокетами, на сегодня спецификации далеки от того, чтобы с полной уверенностью можно было говорить о необходимости включения их реализаций в стабильные версии продуктов. Тест также не учитывает экспериментальную реализацию File API для IE.

    Блок Storage 4 tests | 20 points


    Проверяет поддержку ряда спецификация для хранения данных на клиенте.
    1. Session Storage
    5 points
    Проверяет наличие sessionStorage в window.
    2. Local Storage
    5 points
    Проверяет наличие localStorage в window.
    3. IndexedDB
    10 points
    Проверяет наличие объекта indexedDB (или webkitIndexedDB, или mozIndexedDB, или moz_indexedDB) в window.
    Замечение: тест не учитывает экспериментальной реализации IndexedDB для IE.

    4. WebSQL Database
    0(5) points
    Проверяет наличие метода openDatabase в window.
    Замечение: хотя дальнейшие работы над WebSQL Database прекращены, если браузер не поддерживает IndexedDB, тест позволяет набрать ему дополнительные 5 баллов на WebSQL Database (например, в Opera).

    Блок Web Workers 1 test | 10 points


    Проверка поддержки Web Workers — сводится к сверке наличия объекта Worker в window.

    Блок Local Devices 1 test | 20 points


    Проверка возможности создания <device> элемента и наличия у него свойства type.

    Замечание: полтора месяца назад данный тег вырезан как из спецификации от W3C, так и из спецификации от WHATWG, на которую ссылается автор. Реализация соответствующего функционала должна реализовываться через специальный API.

    Блок Other 2 test | 6 points


    Проверяются несколько разрозненных свойств. (Подозреваю, что для круглого счета в тесте.)
    1. Text Selection
    5 points
    Проверяется наличие метода getSelection в window
    Замечание: метод относится к DOM Range и должен перейти в соответствующую спецификацию.
    2. Scrolling
    1 point
    Проверяется наличие метода scrollIntoView у элементов.
    Замечание: метод перенесен в CSSOM.

    Выводы по содержанию тестов


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

    Произвольность раздачи баллов — я об этом уже писал в начале обзора, но повторю еще раз: раздача баллы за различные «достижения» делается на усмотрение автора волевым решением. В итоге где-то за поверхностную проверку вешается по 15 баллов, где-то по 1-2 за проверку наличия свойств, а где-то 5 баллов дается за 19 проверок алгоритма парсинга или 0,26 балла в пересчете на каждую проверку.

    Связанная с произвольностью вещь: перекос акцентов. Как отмечается в начале, очень большой акцент отдается веб-формам (даже с поверхностным подходом), маленький акцент дается проверке деталей работы Canvas, Video или Audio и различных API. Множеством проверок оценивается работа алгоритма парсинга, единичными проверкам оценивается работа API, включающих по 50+ методов и свойств (Canvas) и множество различных нюансов.

    Баги. Они есть — как в проверках, так и относительно проверяемых стандартов или их частей, некоторые из них уже не поддерживаются или трансформированы так, что проверки, включенные в тест не актуальны.

    Тест включает вещи, не имеющие прямого отношения к веб-стандартам — кодеки, и WebGL, являющийся сторонним (не W3C) стандартом.

    Выборочность проверяемых стандартов: помимо того, что треть (по баллам) проверяемых вещей на сегодня не входит в стандарт HTML5, реальность таковая, что ни в области спецификации HTML5, ни в области набора новых спецификаций для Web Apps, не наблюдается 100% покрытия (даже поверхностного).

    Другими словами, есть множество вещей, которые HTML5Test не проверяет совсем…

    Что не тестирует h5t?


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

    Итак, HTML5 test не проверяет:
    • функциональность детектируемых возможностей, в большинстве случаев ограничиваясь проверкой наличия нужного объекта, свойства или метода;
    • всех новых возможностей HTML5, помимо функциональности, без внимания остаются:
      • многие новые (например, role и aria-*) и старые атрибуты, расширившие или изменившие область применения,
      • расширение области действия многих событий
      • и ряд других нюансов относительно изменившегося поведения многих элементов;
    • реальную поддержку SVG или MathML, ограничиваясь распознаванием namespace;
    • множество новых специкаций, которые можно отнести к поколению «HTML5», представляющих не меньший интерес, чем те, что выбрал автор. Например, чтобы дополнительно разбавить акцент на HTML5, можно также тестировать:
      • Navigation Timing
      • Progress Events
      • RDFa API
      • System Information API
      • MediaCapture API
      • Calendar API
      • Clipboard API
      • и ряд других не менее интересных и сырых спецификаций :)

    Выводы

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

    Если задаваться вопросом «можно ли на основании HTML5 test судить об уровне поддержки HTML5 в браузерах», то ответ скорее нет, чем да. У этого есть множество причин, ключевые из них три: поверхностность, несбалансированность и большое количество примесей.

    Если ставить вопрос немного в другом ракурсе: «отображает ли HTML5 test динамику улучшения поддержки HTML5 в браузерах» — то, с учетом внутренней корректности большинства тестов, ответ будет скорее да, чем нет. Это, правда, не исключает того, что поддержка может быть улучшена (по тем или иным направлениям или параметрам), но тест этого не заметит в силу своей выборочности.

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

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 27

      +3
      Собственно хоть и поверхностный, но тест хорош. А о глубокой реализации к MS тоже остаются притензии, например обещали поддержку SVG в IE9, но почему тогда не раобтает, например, визуализатор из темы habrahabr.ru/blogs/algorithm/118554/.
        +7
        Потому что на страницах не прописаны doctype и браузер сваливается в quirks mode.
          +4
          Ухты, действительно при изменении Document Mode на IE9 standarts — всё работает. Пахнет заговором :)
        +13
        Костя, браво! Отличный анализ теста.
          +1
          На хабре. Есть. Тег. <source>. Используйте его, пожалуйста, для подсветки синтаксиса.
            +1
            Спасибо, учту в будущем :)
            +2
            > Какие-то тесты и проверки весят 1 балл, какие-то по 10. Фактически, распределение баллов между тестами и проверками — это полная воля и фантазия автора теста.

            Это утверждение было бы верно, какую бы политику баллов автор не избрал. Но что с того то? Он же не процент поддержки выдает, а балл. Как он их распределяет — его личное дело. Главное, что отношение ко всем браузерам одинаковое.
              +1
              Если вы не заметили, я нигде не утверждаю, что такое распределение выставляет какой-то браузер лучше, чем другие. В свете данной статьи, мне вообще на это плевать ;))

              Вопрос как раз в том, что тест некорректно смещает акценты относительно самого HTML5 и его внутреннего содержания. Если бы я написал тест, в котором за поддержку Canvas давалось 100 баллов, а за все остальное вместе взятое 10, и говорил бы, что тетс проверяет поддержку HTML5, в меня бы смело можно было кидать помидоры за предвзятое отношение в пользу Canvas ;)
                +6
                А представьте гипотетический IQ тест, в котором за знание Французского даётся 5 баллов, а за знание Испанского 25. Ведь главное, что отношение ко всем людям одинаковое.

                Можно ли будет говорить о корректности такого теста?
                  +3
                  Эта аналогия была бы близкой к истине, если бы разные браузеры «говорили» на разных HTML. А на деле, они должны «говорить» на одном и том же и одинаково хорошо.
                  В таком случае исправить аналогию можно так:
                  «А представьте гипотетический IQ тест только для испанцев(отсыл к тому, что все интересующие нас браузеры — HTML браузеры, а не один HTML, другой, скажем, браузер RSS и т.д. ), в котором за знание Французского даётся 5 баллов, а за знание Испанского 25.»

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

                    В принципе, каждый из тестов сам по себе будет оставаться корректным. Можно ли говорить о корректности весовой функции — большой вопрос.
                      0
                      Признаю, не так понял. Кстати, в рамках статьи тогда имело бы большой смысл узнать почему именно такие коэффициенты? Не от балды же в самом деле. Можно автора теста лично спросить или в открытых источниках найти.
                0
                Спасибо! Очень интересно было прочитать.
                  0
                  Отмечу, что последняя канарейка под Win7x64 снова повисла на H5T :( (закинул в трекер).

                  Под убунтой 13.0.752.0 (83651) работает, но вместо обычных 293 выдает 290… ох мутят они там что-то.
                    0
                    Помню как какая-то dev-сборка ещё 6 версии показывала в Acid3 нечто вроде 60 из 100 (хотя ещё 4 набирала 100 из 100). Было забавно. Разрабы, наверное, опять что-то над WebKit экспериментируют.
                    +4
                    Эээ, а, собственно, с какой стати WebGL это некая сторонняя спецификация, если она вполне закончена и её поддерживает как khronos, так и WHATWG. Сторонняя, видимо, потому, что её, как обычно, не поддерживает Internet Explorer, да.

                    А то, что H5T не проверяет чего-то — это не проблема. Создать единый тест, который проверяет все развивающиеся спецификации, это дело не одного дня и не для одного человека. Если автор выбрал некоторые спецификации для проверки, то, по его мнению, они наиболее важные, либо наиболее нужные ему как разработчику и дизайнеру.

                    С коэффициентами, действительно, похоже, что автор от балды их присваивал.

                    И ещё не забываем о:
                    1). When can I use...
                    2). Find me by IP (ещё одна тема для статьи (-: )
                      0
                      А в чем ее поддерживает WHATWG? В khronos она разрабатывается, но вы же не будете утверждать, что khronos == W3C? Просто когда все остальные тестируемые спецификации являются спецификациями W3C, тест называется HTML5 test, а в него включается дополнительная спецификация со стороны (какой бы хорошей она ни была), иначе как сторонней ее назвать и не получается.
                        +1
                        Дык, разработчик теста и говорит о том, что WebGL не развивается в W3C, а в Khronos, при этом это надстройка над HTML5, о чём говорят ребята из Khronos, так и разработчик теста.
                        При этом HTML5 относился ко времени создания теста одновременно и к W3C, и к WHATWG. На страницах WHATWG разработчики тоже кратко называют свои спецификации HTML5, хотя руководство WHATWG уже выразила инициативу отойти от нумерации версий HTML.

                        В обиходе часто говорят, что, мол, эта игра написана на HTML5, при этом, не все дают себе отчёт, что из HTML5 в игре могут использоваться одна-две спецификации, а всё остальное — это JavaScript и CSS3.

                        P. S. А разве спецификация Local Devices относится к W3C?
                          0
                          То есть вы согласны, что это сторонняя спецификация?

                          HTML5 и сегодня продолжает прорабатываться одновременно и в W3C, и в WHATWG. В обиходе под HTML5 (как тренде) понимается все новое поколение веб-стандартов, ну и что с того?

                          Local Device — какое-то время назад их, вроде, вынесли в отдельную спецификацию (dev.w3.org/html5/html-device/), сейчас ее, похоже, отменили. Как минимум в списках рассылки они точно обсуждаются, и обсуждались на прошедшем TPAC. Также в W3C есть специальная рабочая группа Device APIs & Policy.
                            +1
                            Сторонняя от W3C? Да. Сторонняя от HTML5? Нет.
                              0
                              Так никто же и не спорит с тем, что WebGL расширяет HTML5, «используя canvas для вывода результатов рендеринга».
                                +1
                                А по какому пути будет развиваться IE10? W3C only или может быть и WHATWG захватит?
                                  0
                                  А что вы понимаете под «WHATWG захватит»?
                                    0
                                    Честно сказать даже не знаю, как корректно спросить :)
                                    Будет ли что-то в IE10 из WHATWG, чего нет в W3C? Наверное так…
                                      0
                                      Встречный вопрос: что-то из WHATWG, чего нет в W3C — это вы о чем конкретно?
                                        0
                                        Несколько встречных вопросов подряд — это уже ответ. Я так понимаю: MS не собираются считаться с WHATWG.
                                          0
                                          Не уверен, что формулировка «считаться» является правильной. MS является участником дейятельности W3C и не входит в WHATWG. Мое личное мнение: не вижу причин, почему нужно что-то делать совместно с или в рамках WHATWG. Спецификации новых стандартов вполне успешно прорабатываются в W3C, причем во многом теми же людьми, кто работает в WHATWG.

                                          Поэтому интересен ответ на вопрос: что такого делается в WHATWG, что не планируется утверждать в качестве стандарта W3C?

                    Only users with full accounts can post comments. Log in, please.