抠丁客 抠丁客
项目
编辑 (2024/6/29)

AngleSharp 包含功能

本节列出了从即将发布功能列表中移至已实现功能的部分。这并不包括所有可用的功能，尽管这可能是此页面最终目标。将实现的功能移到这里的目的是为了跟踪引用。这样可以更容易追踪 W3C 规范更改或测试缺失。

变更记录

已经实现了如 MutationObserver 、 MutationObserverInit 和 IMutationRecord 这样的类型。

这些类型可以作为通用通知监听器，当 DOM 中的某些内容发生变化时触发。它们也会被节点内部使用，因为节点可能需要知道其内容何时改变。例如：HtmlStyleElement 需要知道其内容何时改变，因为新内容需要解析和评估。

状态：已实现，有可用测试。

更多信息可在：

提供各种 URI 实现

AngleSharp 中包含了一个 URI 解析器。这个解析器几乎完成，但不处理主机部分的 Unicode 规范化。这通常由 .NET 框架提供，但在我们的 PCL 目标中并未提供。

状态：已实现，有可用测试。

更多信息可在：

伪元素集成

CSS 提供了 HTML 标准描述的一些 DOM 扩展，其中之一是伪元素的集成。这些元素实际上在 DOM 中并不存在，但可以查询，并且也是视觉树的一部分。

伪元素不是真正的元素，它只实现了特殊的 IDL，称为 IPseudoElement 在 AngleSharp 中。最重要的是，这个接口隐含了实现 IGetStyleUtils 接口。因此，即使伪元素不是真正的元素，它也具有参与绘图过程所需的关键属性。

状态：仅提供最小实现。尚未有测试。

更多信息可在：

扩展 IWindow 接口

对于任何与 DOM（至少从开发人员的角度）的交互来说，中央上下文对象通常是 Window 对象。AngleSharp 使用 IWindow 接口作为此类对象的 IDL。尽管 v0.7 中可用 AnalysisWindow 类，但 AngleSharp 仅提供了 Window 类的实现。它更为通用，可能与 RenderDevice 信息一起工作。

Window 实现还包括定时器等功能，非常有用。它是至关重要的，并且在浏览上下文中被广泛使用。然而，仍然可以提供自定义实现。

状态：仅提供最小实现。尚未有测试。

更多信息可在：

事件处理

已添加或删除事件监听器的能力以及 dispatch 函数已被包含。已完成的是将所有.NET 事件处理器转换为显式形式。

考虑以下示例：

public event EventListener Aborted;

这是一个隐式事件处理器。C# 编译器将生成一个备份委托字段，初始值为 null 。当应用 += 或 -= 运算符到 Aborted 字段时，会使用 add 和 remove 部分。

转换后的代码如下：

public event EventListener Aborted
{
    add { AddEventListener(EventNames.Abort, value); }
    remove { RemoveEventListener(EventNames.Abort, value); }
}

这里不再生成备份字段。我们明确定义 add 和 remove方法，它们将调用 AddEventListener 和 RemoveEventListener 方法。事件名称可以从 MDN 事件参考找到，通常没有前缀 on ，如 abort 。

这将添加到 EventNames 类中的一个只读静态字段：

public static readonly String Abort = "abort";

状态：已实现，有可用测试。

更多信息可在：

重构核心 DOM 算法

已使用 MDN 和 W3C 文档实现了核心 DOM 算法。然而，很明显，这些内部工作方式在边缘情况下并未按预期工作。因此，将考虑 WHATWG 文档，因为它提供了更详细的信息和更多的相关资料。

作为副作用，API 也将部分适应。最终，这不仅对标准合规性有利，对用户也是如此。边缘情况不仅要在 HTML5 解析器中工作，还要在 DOM 交互期间工作。

状态：已实现，部分测试可用。

更多信息可在：

浏览上下文

目前，AngleSharp 专注于出色地解析 HTML（和 CSS），但以后可能会在此库之上构建更多内容。因此，为了完全符合 W3C 规范，需要能够注册/创建/打开真正的浏览上下文。

浏览上下文连接各个部分。它包含一个文档列表，并知道当前查看的是哪个文档。它提供了 IWindowProxy 实现，将所有调用转发到当前活动文档的 IWindow 对象。

目前，正在评估规范，并计划适当的接口。AngleSharp 提供了一个简单的默认实现，基本上只保存要使用的配置。

状态：仅提供最小实现。尚未有测试。

更多信息可在：

重塑 CSS API

HTML API 已经被完全重构。这些原则也部分应用于 CSS。由于官方规范中没有相关内容，很难提供不会与官方 API 冲突的 API。然而，为了让 AngleSharp 在 CSS 工作时有效且有用，需要一个面向对象的 API。

在 JavaScript 中，使用字符串很有用，但在 C#（或 F#、VB 等）这样的语言中则不然。我们需要编译器检查规则，检测错误，并通过告诉 IDE 哪些方法和属性可用来帮助我们。因此，已经实现了一个非标准的面向对象 API，直接位于正在使用的 CSSOM 之上。

状态：已实现，有可用测试。

更多信息可在：

WebIDL 属性

