HTML5テストへの没入

(これは、さまざまなブラウザーテストのレビューに関する一連の記事の2番目の記事です。このシリーズの前半: ACID3の浸漬 。)

HTML5Test (以下h5t )への参照の大部分から判断すると、このテストのほとんどのユーザーは、結果の内部の本質ではなく、参照および比較に使用できる指標として、最終結果(ポイントの合計)に関心があります。



一般の人々では、これはpuzomerkiと呼ばれ、約1年前にLenta.ru(下記参照)で適切に気づいたように-「HTML5の方が長い」。



Lenta.ruから始めましょう。 1年前に最初に登場したテストへの参照です。
最新のWeb標準との互換性についてブラウザをテストしました
Webサイトhtml5test.comが3月にWebに登場しました。名前が示すように、特定のブラウザーが非常に有望な新しいHTML5 Web標準でどのように動作するかを確認します。

私の目の前には、「コンピュータービルド#02(125)/ 2011 という番号もあります。 「大規模な」ブラウザテストが配置されています(「18ページのメガテスト」)。
ほとんどのWebページは、HTMLハイパーテキストマークアップ言語で記述されています。 ページを正しく表示するには、ブラウザがソースコードに含まれるすべてのタグを読み取る必要があります。 この行は、ブラウザがエラーなしで表示した384ページの数を示します。

384ページのうち300ページがHTML5テストの結果であり、残りの84ページは指定されていません。 :)

Computerra がMozilla Fennecについて語っています:
HTML5サポートテストはFennecに合格し、207ポイントという良い結果を得ましたが、iOSのSafariは185ポイントしか得られません。

悲しいことに、Habrもテストに関して優れた分析を行っています。 以下は、Operaの新しい解析エンジンに関する投稿の最近のリンクの1つです。
ラグナロクは、やや不完全な(したがって誤解を招く)html5test.comで11点中11点(プラス2ボーナスポイント)を獲得していますHTML5の埋め込みSVGおよびMathMLには2ボーナスポイント

問題は、Operaがずっと前にSVGをサポートしていたことだけでなく、OperaでネイティブMathMLがサポートされていないことだけです(MathMLプロファイルのCSSによる部分的なサポートがあります)。

ブラックボックス


実際、 h5tはある種のブラックボックスとして使用され、「HTML5標準の1つまたは別のブラウザのサポートを確認する」ため、非常に多くが参照し、完全に信頼されています。



もちろん、一般のユーザーやほとんどのジャーナリストよりもWeb開発に没頭している人は、テストが数字を与えるだけでなく、ブロックに分割されていることを理解しています-テストページでは、ポイントが与えられたポイントを追跡できます。 つまり、テストによれば、正確に機能するものと機能しないものです。 明らかな例えは、燃えている電球の数を計算することです:



そして、ここで最も興味深い部分が始まります:各電球の意味、なぜいくつかの電球は大きく、他の電球は小さく、なぜすべての電球が点灯しないのか、そして結局のところ、電球はHTML5サポートをテストするという目的をどれだけ満たしていますか?

注釈 :テストは常に進化していることに注意してください。1年前にテストへの参照を参照すると、ポイントの合計数とテストのセットが異なっていたことがわかります。 現在の400ポイントのバーは、将来変更される可能性があります。

一般的に、すべてを順番に処理しましょう。

誰がh5tを発明したのですか?

HTML5Testの作成者はNiels Leenheerです。 ブログのNielsによる 、彼はグラフィックデザイナーおよびWebプログラマーとして、Geeklog、Nucleus CMS、Zenphoto、Mozilla、KHTML、WebKitなど、さまざまなオープンソースプロジェクトに定期的に貢献しています。各プロジェクトへの貢献については、 http://rakaz.nl/codeをご覧ください)。

さらに興味深い詳細として:

Web標準化団体との連携


Acid3とは異なり、h5tはWeb標準を開発または促進する組織に関連付けられていません。 テスト作成者が書いたものは次のとおりです。
HTML5テストはW3CまたはHTML5ワークグループとは関係がないことに注意してください。

私の知る限り、公式の通信でHTML5サポートの基準としてh5tを参照しているブラウザメーカーは1社もありません。 (OK、エバンジェリストのMozilla Paul RougetからのIE9とFx4.0についての有名なトロロロの投稿を除きます。)

