AngleSharpドキュメントの日本語訳. C#で利用できるhtmlパーサーのAngleSharpプロジェクトのドキュメントの翻訳です。
原文「Features」
このページ（原文ページ）は、Florian Rapplによって編集されました。 2015年8月27日・4改訂
含まれる機能
Included features
このページは、公開予定から実装された機能に移動された機能を一覧にしています。それは、利用可能なすべての機能が、含まれていません。それにもかかわらず、これは、このページの最終的な目標かもしれません。ここで実装された機能を移動する目的は、使用された参照の履歴を維持することです。そうすれば、W3C仕様の変更、あるいは、テストが行方不明になる場合、追跡が簡単になるはずです。
変遷の記録
Mutation records
MutationObserver、MutationObserverInit、IMutationRecordのような、実装されている型があります。
これらの型は、DOMの何かが変更されたとき、発生する、一般的な通知リスナのように動作することができます。また、それらは、ノードによって内部で使用されます。それは、それらのコンテンツが、変更されたとき、知っている必要があるかもしれません。一例として、新しいコンテンツを解析し、評価する必要があるため、その内容が変化したとき、HtmlStyleElementは、知っている必要があります。
状態：テストは、実装され、利用可能です。
詳細については、以下で見つけることができます。：
さまざまなUri実装を提供します
Provide various Uri implementations
AngleSharpには、URIパーサーが含まれています。このパーサは、ほぼ完成していますが、それは、一部のホストのためのユニコード正規化を行いません。これは、あまりに重くて、通常、.NET Frameworkで、提供する必要がありますが、私たちのPCLターゲットはそうではありません。
状態：テストは、実装され、利用可能です。
詳細については、以下で見つけることができます。：
擬似要素の統合
PseudoElement integration
CSSは、HTML標準で説明されるDOMに、いくつかの拡張機能を提供します。これらの拡張機能の1つは、いわゆる疑似要素の統合です。これらの要素は、実際には、DOMに存在しませんが、それらは、問い合わせることができ、また、それらはビジュアル・ツリーの一部です。
疑似要素は、実在の要素のようではなく、AngleSharpのIPseudoElementと呼ばれる、特別なIDLを実装するだけです。最も重要なことは、このインターフェイスは、IGetStyleUtilsインターフェイスの実装を示します。それで、疑似要素は、実在の要素ではありませんが、描画プロセスの一部として必要な、最も重要なプロパティを持っています。
状態：最小限の実装が、提供されています。まだ、テストは存在しません。
詳細については、以下で見つけることができます。：
拡張ウィンドウ・インタフェース
Extend IWindow interface
DOMのあらゆる対話処理のための中心(少なくとも、（JavaScript）開発者の視点から）は、通常は、Windowオブジェクトの（ルート）コンテキスト・オブジェクトです。AngleSharpは、オブジェクトのようなIDLとして、IWindowインターフェイスを使用します。利用可能なクラスであるにもかかわらず、v0.7 AngleSharpのAnalysisWindowは、Windowクラス実装を一つだけ提供します。それは、遙かに一般的で、RenderDevice情報と一緒に動作する場合があります。
また、Windowの実装は、タイマーなどが含まれており、とても便利です。それは、極めて重要で、ブラウジング・コンテキストから大量に使用されます。しかしながら、カスタム実装を提供できます。
状態：最小限の実装が、提供されています。まだ、テストは存在しません。
詳細については、以下で見つけることができます。：
イベント処理
Event handling
イベント・リスナーを追加、あるいは、削除する機能は、ディスパッチ機能と一緒に含まれています。 また、完了したことは、全ての.NETイベント・ハンドラの明確な形式への変換です。
次の例を考えてみます：
public event EventListener Aborted;これは、暗黙的なイベントハンドラです。C#コンパイラは、nullに初期化される、バッキング・デリゲート・フィールドを作成するでしょう。これらの演算子が、Abortedフィールドで適用されるとき、追加+=と一部の削除-=が、使用されるでしょう。
変換により、次のコードが生成されました。：
public event EventListener Aborted
{
add { AddEventListener(EventNames.Abort, value); }
remove { RemoveEventListener(EventNames.Abort, value); }
}ここでは、バッキング領域は、もはや作成されません。私たちは、AddEventListener/RemoveEventListenerメソッドだけを呼び出す、addとremoveメソッドを明示的に定義します。 イベントの名前は、MDNイベント参照で見つけることができます。通常、それは、接頭辞のない、公式のDOMの名前（例えば、onabort）です。
これは、読み取り専用の静的フィールドとして、EventNamesクラスに追加されます。：
public static readonly String Abort = "abort";状態：テストは、実装され、利用可能です。
詳細については、以下で見つけることができます。：
コアDOMアルゴリズムを調整する
Rework core DOM algorithms
コアDOMアルゴリズムは、MDNやW3Cドキュメントを使用して実装されています。とはいうものの、エッジケースでは予想通り、いくつかのこれらの内部の作業が、動作しないことは、明らかでした。その結果、より関連した情報を持つ詳細な情報を提供するように、WHATWGドキュメントは、考慮されるでしょう。
また、APIは、副作用として、部分的に適応しています。結局は、これは、標準に準拠する考え方からだけでなく、また、ユーザーにとっても有益です。エッジ・ケースは、HTML5パーサ内だけでなく、DOMのやり取り中にも機能する必要があります。
状態：いくつかのテストは、実装され、利用可能です。
詳細については、以下で見つけることができます。：
コンテキストの閲覧
Browsing context
現在、AngleSharpは、HTML（とCSS）を解析する、大きな仕事をする上で、純粋に焦点を合わせようとしています。しかしながら、後の段階で、このライブラリ上で、さらに構築することを望むかもしれません。その結果、（そして、完全にW3Cに、準拠します）、実際にコンテキストを閲覧するために、登録/作成/開く機能が、必要です。
閲覧するコンテキストは、さまざまな部分を接続します。それには、（前の）文書を含むリストが含まれており、どんな文書が、現在調べられるかを認識しています。それは、現在アクティブな文書のIWindowオブジェクトに、すべての呼び出しを転送する、IWindowProxy実装を提供します。
現在、仕様が、評価され、適切なインターフェイスが、企画されています。AngleSharpは、基本的に、使用する設定を保持するだけの、とても単純なデフォルトの実装を提供します。
状態：最小限の実装が、提供されています。まだ、テストは存在しません。
詳細については、以下で見つけることができます。：
CSS APIを作り直す
Reshape CSS API
HTML APIは、完全に修正されました。これらの原則のいくつかは、CSSにも適用されています。公式の仕様では何も利用できないので、公式のものと競合しないAPIを提供することは、困難です。それにもかかわらず、AngleSharpを効果的に作成するために、そして、オブジェクト指向のAPIが、必要なCSSでの作業に便利です。
文字列だけを使用することは、JavaScriptで、役立ちますが、C＃（またはF＃、VB、...）のような言語ではありません。私たちは、規則を確認するために、コンパイラが必要です。どんなメソッドとプロパティが利用可能か、IDEに伝えることによって、エラーを検出し、私たちを助けて下さい。その結果、標準ではないオブジェクト指向のAPIが、使用されているCSSOM上に、直接、配置される実装がされました。
状態：テストは、実装され、利用可能です。
詳細については、以下で見つけることができます。：
WebIDL属性
WebIDL attributes
インターフェース定義言語（IDL）は、JavaScriptのような、言語からアクセス可能なインターフェイスを記述するために、使用されます。AngleSharpは、名前の付いたインターフェイスとアルゴリズムを実装しています。しかしながら、命名は、変更されています（時には、時にはそれほど悪くない場合もあります）。例えば、JavaScriptエンジン、そして、ドキュメント・ジェネレーターのためのラッバーの生成を自動化するために、AngleSharpは、DomNameAttributeと呼ばれるカスタム属性を提供します。この属性は、メソッド、プロパティ、型などを装飾します。最後に、1つは、対応する型のインスタンスを問い合わせることによって、OfficialNameを取得することができます。
メンバーのより洗練されたプロパティを明らかにする、そのような属性が、更にあります。例が、あります。メソッドが、実際に、インデックス・ゲッターやセッター（または、その両方）のように、扱われるべきである場合、おそらく、プロパティの設定は、プロパティのプロパティにリダイレクトされる必要があります。公式のIDL言語で、記述されている、多くの指定された動作が、あります。 これらのいくつかは、リフレクションを使用して、導き出すのが簡単です。いくつかは、カスタム属性のヘルプを必要とするかもしれません。
この作業パッケージは、重要なIDL構文を見つけることを扱います。続いて、それらを扱う適切な方法（例えば、カスタム属性による修飾）が見つかる必要があります。最後に、既存のインタフェースを調査/拡張する必要があります。２つ目の手順で、何が決定されたかに依存します。
状態：最も重要なものが実装され、要求/要求に応じてさらに多くのものが提供されます。
詳細については、以下で見つけることができます。：
IDocumentインタフェースを完成させる
Complete the IDocument interface
文書の中心的なノードは、確実にIDocumentなオブジェクトそのものです。それは、（直接、または、間接的に）すべての添付されたノードの所有者です。そして、それは、添付されたIConfigurationインスタンスを持っている、IWindowオブジェクトと（内部でのみアクセス可能な）IBrowsingContextへの接続を持っています。
現在、IDocumentインタフェースは、ほぼ完全です。そして、さらにいくつかの最初は、風変わりに感じるプロパティ/メソッドが、含まれています。これらのメンバーのうちのいくつかは（少なくとも現時点では）あまり貢献していませんが、他は、特にスクリプトと連携して、確実に更に面白いです。 1つの例は、現在実行されたIHtmlScriptElementを示すcurrentScriptプロパティです。
また、コマンドAPIが実装され、利用可能な拡張によって接続することができます。すべてにおいて、IDocumentインタフェースとその実装（文書）は、完全に完成していると言うことができます。
状態：いくつかのテストは、実装され、利用可能です。
詳細については、以下で見つけることができます。：
非同期解析の改善
Improve async parsing
非同期の構文解析は、極めて重要です。標準（さらに大型）の処理は、数ミリ秒だけしかかかりませんが、AngleSharpは、（ネットワーク）ストリームにあるソースにも使用されます。可能性がある2つの戦略があります。：１つは、事前に全てをダウンロードしておくことです。（非同期で、バイトの配列です）、２つ目は、文書を処理している間、連続的に、データをダウンロードします。後者には、たとえ、文書が長い、そして、転送が、ある時点で中断される可能性がある場合でも、文書の少なくとも一部は、すでに利用できる利点があります。
２つ目の方法の他の利点は、1つ目が、まだ、進捗している間に、他のダウンロードを開始できることです。それで、他をダウンロードする代わりに、私たちは、利用可能な帯域幅をより適切に使用し、一度に、複数をダウンロードできます。
AngleSharpは、その結果、２つ目の方法を実装しようとします。TextSourceクラスは、既に、適切にストリームを（ネットワーク）処理することができます。－そして、提供される "ネイティブ"非同期コールバックの可能性を提供します。それにもかかわらず、ParseAsyncメソッドは、同期されたもののためにのみ依存しますが、他のTaskで、それをラップします。（まさに、このシナリオの他のスレッドです）。
この概念は、実際の非同期メソッドを提供することです。すなわち、TextSourceで提供される非同期メソッドを利用するメソッドです。これは、最終的に、ほんの少しの変更だけで、多くのコピー/ペーストを結果として生じますが、それは、複製の価値があります。もちろん、メンテナンスを最小限に抑えるために、重複を減らすためのいくつかの手法を使用する必要があります。
ここでは重要なヒントとして： awaitコールは、ConfigureAwait(false)でのみ使用する必要があります。これは、メソッドを同期的に呼び出すことによって、環境に関係なくデッドロックが発生しないようにするために必要です。
状態：実装され、そして、また、パーサが、内部的に、スクリプトの実行やスタイルシートの解像度のような、更なるタスクを待っています。
画素
The picture element
画素は、レスポンシブ画像とそれらの問題への解決法です。画像は、画素密度と表示装置のために、調整する必要があります。問題は、既存のHtmlImageElementが、一つのソースだけを処理することができることです。現在、それは、（まだ実装されていない）srcsetとsizes属性のために変更されました。最初の1つは、それらの潜在的なメディア・クエリと一緒に、さまざまなソースを提供します。 後者は、画素密度やビューポートの幅に依存する画像サイズの設定に役に立ちます。
しかしながら、私たちが、新しいimg属性によって提供されるより、更にきめ細かい解決法を求める場合、続いて、私たちは、画素を見る必要があります。要素は、HtmlPictureElementクラスで実装されましたが、まだ、何も含まれていません。問題なく機能するソリューションは、ポリフィルを要素に移植することです。その解決策は、素晴らしいスタートになるでしょう。そして、続いて、必要に応じて、調整することができます。
状態：利用可能な要素、srcset属性とソースの子供たちが、考慮されます。現在、デバイスの検証はできません。（v1.0のためのCSS改善の一部）。それゆえに、擬似静的。
詳細については、以下で見つけることができます。：
リソースを読み込む
Loading resources
目に見えるよりも多くのリソースが読み込まれます。現在、AngleSharpは、外部データを取得する、とても基本的なアルゴリズムを実装しています。これは、将来変更されます。
この変更は、IBrowsingContextのより多くの拡張（おそらくは制約）と釣り合っています。ブラウジング・コンテキストは、また、セキュリティ視点からも重要です。ここでは、基本的なフラグは、持っているかもしれない基礎となるAPIを、正しく決定するために設定します。他の直接の影響は、文書の正しいアンロードを行うことです。これは、まだ実装されていません。
状態：利用可能な単純な実装は、より洗練されたものが必要です。サンドボックス解析は、既に実装されています。
詳細については、以下で見つけることができます。：
タッチ・イベントを含める
Include Touch events
いくつかのイベントが、DOMの中にあります。それにもかかわらず、これらのイベントのいくつかは、単純な通知だけです。他は、カスタム・データを運搬する場合があります。このグループでは、私たちは、キーボードやMouseイベントのような、古くからあるものを見つけます。また、W3Cは、特別なタッチ・イベントを作成しました。それは、タッチ点のリスト形式で、タッチ・データをもたらします。
このタスクの目的は、すべての必要とされるインターフェイスを提供することです。タッチイベントの作成と処理を可能にするために、点を実装、そして、拡張します。これは、IDocument、IElement、そして、他の既存のインターフェイスを拡張します。また、これは、ITouchEventやITouchListのような、新しいインターフェイスを作成します。
注意が必要なアルゴリズム、タッチの実装やOS固有の結合を作成する必要はありません。これは、PODオブジェクトの作成を可能にするレイヤーです。
状態：すべて利用できます。
詳細については、以下で見つけることができます。：
