早在 11 月，我们就宣布了 众多 API 重构中的第一个。在那篇文章中，我们简要说明了我们的总体目标

jQuery UI 正在进行 API 重构，这将缩减 API 的大小，以便提供更稳定、更易于学习和使用的代码库。我们将在接下来的几周内发布提议的更改，以便收集社区的反馈。我们的目标是在 1.9 中同时支持旧（当前）和新（提议）API，然后在 2.0 中删除对旧 API 的支持。

现在已经过去了三个月，有两件事是明确的：1）发布所有提议的更改需要不止几周的时间；2）我们没有提供足够的关于计划的更改及其背后原因的信息。

过去

jQuery UI 最初创建时，它是新插件和现有插件的组合。引入现有的流行插件对所有相关人员都有利：jQuery UI 发布得更早，而且拥有更多插件，原始作者的辛勤工作得到了 jQuery 项目的公开认可和支持，而现有的用户群获得了对其正在使用的代码的官方支持。不幸的是，这种方法也有缺点。由于现有的插件是由不同的作者使用不同的设计原则和不同的编码风格编写的，因此 jQuery UI 内部没有太多一致性。在 1.0 到 1.8 版本之间，曾尝试对 API 的各个部分进行标准化，但从未有过足以进行必要更改的协调工作。

除了插件之间存在的不一致性之外，在过去三年半的时间里，其他问题也开始出现。随着用户请求越来越多的功能，选项、方法和事件的数量不断增加。随着时间的推移，这导致了我们今天所看到的情况，即像可拖动元素这样简单的东西几乎有 30 个选项。一方面，能够处理如此多的不同用例，通常只需要使用其中一两个选项，这令人印象深刻。另一方面，对于新手用户来说，寻找合适的一两个选项可能是项艰巨的任务。

现在

认识到现有问题，我们以不同的方式处理了 1.8 版本。我们定义了一个新的插件构建流程，该流程侧重于简化 API，使之易于扩展。随着 1.8 版本的成功，尤其是自动完成小部件的简单性和灵活性，我们确信我们的新流程正在发挥作用。拥有新的流程和新标准后，我们决定回过头来，使用相同的设计流程重新设计所有现有的插件。10 月，jQuery UI 团队在波士顿聚会，对所有现有插件进行了初步重新设计。几周后，我们开始发布提议的更改，以收集社区的反馈。我们仍在处理某些特定插件的详细信息。

我们的目标是通过 2.0 版本发布一个完全更新的项目。我们将拥有更简单的 API、更好的稳定性、完整的文档和所有插件的完整测试套件。但是，实现这一目标需要进行大量的向后不兼容的更改。我们意识到这可能是多么痛苦，并且我们正在尽一切努力减少升级的痛苦。具体来说，我们在实施新的 API 时正在执行以下操作

• 确保我们拥有 2.0 API 的完整测试套件
• 为 1.8 API 创建单独的测试套件
• 在新的功能之上重新实现任何已弃用的功能
• 在旧 API 和新 API 不能并存的情况下，默认为 1.8 API

这种方法有几个优点，其中最重要的一个优点是，升级到 1.9 不会破坏任何现有页面。事实上，1.9 版本将比任何 1.8.x 版本都更好地支持 1.8 API。随着插件为 1.9 重新构建，1.8.x 中存在的许多错误将得到修复，并且某些修复将无法轻松移植到 1.8 分支。由于 1.9 版本中对 1.8 API 的支持实际上是建立在 2.0 API 之上的新代码，因此它受益于这些错误修复。为 1.8 API 添加完整的测试套件可确保这些错误实际上在两个 API 中都得到修复。

将 1.8 API 的支持默认设置为 100% 对升级到 1.9 非常有用，但它没有提供一种方法来确定你是否已准备好升级到仅使用 2.0 API。为了解决这个问题，我们添加了一个新的标志，jQuery.uiBackCompat。如果你加载 jQuery，然后设置 jQuery.uiBackCompat = false，然后加载 jQuery UI，则不会加载任何 1.8 API。这将导致只有 2.0 API 可用，并允许你测试你的页面与新 API 的兼容性，并确保你准备好升级到 2.0（在它发布后）。

未来

当 jQuery UI 2.0 发布时，我们将不再支持 1.8 API。但是，1.9 中的 1.8 API 兼容层应该继续工作；它只是不会包含在 2.0 版本中，并且不再被官方支持。所有新插件都将通过新的设计流程，因此像这样的大规模 API 更改不应该再次发生。一旦现有的插件更新到我们的新标准，我们应该能够比以前更快地推进项目。