h5tはどのように機能しますか?

テストの内部構造は、ページのコードとgithubのソースコードの両方で直接トレースできます。 Acid3とは異なり、h5tは美しい画像の生成を意味しません。テストのポイント数と詳細の形式での一般的な結果のみです。

テストの構成:

テストエンジン


テストエンジンは、いくつかの重要な機能(オブジェクト)で構成されています。
一般に、このメカニズムは、新しいテストを自由に追加したり、現在の操作やその他の興味深い操作を修正したりするのに十分な柔軟性を備えています。 (必要に応じて使用する場合は、テストページの最初にある著作権を参照してください。)

テストスイート


各テストスイートは、テストの数、スイートの名前、およびテスト自体を格納する個別の関数によって表されます。

テストの内部構造はさまざまですが、セットの一般的な構造は次の例で明確に見ることができます。

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 .

すべてのテストは個別の関数t iとして実行され、テストプロセス中にセットが初期化されると、ブラウザーはセット内で説明されているすべてのメソッドを実行します。

各メソッド自体が、テストの合格または不合格に関する情報、このテストに依存するポイント数、および追加のメタ情報(仕様への参照からテストの部分的または完全性に関する定式化まで)を収集結果に追加します(結果オブジェクトはテストエンジンから渡されます) 。

より複雑なテスト(Webフォームなど)では、結果をグループ化するためにやや複雑な構造を使用しますが、本質は変わりません。

テストの動作のメカニズムが一般的な用語で理解されたので、テスト自体の内部キッチンの詳細に移りましょう。

h5tは何をチェックしますか?

h5tが仕様または仕様の一部への参照(常に正しいとは限らない)で具体的にチェックするもののリストは、テストページで直接見つけることができるため、ここで複製する意味はあまりありません。 内部で何が起こっているのか、各テスト機能の背後に何があるのか​​を理解することは、はるかに重要です。

まず、テスト対象の個々のブロックがテストに従って分散され、ポイントに変換される方法、およびこれがすべてHTML5標準と相互接続される方法を見てみましょう。

構成


最初に目を引くのは、今日の「チェック済み」要素の大部分がHTML5仕様に含まれていないことです。



これらの要素の一部はHTML5仕様から除外され、別の標準(HTML Microdataなど)に割り当てられましたが、一部はこの仕様に含まれていません(FileAPIなど)。

Web標準に直接関係しないものもあります(コーデック—サポートのために追加のボーナスポイントが提供されます)。

最後に、WebGLはHTML5に直接関連しないサードパーティ仕様です(Canvasを使用してレンダリング結果を表示します)。

割合


間違いなく注意すべき2番目の重要な点は、異なる仕様間およびHTML5仕様内でのスコアの分布です。

したがって、膨大な数のポイント(400のうち90)がフォームの新しい要素に割り当てられます-合計金額のほぼ4分の1またはHTML5に直接割り当てられたポイントの3分の1。 もちろん、Webフォームは新しい仕様の重要なコンポーネントですが、今日では、このコンポーネントが需要で支配的と呼ばれることはほとんどありません(詳細については以下を参照)。

すべての新しいHTML5セマンティック要素と同じくらい多くのポイントがビデオの操作に割り当てられます。 Canvasでは、Audioよりもはるかに少ない量が割り当てられます。

いくつかのテストとチェックの重さは1ポイント、いくつかは10です。実際、テストとチェックの間のポイントの分布は、テストの作成者の完全な意思と想像です。

ステータス


念頭に置かなければならない問題の第3の側面は、どの仕様が現在の状態でどのような条件でチェックされているかに関するものです。

内側に掘り始めると、表面に最初に現れるのは、ほとんどの仕様の現在のドラフトステータスです。



2番目に重要なのは、多くの仕様の初期の状態と変動性です。上の図では、過去3年間の各標準の仕様更新の頻度を確認できます。 上記のように、場所によっては、テストがWeb標準の分野における実際の状況に対応しなくなるような変動性があります

テスト作成者が書いたものは次のとおりです。
テスト対象の仕様はまだ開発中であり、公式になるまで変更される可能性があることに注意してください。

各テストの内容を詳しく見てみましょう。