接口定义语言（IDL）用于描述可以从 JavaScript 等语言访问的接口。AngleSharp 实现了命名接口和算法。然而，名称有时更多，有时更少地发生了变化。为了自动化为 JavaScript 引擎生成包装器和文档生成器，AngleSharp 提供了一个名为 DomNameAttribute 的自定义属性。该属性装饰方法、属性、类型等。最终，可以通过查询相应的 Type 实例获取 OfficialName 。

还有更多这样的属性，揭示了成员的更复杂特性。例如，方法是否应实际被视为索引获取器或设置器（或两者都包括）。也许设置属性应该重定向到属性的属性。有许多在正式的 IDL 语言中指定的操作，其中一些可以通过反射轻松推断出来，而其他可能需要自定义属性的帮助。

此工作包涉及查找重要的 IDL 结构。然后需要找到处理它们的适当方式（例如，使用自定义属性进行装饰）。最后，根据第二步的决定调查或扩展现有接口。

状态：大多数重要功能已实现，更多请求/需求时会继续添加。

更多信息可在：

完善 IDocument 接口

文档的中心节点无疑是 IDocument 对象本身。它是所有附加节点（直接或间接）的所有者，并且它连接到 IWindow 对象和 IBrowsingContext （仅在内部可访问）， IBrowsingContext 附带了 IConfiguration 实例

当前，IDocument 接口几乎已经完成，甚至包括一些一开始看起来很奇特的属性和方法。虽然其中一些成员可能贡献不大（至少目前），但其他一些肯定更有趣，尤其是在脚本配合下。例如，currentScript 属性表示当前正在执行的 IHtmlScriptElement。

此外，命令 API 已经实现，并可通过可用扩展连接。总的来说，IDocument 接口及其实现（Document）可以说已经完全完成。

状态：已实现，部分测试可用。更多信息见：

异步解析改进

异步解析非常重要。尽管标准处理（即使大型）可能只需要几毫秒，但 AngleSharp 也将用于网络流等来源。有两种策略：第一种是在下载之前（异步）获取所有数据（以字节数组的形式），而第二种是在处理文档的同时持续下载数据。后者的优势在于，即使文档很长且传输在某个点上被中断，至少部分文档已经可用。

第二种方法的另一个优势是可以开始其他下载，同时原始下载还在进行。因此，我们不是一次下载一个，而是同时下载多个，更好地利用带宽。

因此，AngleSharp 将尝试实现第二种方法。TextSource 类已经很好地处理了（网络）流——并确实使用了“原生”提供的异步回调功能。然而，ParseAsync 方法仅依赖同步方法，将其包装在另一个 Task（在这种情况下，这只是另一个线程）中。

想法是提供一个真正的异步方法，即使用 TextSource 提供的异步方法。这最终会导致大量复制/粘贴，但值得重复。当然，需要使用一些减少重复的技术来最小化维护工作。

重要提示：任何 await 调用都应只使用 ConfigureAwait(false)。这是确保无论环境如何，同步调用都不会导致死锁所必需的。

状态：已实现，解析器内部也等待进一步任务，如脚本执行或样式表解析。

图片元素

图片元素是响应式图像及其问题的解决方案。图像需要根据像素密度和视图设备进行调整。问题是，现有的 HtmlImageElement 只能处理单个源。现在由于（尚未实现的）srcset 和 sizes 属性，这种情况已经改变。前者提供了多个源及其潜在媒体查询。后者可用于根据视口的像素密度或宽度设置图像大小。

然而，如果我们想要比新 img 属性提供的更精细的解决方案，我们应该查看 picture 元素。该元素已在 HtmlPictureElement 类中实现，但目前还没有包含任何内容。一种可能的解决方案是将 polyfill 移植到元素上。这个解决方案是一个很好的起点，然后可以根据需要进行调整。

状态：元素可用，考虑了 srcset 属性和 source 子元素。目前无法进行设备验证（属于 v1.0 中 CSS 改进的一部分）。因此暂时静态。

更多信息见：

加载资源

加载资源比表面看起来要复杂得多。目前，AngleSharp 实现了非常基础的获取外部数据算法。将来会有所改变。

这种变化将与 IBrowsingContext 的更多扩展（可能还有约束）保持一致。浏览上下文在安全方面也很关键。这里的基本标志被设置来确定底层 API 可能拥有的权限。另一个直接影响是正确卸载文档。这尚未实现。

状态：有简单实现，需要更复杂的实现。沙箱解析已经实现。

更多信息见：

触摸事件支持

DOM 中有许多事件。尽管有些只是简单的通知，但有些可能会携带自定义数据。在这个组中，我们找到了像键盘或鼠标事件这样的经典事件。W3C 还创建了特殊触摸事件，这些事件以触摸点列表的形式携带触摸数据。

该任务的目标是提供所有所需的接口、实现和扩展点，以便创建和处理触摸事件。这将扩展 IDocument、IElement 和其他现有接口。还将创建新的接口，如 ITouchEvent 或 ITouchList。

没有复杂的算法、触摸实现或操作系统特定绑定需要创建。这只是允许创建 POD 对象的层。

状态：所有功能可用。更多信息见：

XPath 解析的可能性

从官方角度看，CSS 选择器是查询文档的方式。然而，有些人对这种解决方案相当不满。这些人大多不是 Web 开发者，他们熟悉更强大的 XPath 查询。不幸的是，XPath 目前不支持标准级别。

状态：已在 AngleSharp.XPath 库中可用。更多信息见：

在本文档中