值得一提的是，只有小部件、实用程序和效果在 1.9 中被重构。所有交互都将在 2.0 中被重写，因此它们将经历不同的实现过程。作为 jQuery UI 的用户，除了发布日期之外，你应该不会在小部件重构和交互重写之间感受到很大的区别。

我们知道没有人希望重构现有代码以与 API 更改一起工作，我们正在努力确保过渡过程清晰明了。我们希望你（我们的用户）理解，我们需要抓住这个机会来改进 jQuery UI，使其在长期内更加健壮、可扩展和可维护。

继续进行API 重设计，我们对选项卡小部件有一些计划的更改。我们知道，像这样的 API 更改并非没有代价，因此我们想明确表示，除特别说明外，1.9 中的 jQuery UI 选项卡也将支持 1.8 API，并且弃用的 API 不会在 jQuery UI 2.0 之前删除。

API 重设计

删除旋转。
rotate 方法将被删除，因为它并不常见，并且一直作为内置扩展来实现。这实际上将被删除，而不是仅仅在 1.9 中被弃用，因为它一直作为扩展存在。Christopher McCulloh 拥有一个增强的旋转扩展，它基于原始代码。

彻底改造 ajax 选项卡
ajaxOptions 和 cache 选项将被删除，取而代之的是一个新的事件：beforeload。beforeload 事件将接收一个 jqXHR 对象和将传递给 jQuery.ajax() 的设置对象。ajaxOptions 通过修改传递给 beforeload 的设置来替换，缓存可以通过调用 event.preventDefault() 来实现，以防止 ajax 调用并直接跳到显示选项卡。我们还将保留 href 属性不变，并将面板 ID 存储在 aria-controls 属性中。aria-controls 属性将为所有选项卡设置，无论它们是本地还是远程。这将消除对 url 方法的需求，该方法也被删除。可以在 aria-controls 值中为远程选项卡预定义一个值，从而无需在 title 属性（也被删除）中指定位置。abort 方法将被删除，因为 jqXHR 对象将可以直接访问，因此你可以直接中止 ajax 调用。beforeload 事件的另一个好处是，当它与现有的 load 事件配对时，你可以创建自定义加载功能；因此，我们删除了 spinner 选项。

选中与激活
为了提高 jQuery UI 套件内部的一致性，选择/选中将被全面重命名为激活/激活。这对选项卡意味着，selected 选项将被重命名为 active，select 事件将被重命名为 beforeactivate，show 事件将被重命名为 activate。beforeactivate 和 activate 选项将包含对旧选项卡和新选项卡的选项卡和内容面板的引用，类似于手风琴。此外，select 方法将被删除，取而代之的是设置 active 选项。最后，deselectable 选项将在 1.9 中删除，因为它在 1.8 中已弃用。

删除模板化
与模板化相关的所有选项都将被删除。选项卡中的模板化是一个一次性实现，它与其他 jQuery UI 的实现不一致。此更改包括删除 idPrefix、tabTemplate 和 panelTemplate 选项。

添加和删除选项卡
add 和 remove 方法将被删除，取而代之的是一个新的 refresh 方法。这与在初始化后更新新插件的方式一致。删除这些方法也意味着 add 和 remove 事件将被删除。

启用和禁用选项卡
选项卡将正确支持禁用单个选项卡或整个选项卡集。可以使用布尔值来禁用整个选项卡集，或者提供一组索引来禁用单个选项卡。此外，enable 和 disable 事件将被删除，以保持与其他小部件的一致性。

删除长度方法
length 方法将被删除，因为它没有太大用途，并且可以很容易地通过计算列表项的数量来计算。

删除 cookie 选项
cookie 选项将被删除，因为 cookie 支持不是插件的核心功能。跨页面状态管理应该很容易，但不要内置。

设计更改仍在不断变化中
我们还没有完全解决的几件事。我们计划用 show 和 hide 选项替换 fx 选项，以保持与其他小部件的一致性，但我们仍在处理一个开放问题，即如何在插件之间支持效果。我们还想删除 load 方法，但我们需要验证它是否可以作为扩展构建。在我们进入新的实现之前，我们不会知道这是否可能；如果不行，load 方法将保留在插件中。

反馈

我们很乐意听取你对这些更改的反馈。我们希望确保我们在最终确定并实施这些更改之前，解决社区可能遇到的任何问题。如果你有任何反馈，请在相关的论坛帖子上发布。谢谢。