HTML5ブロック


中心となるテスト全体で最大のブロック。 これらまたはこれらの要素をテストするいくつかの内部部品で構成されています。

5つのテストの解析| 11ポイント| 2ボーナスポイント


このテストブロックは、ドキュメントの解析、特にHTML5仕様に準拠したさまざまなエキゾチックで不正なマークアップオプションの解析に関するいくつかのルールをチェックします。

1. <!Doctype html> 1ポイントのサポート
「doctypeがインストールされている場合、ブラウザはストリクトモードで動作する」ことを確認します。 内部では、document.compatMode == "CSS1Compat"のチェックが行われます。 このプロパティは、ブラウザが現在動作しているモードを特徴づけます(Quirks vs. Strict)。

実際、有効なDoctypeがある場合、ブラウザはストリクトモードで動作するはずです。つまり、このチェックはHTML5に直接関連していません。 IE6でも<!Doctype html>の厳格なモードが含まれますが、これは明らかにHTML5をサポートしていません。

2. HTML5トークナイザー5ポイント
要素の名前、属性、およびコンテンツを割り当てるさまざまなエキゾチックなケースがチェックされます-html要素の内部コンテンツを正しく解析するために合計19のチェックがあります。

人生でこれらのケースのほとんどに直面する必要はほとんどありませんが、HTML5仕様はドキュメントの解析とそのような例の適切な処理に本当に注意を払っていることに注意することが重要です。

