Home > C# > 目的別資料 > Web関連 > AngleSharp

AngleSharpドキュメントのTODOの日本語訳

新規作成日 2018-07-09
最終更新日

AngleSharpドキュメントの日本語訳. C#で利用できるhtmlパーサーのAngleSharpプロジェクトのドキュメントの翻訳です。

原文「TODO

このページ(原文ページ)は、Florian Rapplによって編集されました。 2015年8月27日・16改訂

今後の機能

Upcoming features

GitHubプロジェクトの管理機能は、明らかに見事です。しかし、それらは、議論のための十分なスペースと今後の機能の詳細なプレゼンテーションを提供していません。このリストは、どんな形であれ順序づけされません(重要性、タイムツーリリース、...)そして、概念と覚え書きの集まりとと同じようにだけ、考えて置く必要があります。

CSSOMビュー・モジュール

CSSOM view module

レンダリングは、AngleSharpで最も面白い面の1つかもしれません。AngleSharpは、直接レンダリングを取り扱いません。その代わりに、カスタム・レンダリング・エンジンをフックすることは簡単です。おそらく、JavaScriptエンジンを組み込むための例として役立つ、AngleSharp.Scripting oneでのような、(サンプル)ライブラリが提供されるでしょう。レンダリングの必須のものの1つには、多くのメソッド、インターフェイスなどを指定するCSSOM Viewのモジュールが含まれています。 スクリーンのような、実際のデバイスに接続するとき、これは重要です。また、分析のために使用される場合がある偽のディバイスは、CSSOM Viewモジュールから、利益を得ます(Windowを参照)。

コアAngleSharpライブラリによって、すべてのインタフェースとメソッドを実装/提供する必要はありません。その代わりに、この作業パッケージの主な仕事の1つは、柔軟性と情報の両方を提供する優れた階層を決定することです。それは、多くの目的に、使用することができます。

状態:部分的に含まれています。これらのほとんどは、一旦、(外部ライブラリ)1からレンダリングされ、決定されます。

詳細については、以下で見つけることができます。:

レンダリング

Rendering

OK、それは、ここにあります。これは、レンダリングされるでしょう。しかしながら、AngleSharpの中で、直接ではなく、しかしながら、コアの観点から(まだ)必要とされていることを確認するために、リファレンス実装が、提供される必要があります。この実装は、CSS 2.1仕様で説明されている公式の標準、そして、後で到着したモジュールに従うべきです。

状態:スケッチした、輪郭を描いた、しかしこれまで何も起こっていません。

詳細については、以下で見つけることができます。:

UIの処理を定義する

Define UI handling

このセクションのほとんどは、IWindowの拡張です。私たちは、いくつかの点を必要とします。:

  • UIの固有の木の走査、スタイルの履歴を維持する
  • イベント・ループ(今すぐ、Documentに配置)
  • ...

サンプル・レンダラーの実装が完了し、リリースされると、これらのほとんどが、より明白になります。これは、v0.7の後、発生し、おそらく、10月に、あるいは、11月が、可能性が高いでしょう。

コア・ソースは、ブラウジング・コンテキストである必要があります。これは、しかしながら、それ自身のポイントです。ブラウジング・コンテキストは、IWindowインスタンスよりもすぐれています。 IDocumentインスタンスに密接に結合しています。また、ブラウジング・コンテキストは、現在、IWindowレベルで利用できるデバイス情報をもたらします。

状態:完全に欠落。

更なる拡張ポイントを提供する

Provide further extension points

例えば、自動ファイルシステム・バッファは、(言うまでもなく)ファイルシステムにアクセスが必要です。さらに、ストレージは、ファイル・システムへのアクセスを、おそらく、別のフォ-ムで、必要とする場合があります。

また、画像の表示と同様に、ビデオ、オーディオやイメージのような、メディア入力は、ビデオとオーディオ・ストリーミング/再生へのアクセスを必要とします。

その可能性は、高いです。v0.7は、既に、(未処理バイトから)画像や音声情報の収集など、いくつかのメディア拡張機能を導入しています。あるいは、オフラインAPIのストレージを呼び出します。 また、これは、拡張設定パイプラインを導入します。

拡張設定パイプラインは、DOM対話処理の間、中心になります。パーサーは、ソース解析中のコアですが、設定パイプラインには、すべての関連したデータが含まれています。

例えば、以下は、既に利用可能です。:

  • スタイル・パーサ
  • スクリプト・エンジン
  • HTTPリクエスタ

とりわけ、欠けているものは、以下の通りです。

  • メディア型のMime
  • リソース・データベース
  • ローカル記憶装置

最終的な目標は、続いて、完全にカスタマイズ、拡張、使用することができる、多数の拡張ポイントを持つことです。AngleSharpのこの方法は、極めて強力な状態(パーサ、DOM)を保ち、(ローカルを超えて)成長する機能を提供します。ヘッドレス・ブラウザは、完全にカスタマイズ可能で拡張できます。

状態:開始されています。

(単純な?)XPathな構文解析の可能性

Possibility of (simple?) XPath parsing