(実際、ほぼ文字通り、これらのテストはMozilla HTML解析テストに基づいています: http : //hsivonen.iki.fi/test/moz/detect-html5-parser.html

3. 5ポイントの HTML5ツリー構築
ドキュメントの解析のトピックの続きは、同じ元のテストソースでさまざまな要素を動的に作成することです。

:特定の機能の実装の詳細を確認し、ドキュメント解析の相互運用性を検証するh5tのテストは、これと以前のテストのみです。

(他のテストとは異なり、解析テストは、Firefox 4のHTML5パーサーの開発に非常に関与していることでも知られているHenri Sivonenから借用したことを繰り返します。つまり、これらは実際に発明されたテストですそのようなコレクションの重要な特徴は、それらが正しいままであっても、テストされた機能の100%または密接なカバレッジを主張できないことです。言い換えれば、これは著者にとって興味深いコードバリエーションの選択的テストです。

4.テキスト/ htmlのSVG1ボーナスポイントブラウザーが、対応するネームスペースによってドキュメントに挿入されたSVGコンテンツを認識できることを確認します。
5.テキスト/ htmlのMathML1ボーナスポイント対応する名前空間によってドキュメントに挿入されたMathMLコンテンツをブラウザが認識できることを確認します。
ブラウザがSVGまたはMathMLをサポートしているかどうかは実際にはチェックされていません

予想外に、テストはOperaに失敗します。Operaは歴史的に最高のSVGサポートの1つを持っています。 真のMathMLサポートはFirefoxでのみ利用可能です。 ChromeはMathML自体のサポートがなくてもこのテストに合格します( Mozillaテストケースで確認できます)。

:正式には、svgおよびmath要素の内部コンテンツと解析/マッピングルールは個別の仕様で記述されます。 HTML5仕様では、ドキュメントは<svg>タグおよび特別な<math>タグを使用したMathMLコンテンツを介したSVGコンテンツの挿入をサポートする必要があるとされています。

Canvas 3テスト| 20ポイント


このテストブロックはCanvasサポートをチェックします。 実際、以下の説明からわかるように、ブラウザーがcanvasタグをサポートし、JavaScriptから操作するための正しいコンテキストを返すという事実のみがチェックされます。
1. <canvas>要素
5ポイント
作成されたキャンバス要素にgetContextメソッドがあることを確認します。
2.2dコンテキスト
10ポイント
CanvasRenderingContext2Dオブジェクトがサポートされていることを確認し、getContext(「2d」)メソッドを呼び出すと、このオブジェクトのインスタンスが返されます。
3.テキストのサポート
5ポイント
結果のコンテキストにfillTextメソッドがあることを確認します。
残念ながら、 このブロックは、canvasのサポートレベルと実装の互換性の重要な検証を行いません

ビデオ7テスト| 31ポイント| 8ボーナスポイント


このブロックは、新しい<video>タグのブラウザーサポートを確認するように設計されています。 さらに、さまざまなコーデックのサポートをチェックします。これは、HTML5仕様とは関係ありませんが、興味深いものです。
1. <video>要素
20ポイント
作成されたビデオ要素がcanPlayTypeメソッドをサポートしていることを確認します。
2.追跡サポート
10ポイント
ブラウザがtrack要素を認識することを確認します。
3.ポスターサポート
1点
動画要素がポスターをサポートしていることを確認します。
4. MPEG-4をサポート
2ボーナスポイント
ブラウザが適切なコーデックでビデオを再生できると言っていることを確認します。
5. H.264をサポート
2ボーナスポイント
ブラウザが適切なコーデックでビデオを再生できると言っていることを確認します。
6. Ogg Theoraのサポート
2ボーナスポイント
ブラウザが適切なコーデックでビデオを再生できると言っていることを確認します。
7. WebMサポート
2ボーナスポイント
ブラウザが適切なコーデックでビデオを再生できると言っていることを確認します。
このテストブロックは、ビデオ内のビデオ要素またはトラック要素のサポートレベルの詳細なチェックを実行しません

オーディオ6テスト| 20ポイント| 5ボーナスポイント


ビデオサポートチェックブロックと同様に、このブロックは新しい<audio>タグのサポートをチェックします。 さらに、さまざまなオーディオコーデックのサポートを確認します。
1. <audio>要素
20ポイント
作成されたオーディオ要素がcanPlayTypeメソッドをサポートしていることを確認します。
2. PCMサポート
1ボーナスポイント
ブラウザが適切なコーデックでオーディオを再生できると言っていることを確認します。
3. MP3サポート
1ボーナスポイント
ブラウザが適切なコーデックでオーディオを再生できると言っていることを確認します。
4. AACのサポート
1ボーナスポイント
ブラウザが適切なコーデックでオーディオを再生できると言っていることを確認します。
5. Ogg Vorbisのサポート
1ボーナスポイント
ブラウザが適切なコーデックでオーディオを再生できると言っていることを確認します。
6. WebMサポート
1ボーナスポイント
ブラウザが適切なコーデックでオーディオを再生できると言っていることを確認します。
このテストブロックでは、audio要素のサポートレベルはチェックされません

:このようなテストでのコーデック検証の不正確さは、特定のコーデックをサポートするための要件が​​HTML5仕様で定義されていないという事実だけでなく、これが常に(永続的な)ブラウザー特性ではないという事実によっても決定されます。 たとえば、GoogleからWebMコーデックがインストールされたIE9は、さらに3つのボーナスポイントを受け取ります。

Elements 8テスト| 38ポイント


このブロックは、さまざまな新しい要素と属性のサポートをチェックします。
1.不可視データを挿入する
4ポイント
要素のデータセットプロパティをチェックします。
2.セクション要素
7ポイント
(各アイテムのスコア)
ブラウザがセクション、ナビゲーション、記事、脇、hgroup、ヘッダー、フッターのブロック要素を作成できることを確認します。
3.注釈付きブロックのサポート (何らかの理由でグループ化と呼ばれる)
2点
(各アイテムのスコア)
ブラウザがブロック要素figureとfigcaptureを作成できることを確認します。
4.テキストのセマンティクス
6ポイント
(各アイテムのスコア)
ブラウザがテキストセマンティクスの説明要素を作成できることを確認します。
  • マーク
  • ルビー、rt、rp
  • 時間
  • wbr
:最後のテストによると、興味深い点があります。各要素markとruby / rt / rpのスコアは、いわゆる 著者によると、要素のスタイルの正しいデフォルト値で構成されている要素の「完全サポート」。 実際には:
5.インタラクティブな要素
6ポイント
(詳細と要約のスコア、およびコマンドとメニューによる2)
ブラウザが適切な要素(詳細、概要、コマンド、メニュー)を作成できることを確認します。
:詳細および要約の要素を作成するための内部チェックは完全に正しいわけではありません。 最初に、それ HTMLElementではなくHTMLDetailsElementであることを確認する必要があります(すべてのブラウザーがこのテストに失敗するはずです)。 2番目の特別なDOMインターフェースには提供されていないため、ブラウザーがHTMLElementを作成してもテストに合格しますが、この要素が何であるかはわかりません。 さらに、適切な検証では、summary要素がdetails要素のコンテキストでのみ意味をなすことも考慮する必要があります。
6.隠し属性
1点
要素に非表示属性があることを確認します。
7. contentEditable
10ポイント
要素にcontentEditable属性があることを確認します。
:iPhoneとAndroidが正式にcontentEditable(Webkitから継承)をサポートしますが、実際にはサポートしないため、このテストではポイントが与えられません。
8.ドキュメントのAPI (何らかの理由で動的挿入と呼ばれる)
2点
(各アイテムのポイント)
要素にouterHTMLプロパティとinsertAdjacentHTMLメソッドがあることを確認します。
:残念ながら、上記の属性については、この場合、指定されたプロパティとメソッドの機能はチェックされません-DOMでの露出のみが評価されます。

フォーム3テスト| 90ポイント


:Webフォームはさまざまな観点から非常に興味深いオブジェクトですが、このテストでのそれらへの注意は一般的に大きすぎて表面的すぎ、他のHTML5要素と比較して著しく深く、特に実際の写真。

すでに述べたように、WebフォームはHTML5の重要な部分です。 歴史的な側面では、HTML5はWeb Applications 1.0プロジェクトから発展し、その後、新しいフォーム要素と既存の要素への追加を記述するWeb Forms 2.0仕様の一部として含まれました。 したがって、もちろん、他の要素がふさわしいので、Webフォームは多くの注目に値しますが、たとえば、キャンバス、メディア要素、セマンティック構造タグ、およびさまざまなAPIとは異なり、HTML5の話題の焦点にはなりませんでした。

Webフォーム、特に新しい入力要素に関しては、まだ整理が必要なあいまいな点が多くあります。まず第一に、これは外観とユーザーインタラクションに関係します。
今日、一部のブラウザーは、以下で説明する要素の一部または多くを既にサポートし始めており、テストに合格して、優れた結果を示しています。 残念ながら、実際には、これは完全な実装と、幅広いユーザー向けに設計された実際のプロジェクトで新しいフォームを使用する可能性に関して誤解を招きます。 ああ。

1.入力要素の種類58点
特定のタイプの入力要素、検証、および場合によっては追加機能を設定する機能を検証する一連のテスト。
検索する
2点
型サポート
tel
2点
型サポート
url
2点
サポートタイプ(ポイント)、検証
メール
2点
サポートタイプ(ポイント)、検証
日時
24ポイント
(タイプごとに4ポイント)
日時、日付、月、週、時刻、日時ローカルの確認:
  • タイプサポート(ポイント)
  • アイテムのカスタムスタイル(ポイント)
  • 無効な入力保護
  • 最大および最小属性のサポート
  • step、stepDown、stepUp属性のサポート
数、範囲
8ポイント
(タイプごとに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メソッドが存在するかどうかを確認します。
イベント
2ポイント
(各イベントのポイント)
forminputおよびformchangeイベントのサポートを確認します。
イベントディスパッチ
2ポイント
(各イベントのポイント)
dispatchFormInputおよびdispatchFormChangeメソッドのサポートを確認します。
:最後のチェックは率直なエラーで行われるため、これらのメソッドをサポートするブラウザーでも機能しません。テストのベータ版では、仕様の変更続いて両方のイベントチェックが削除され、上記のセレクターに有利になるようにポイントが再配布されました。

ユーザーインタラクション2テスト| 15ポイント


このブロックには、ドラッグアンドドロップと履歴APIの2つの可能性のチェックが含まれます。

1.ドラッグアンドドロップ10ポイント
要素のドラッグ可能な属性のサポートを確認します。

:D&DサポートがNetscapeおよびInternet Explorerの4つのバージョンにまだあったことは興味深いです。 IE5では大幅に拡張され、その後Safariにも実装されました。後に、HTML5での作業中に、このD&D実装はIan Hicksonによってリバースエンジニアリングされ、新しい標準で説明されました。

ドラッグアンドドロップの主な本質は、要素を転送し、特別なオブジェクトを介して要素と一緒にデータを転送するプロセスの個々の段階をマークする特別なイベントです。一般に、IE5 +にはD&Dがありますが、h5tは(Modernizrとは異なり)それについては知りません。IEでサポートされていない特定の新しい属性でのみ判定をレンダリングします。

2.セッション履歴5ポイント
履歴プロパティとその中のpushStateメソッドの存在を確認します。

Webアプリケーション3テスト| 19ポイント


Application Cache(オフラインアプリケーション用)およびNavigatorの特別なメソッド(受信データに関する情報を受信するため)のサポートを確認します。
1.アプリケーションキャッシュ
15ポイント
ウィンドウ内のapplicationCacheプロパティの存在を確認します。
2. ProtocolHandler
2点
ナビゲーターのregisterProtocolHandlerメソッドの存在を確認します。
3. ContentHandler
2点
ナビゲーターのregisterContentHandlerメソッドの存在を確認します。

セキュリティ2テスト| 10ポイント


iframeの動作を確認します。
1.サンドボックス
5ポイント
iframeのサンドボックス属性をチェックします。
2.シームレス
5ポイント
iframeのシームレスな属性をチェックします。
:なぜなら セキュリティなどの重要な要素であるため、これらの属性の存在を簡単に確認することは、実際にブラウザがどのように処理するかを確認しなくてもほとんど価値がありません。

MicroDataブロック1テスト| 15ポイント


HTML Microdata仕様のサポートが評価されました。テストには、次のことを検証するテストが1つ含まれています。

ブロックジオロケーション1テスト| 15ポイント


ジオロケーションのサポートを確認しました。このテストには、ナビゲーター内の位置情報プロパティーの存在を調べる1つのテストが含まれています。

WebGLブロック1テスト| 15ポイント


WebGLサポートは評価中です。テストには、canvas要素の多くのコンテキストの少なくとも1つのサポートをチェックする1つのテストが含まれます: 'webgl'、 'ms-webgl'、 'experimental-webgl'、 'moz-webgl'、 'opera-3d'、 'webkit-3d' 、「ms-3d」、「3d」。 :)

通信3テストブロック| 25ポイント


ネットワーク接続を説明する多くの仕様のサポートを検証します。
1.クロスドキュメントメッセージング
5ポイント
ウィンドウ内のpostMessageメソッドの存在を確認します。
2.サーバー送信イベント
10ポイント
ウィンドウ内の「EventSource」オブジェクトの存在を確認します。
3. Webソケット
10ポイント
ウィンドウ内の「WebSocket」オブジェクトの存在を確認します。
:ご存じのように、Webソケットの進化はうらやましいものではありません。プロトコルは定期的に変更され(互換性がない場合もあります)、セキュリティ上の脅威により、Webソケット自体のサポートがオフになっていることがあります。このテストでは、IE用のWebソケットの実験的な実装も考慮していません

ブロックファイル2テスト| 20ポイント


File APIのサポートをチェックします(チェックされたすべての中で最も生の(最新の)仕様の1つ)。
1. FileReader API
10ポイント
ウィンドウ内の「FileReader」オブジェクトの存在を確認します。
2. FileWriter API
10ポイント
ウィンドウ内の「FileWriter」オブジェクトの存在を確認します。
:Webソケットの場合と同様に、今日の仕様では、製品の安定バ​​ージョンに実装を含める必要性について十分な自信を持って話すことができません。このテストでは、IE用のFile APIの実験的な実装も考慮していません

ストレージ4テストブロック| 20ポイント


クライアントにデータを保存するための多くの仕様のサポートを確認します。
1.セッションストレージ
5ポイント
ウィンドウ内のsessionStorageを確認します。
2.ローカルストレージ
5ポイント
ウィンドウでlocalStorageを確認します。
3. IndexedDB
10ポイント
ウィンドウ内のindexedDBオブジェクト(またはwebkitIndexedDB、mozIndexedDB、またはmoz_indexedDB)の存在を確認します。
:このテストでは、IE用のIndexedDB実験的な実装を考慮していません

4. WebSQLデータベース
0(5)ポイント
ウィンドウ内のopenDatabaseメソッドを確認します。
:ブラウザがIndexedDBをサポートしていない場合、WebSQLデータベースの追加作業は中止されていますが、テストでは、WebSQLデータベース(たとえばOpera)でさらに5ポイントを獲得できます。

Web Workers Block 1テスト| 10ポイント


Web Workersサポートの確認-それは、ウィンドウ内のWorkerオブジェクトの存在を確認することになります。

ローカルデバイスのブロック1テスト| 20ポイント


<device>要素を作成できるかどうか、およびtypeプロパティが存在するかどうかを確認します。

:1か月半前、このタグはW3C仕様と著者が参照したWHATWG仕様の両方から切り取られました。対応する機能の実装は、特別なAPIを介して実装する必要があります。

ブロック2その他のテスト| 6ポイント


いくつかの異なるプロパティがチェックされます。(テストのラウンドスコアについては疑いがあります。)
1.テキスト選択
5ポイント
ウィンドウのgetSelectionメソッドを確認します
:メソッドはDOM範囲に属し、対応する仕様入らなければなりません
2.スクロール
1点
要素のscrollIntoViewメソッドの存在を確認します。
:メソッドはCSSOMに移植されています

テストの内容に関する結論


テストのスキャンと説明を見るときに最初に思い浮かぶのは、表面的なことです。さまざまなブラウザーでHTML5のサポートレベルをチェックするという大きなタスクを設定するテスト(いずれにしても、これがどのように認識されるか)は、特定のプロパティとメソッドの存在の正式なチェックに限定されます。

ポイントの分配の意性 -私はすでにレビューの最初にこれについて書きましたが、繰り返します。さまざまな「成果」に対するポイントの分配は、著者の裁量で故意の決定によって行われます。その結果、表面的なチェックの場合は15ポイント、プロパティの存在の場合は1〜2ポイント、解析アルゴリズムの19チェックでは5ポイント、各チェックでは0.26ポイントがハングします。

任意:バイアスアクセント。冒頭で述べたように、Webフォームには非常に大きな重点が置かれ(表面的なアプローチでも)、Canvas、VideoまたはAudio、およびさまざまなAPIの詳細の確認に小さな重点が置かれます。多くのチェックが解析アルゴリズムの動作を評価し、単一のチェックは50を超えるメソッドとプロパティ(キャンバス)および多くの異なるニュアンスを含むAPIの動作を評価します。

バグそれらは存在します-検査と検証可能な標準またはそれらの部分の両方に関して、それらのいくつかはもはやサポートされないか、テストに含まれるチェックが関連しないように変換されます。

このテストには、Web標準に直接関連しないもの、つまりコーデック、およびサードパーティ(非W3C)標準であるWebGLが含まれます。

テストされた標準の選択性:現在確認されているものの3番目(ポイント単位)がHTML5標準に含まれていないという事実に加えて、現実には、HTML5仕様の分野でも、Web Appsの新しい仕様のセットでも、100%のカバレッジがあります(偶数表面的)。

言い換えれば、HTML5Testがチェックしないことはたくさんあります...

h5tをテストしないのは何ですか?


著者が彼の発案について言っていることを見てみましょう:
HTML5のテスト結果は、ブラウザーが今後のHTML5標準および関連する仕様をどれだけサポートしているかを示す単なる指標です。彼はHTML5のすべての新機能をテストしようとはしていません。また、検出可能なすべての機能の機能もテストしていません。

そのため、HTML5テストでチェックしません

結論

結論は、いつものように、あなたの目標とあなたが答えたい質問に依存します。

「HTML5テストに基づいて、ブラウザーでのHTML5サポートのレベルを判断することは可能ですか」という質問をした場合、答えはおそらく「はい」にすぎません。これには多くの理由があり、そのうちの3つが重要です:表面性、不均衡、および多数の不純物。

「HTML5テストは、ブラウザーでのHTML5サポート改善ダイナミクスを示します」- わずかに異なる視点で質問をすると、ほとんどのテストの内部的な正確さを考えると、答えはそうではありません。ただし、これは、サポートを(ある方向または別の方向に)改善できる可能性やパラメーターを除外しませんが、選択性のためにテストはこれに気付きません。

技術的な面では、HTML5テストは、ブラウザをテストするための十分に構築されたアーキテクチャの例として、非常に興味深いものです。

Source: https://habr.com/ru/post/J118641/


All Articles