現在、CSSセレクタは、文書を問い合わせる方法です。それにもかかわらず、この解決法には、非常に不満を持っている人々がいます。それらの人々のほとんどは、Web開発者では、ありません。そして、XPathの形で、さらに強力なクエリに精通しています。残念ながら、XPathは、現在、標準レベルではサポートされていません。

限定された時間で効果的に実装できる、続いて、それは、含まれている必要がある場合、XPathクエリ・エンジンをコード化するために、どれくらい手間がかかるか、評価する必要があります(十分に、単純ですが、それは、標準に適合している必要があります)。それ以外の場合には、他/任意のクエリ・エンジンが、含まれている可能性を、評価する必要があります。一般に、これは、とても面白いパスかもしれません。

状態:完全に欠落。

詳細については、以下で見つけることができます。:

MathML

MathML

MathMLは、マークアップ言語です。それは、LaTeXのような方程式を書くことができるはずです。 その結果、MathMLは、演算子、識別子、記号、スペース、未処理テキストなどのような、セマンティックな意味を伝える特別なタグを持っています。HTML5は、仕様で、MathMLの埋込ができます。

現在、AngleSharpは、MathMLをHTMLの外部要素として扱うことができます。これは、それが、あるべき姿です。数学文書や類似の構文をサポートする計画はありません。しかしながら、現在、AngleSharpは、ほんの少しのMathML要素だけに制限されています。他の全ての要素は、カスタムNodeNameで、一般的なMathElement要素と同じようにみなされます。

MathML (sub) DOMに関する情報を追加する理由はいくつかあります。その結果、AngleSharpに、他のすべての特別に定義された要素を含めることが重要です。結局は、これらの他の要素もサポートするためには、MathFactoryを拡張する必要があります。それは、MathMLをサポートするのに十分である必要があります。

それは、調査する必要があります。特別なエンティティのような他のプロパティの場合、同様に、含まれられている必要があります。もし、そうである場合、問題は以下の通りです。:エンティティ検索モードを変更するには、どうすればいいですか?いくつかのオプションが、ありますが、ソリューションは、堅牢で、拡張が容易で、性能が優れている必要があります。

状態:基本は、v1.0に戻って含まれています。

詳細については、以下で見つけることができます。:

SVG

SVGは、XMLに基づいた、ベクトル・ファイル形式です。HTML5では、仕様に基づいて、ドキュメントにSVGイメージを埋め込むことができます。いくつかの旧式のブラウザでは、(外部的に)参照するために、SVG画像を必要する可能性があります。AngleSharpは、HTML5をサポートしています。そして、その結果、SVGを、ドキュメントに、直接、含めることができます。

それにもかかわらず、「数学文書」のための計画はありません。AngleSharpは、(XMLDocument実装で)IXmlDocumentインターフェイスを使用するフォ-ムで、「SVG文書」を持つことを考える必要があります。その方法で、同様に、外部SVG画像を解析することができます。文書が、HTMLパーサだけを使用するような場合、あるいは、XMLパーサが、このために、復活する場合、もし、それが、おそらく、ダウングレードする場合、DTDなどのサポートを中止するかは、まだ不明です。その方法で、XMLパーサーは、検証されません。これは、おそらく最適の解決法です。

取り扱われる必要がある特別な要素や属性が、たくさんあります。結局は、しかしながら、この努力は、HTML DOMを実装するよりもはるかに少なくなるでしょう。

状態:基本は、v1.0に戻って含まれています。

詳細については、以下で見つけることができます。:

AngleSharpを減量する

Slimming AngleSharp

AngleSharpは、本当に巨大ではありませんが、それは、プロジェクトが、そのコアを決してドロップしないのに対して、連続的に成長しています。

  • HTMLパーサ、
  • CSSパーサ、
  • (Core)IDLインターフェイス、
  • (Core)DOM実装、
  • 設定と拡張機能、

含まれた機能のいくつかは、他の(拡張機能)プロジェクトに移動する必要があります。v0.8の完成を皮切りに、どの部分がコア/重要であり、どの部分が拡張であるかの決定するための主要な評価が開始されます。この評価の主要な目的は、以下の通りです:

  • 小さな仕事のためにAngleSharpを小さく保つ
  • フットプリントを削減する
  • AngleSharpをさらに拡張する
  • 必要な場合にのみ拡張機能を提供する

それで、AngleSharpが、HTMLの数行、あるいは、一つのHTML文書を解析するだけの場合、この作業は、コアライブラリでのみ可能です。Webページのスクリーンショットを作成する場合、完全なブラウジング・コンテキストをエミュレートします。あるいは、JavaScriptをAngleSharp(文書の上だけでなく)に完全に統合する。続いて、拡張機能は、ここで役立ちます。

結局は、概念は、ユーザーに必要なものだけを提供することであり、それ以上のものを提供することはありません。彼らが、もっと望む場合、コア・ライブラリのための拡張機能として動作する、より高度なNuGetパッケージを入手して、オプトインすることができます。

状態:継続的な調査。v1.0に移行しました。

このエントリーをはてなブックマークに追加

Home PC C# Illustration

Copyright (C) 2011 Horio Kazuhiko(kukekko) All Rights Reserved.
kukekko@gmail.com
ご連絡の際は、お問い合わせページのURLの明記をお願いします。
「掲載内容は私自身の見解であり、所属する組織を代表するものではありません。」