From 0b68c59ba3b583de194ad8c545b95de7431e9c72 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Fran=C3=A7ois=20Daoust?= Date: Fri, 5 Jun 2020 12:56:28 +0200 Subject: [PATCH] Update migrated WICG specs, CORS and Notifications (#469) This update updates the URL of WICG specs that have recently migrated to a Working Group or whose repo name has changed: - Migrations to the Web Applications Working Group: Badging API and Web Share Target API - Repo name changes: Web Background Synchronization and Input Device Capabilities Relevant text moved to "in progress" sections for migrations. This update also makes CORS a feature of the Fetch spec and switches the Notifications API to the WHATWG version (see #467) A few new implementation statuses seem to be reported by the Edge status platform, this update also takes these new statuses into account. --- data/background-sync.json | 3 +-- data/badging.json | 8 +++++++- data/cors.json | 6 ------ data/fetch.json | 6 ++++++ data/inputdevice.json | 2 +- data/notifications.json | 3 ++- data/web-share-target.json | 9 ++++++++- games/network.html | 2 +- games/network.ja.html | 2 +- mobile/lifecycle.html | 7 ++----- mobile/lifecycle.zh.html | 7 ++----- mobile/network.html | 2 +- mobile/network.zh.html | 2 +- mobile/userinput.html | 9 ++++----- mobile/userinput.zh.html | 9 ++++----- tools/extract-impl-data.js | 4 ++++ 16 files changed, 45 insertions(+), 36 deletions(-) delete mode 100644 data/cors.json diff --git a/data/background-sync.json b/data/background-sync.json index 68ea6845..baf09bef 100644 --- a/data/background-sync.json +++ b/data/background-sync.json @@ -1,6 +1,5 @@ { - "url": "https://wicg.github.io/BackgroundSync/spec/", - "title": "Web Background Synchronization", + "url": "https://wicg.github.io/background-sync/spec/", "impl": { "caniuse": "background-sync", "chromestatus": 6170807885627392, diff --git a/data/badging.json b/data/badging.json index 396b4cda..57d1a75e 100644 --- a/data/badging.json +++ b/data/badging.json @@ -1,6 +1,12 @@ { - "url": "https://wicg.github.io/badging/", + "url": "https://w3c.github.io/badging/", "title": "Badging API", + "wgs": [ + { + "label": "Web Applications Working Group", + "url": "https://www.w3.org/2019/webapps/" + } + ], "impl": { "chromestatus": 6068482055602176 } diff --git a/data/cors.json b/data/cors.json deleted file mode 100644 index 33559dca..00000000 --- a/data/cors.json +++ /dev/null @@ -1,6 +0,0 @@ -{ - "url": "https://www.w3.org/TR/cors/", - "impl": { - "caniuse": "cors" - } -} \ No newline at end of file diff --git a/data/fetch.json b/data/fetch.json index 986b689c..0de5ed48 100644 --- a/data/fetch.json +++ b/data/fetch.json @@ -6,5 +6,11 @@ "chromestatus": 6730533392351232, "edgestatus": "Fetch API", "webkitstatus": "specification-fetch" + }, + "features": { + "cors": { + "title": "CORS protocol", + "url": "#http-cors-protocol" + } } } \ No newline at end of file diff --git a/data/inputdevice.json b/data/inputdevice.json index 0508ae62..fc68de18 100644 --- a/data/inputdevice.json +++ b/data/inputdevice.json @@ -1,5 +1,5 @@ { - "url": "https://wicg.github.io/InputDeviceCapabilities/", + "url": "https://wicg.github.io/input-device-capabilities/", "impl": { "chromestatus": 5681847971348480 } diff --git a/data/notifications.json b/data/notifications.json index 51f747ed..1868e1f9 100644 --- a/data/notifications.json +++ b/data/notifications.json @@ -1,5 +1,6 @@ { - "url": "https://www.w3.org/TR/notifications/", + "url": "https://notifications.spec.whatwg.org/", + "title": "Notifications API", "impl": { "caniuse": "notifications", "chromestatus": 5064350557536256, diff --git a/data/web-share-target.json b/data/web-share-target.json index 1c83f577..f39edb51 100644 --- a/data/web-share-target.json +++ b/data/web-share-target.json @@ -1,5 +1,12 @@ { - "url": "https://wicg.github.io/web-share-target/", + "url": "https://w3c.github.io/web-share-target/", + "title": "Web Share Target API", + "wgs": [ + { + "label": "Web Applications Working Group", + "url": "https://www.w3.org/2019/webapps/" + } + ], "impl": { "chromestatus": 5662315307335680 } diff --git a/games/network.html b/games/network.html index 911f94eb..30a1986c 100644 --- a/games/network.html +++ b/games/network.html @@ -18,7 +18,7 @@

Well-deployed technologies

-

By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects users from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing (CORS) mechanism, opening up much wider cooperation across Web applications and services. Note the W3C version of the CORS specification does not reflect current implementations and will be obsoleted. The CORS mechanism is now a core part of the on-going Fetch specification in the WHATWG.

+

By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects users from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing (CORS) mechanism, opening up much wider cooperation across Web applications and services.

diff --git a/games/network.ja.html b/games/network.ja.html index d550cbb5..44974cad 100644 --- a/games/network.ja.html +++ b/games/network.ja.html @@ -18,7 +18,7 @@

実装されている仕様

-

既定では、ブラウザはドメイン間 (正確にはオリジン、プロトコル・ドメイン・ポートの異なる組み合わせです) にわたるリクエストを一つのウェブページから行うことはできず、この規則によりユーザはあるウェブサイトから他のサイトの認証情報を悪用したりデータを盗んだりという危険から保護されます。サイトは Cross-Origin Resource Sharing (CORS) の機構を利用してこの規則の除外規定を行うことができ、より広い範囲のウェブアプリケーションやサービスに開放することができます。注: W3C 版の CORS 仕様は現在の実装を反映しておらず廃止予定です。CORS 仕様は、WHATWG の Fetch 仕様 のコアに入りました。

+

既定では、ブラウザはドメイン間 (正確にはオリジン、プロトコル・ドメイン・ポートの異なる組み合わせです) にわたるリクエストを一つのウェブページから行うことはできず、この規則によりユーザはあるウェブサイトから他のサイトの認証情報を悪用したりデータを盗んだりという危険から保護されます。サイトは Cross-Origin Resource Sharing (CORS) の機構を利用してこの規則の除外規定を行うことができ、より広い範囲のウェブアプリケーションやサービスに開放することができます。

diff --git a/mobile/lifecycle.html b/mobile/lifecycle.html index 24b8eb2f..a9d83aba 100644 --- a/mobile/lifecycle.html +++ b/mobile/lifecycle.html @@ -25,6 +25,7 @@

Well-deployed technologies

Technologies in progress

Whether packaged or not, users rely on a variety of metadata (name, icons) to identify the apps they want to use among their list of regularly used applications. The Web App Manifest specification lets developers group all these metadata into a single JSON file.

+

The Badging API defines a more subtle notification mechanism than Web Notifications, allowing Web applications that have been installed on the device (e.g. through a manifest file) to set an application-wide badge, typically shown next to the application's icon on the home screen, to notify the user when the state of the application has changed and might require their attention (e.g. a new message has arrived).

@@ -38,6 +39,7 @@

Technologies in progress

The share action is a common paradigm on mobile devices to pass content across application boundaries, for instance to post a URL or an image to one's favorite social network application. The Web Share API specification allows a Web application to share text, links and other content to an arbitrary destination of the user's choice. The API is a more focused version of the Web Intents proposal, which was abandoned end of 2012, in part because its genericity triggered user experience issues.

+

The Web Share Target API proposal allows web applications to declare, in their application manifest, that they can receive content shared from other applications. This allows Web applications, that the user chose to install, to be listed among other native applications in share menus.

@@ -50,17 +52,12 @@

Exploratory work

The Web Packaging document describes use cases for a new package format for web sites and applications and outlines such a format.

-

The Badging API defines a more subtle notification mechanism than Web Notifications, allowing Web applications that have been installed on the device (e.g. through a manifest file) to set an application-wide badge, typically shown next to the application's icon on the home screen, to notify the user when the state of the application has changed and might require their attention (e.g. a new message has arrived).

Applications running on mobile devices can go through different application states, from running to being idle, paused, stopped, discarded, or terminated. Transitions between these states are triggered by the underlying operating system, and hidden from web applications. The Page Lifecycle proposal seeks to expose application state transitions to applications so that these applications can persist/restore state, enable/disable use of network, etc.

-
-

The Web Share Target API proposal allows web applications to declare, in their application manifest, that they can receive content shared from other applications. This allows Web applications, that the user chose to install, to be listed among other native applications in share menus.

-
-

Various sites embed content from a third party origin (e.g. news content) within their own user interface, or load third party content into an iframe to provide a faster, reliable loading experience, which is particularly crucial on mobile devices. One main drawback of this approach is that the third party's origin is not preserved: only the first party's origin appears in the address bar, which makes it difficult for users to identify the provenance and trustworthiness of the content they are browsing. Another drawback is that the third party page cannot leverage client-side resources and permissions that are attached to their origin. Portals is a proposal for enabling seamless navigations between sites or pages. In particular, it enables a page to show another page as an inset and perform a seamless transition between an inset state and a navigated state, thus solving the origin issues mentioned above.

diff --git a/mobile/lifecycle.zh.html b/mobile/lifecycle.zh.html index bf5beb06..67a7693e 100644 --- a/mobile/lifecycle.zh.html +++ b/mobile/lifecycle.zh.html @@ -25,6 +25,7 @@

广泛部署的技术

开发中的技术

无论是否打包，用户都依靠各种元数据（名称、图标）在常用应用列表中来识别他们想要使用的应用。Web应用清单规范允许开发人员将所有这些元数据放在一个 JSON 文件中。

+

除了Web通知以外，标记 API定义了另一种通知机制，允许已经安装在设备上的 Web 应用（例如通过清单文件）设置一个标记，通常显示在主屏幕上应用程序的图标旁边，在应用程序的状态发生变化时通知用户可能需要注意的信息（如新消息）。

@@ -38,6 +39,7 @@

开发中的技术

分享操作是移动设备上通过跨应用边界传递内容的常见范例，例如将 URL 或图像发布到自己最喜欢的社交网络应用中。Web分享API规范允许 Web 应用将文本、链接和其他内容分享到用户选择的任意目的地。该 API 是Web Intents提案的一个更有针对性的版本，Web Intents在2012年停止开发，部分原因是它的一般性引发了用户体验问题。

+

Web分享目标API建议允许Web应用在其应用清单中声明其可接收来自其他应用的内容。这允许用户选择安装的Web应用在分享菜单中被其他本地应用列出。

@@ -50,17 +52,12 @@

探索性工作

Web 打包文档描述了用于网站和应用的新包格式的用例，并概述了这种格式。

-

除了Web通知以外，标记 API定义了另一种通知机制，允许已经安装在设备上的 Web 应用（例如通过清单文件）设置一个标记，通常显示在主屏幕上应用程序的图标旁边，在应用程序的状态发生变化时通知用户可能需要注意的信息（如新消息）。

在移动设备上运行的应用可以通过不同的状态，从运行到空闲、暂停、停止、丢弃或终止。这些状态之间的转换由底层操作系统触发，并从 Web 应用中隐藏。页面生命周期方案旨在向应用公开状态转换，以便这些应用能够保持/恢复状态、启用/禁用网络等。

-
-

Web分享目标API建议允许Web应用在其应用清单中声明其可接收来自其他应用的内容。这允许用户选择安装的Web应用在分享菜单中被其他本地应用列出。

-
-

很多网站会在其自己的用户界面内嵌入来自第三方来源的内容（例如新闻内容），或者将第三方内容加载到 iframe 中以提供更快、可靠的加载体验，这对于移动设备尤其重要。这种方法的一个主要缺点是不保留第三方的来源：只有第一方的来源出现在地址栏中，这使得用户难以识别他们正在浏览的内容的出处和可信度。另一个缺点是第三方页面无法利用附加到其源的客户端资源和权限。Portals是一个在网站或网页之间实现无缝切换的提案，它使一个页面能够嵌入另一个页面，并在嵌入状态和切换后的全屏状态之间无缝转换，从而解决上述源的问题。

diff --git a/mobile/network.html b/mobile/network.html index 9708b774..d01d2257 100644 --- a/mobile/network.html +++ b/mobile/network.html @@ -19,7 +19,7 @@

Well-deployed technologies

-

By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing (CORS) mechanism, opening up much wider cooperation across Web applications and services. Note the W3C version of the CORS specification does not reflect current implementations and will be obsoleted. The CORS mechanism is now a core part of the on-going Fetch specification in the WHATWG.

+

By default, browsers do not allow to make request across different domains (or more specifically, across different origins, a combination of the protocol, domain and port) from a single Web page; this rule protects the user from having a Web site abusing their credentials and stealing their data on another Web site. Sites can opt-out of that rule by making use of the Cross-Origin Resource Sharing (CORS) mechanism, opening up much wider cooperation across Web applications and services.

diff --git a/mobile/network.zh.html b/mobile/network.zh.html index 037ef069..789fb54d 100644 --- a/mobile/network.zh.html +++ b/mobile/network.zh.html @@ -19,7 +19,7 @@

广泛部署的技术

-

默认情况下，浏览器不允许在单个网页上的不同域名（或者更具体地说，不同源，包括协议、域名和端口的组合）之间进行请求；这个规则保护用户，使用户们不会被一个网站滥用他们的证书并窃取他们在另一个网站上的数据。站点可以通过使用跨源资源共享（Cross-Origin Resource Sharing，CORS）机制来选择退出该规则，从而在 Web 应用和服务之间开展更广泛的合作。请注意 CORS 规范的 W3C 版本并不能反映现有的实现，并将被废弃。CORS 机制现在是 WHATWG Fetch 规范的核心部分。

+

默认情况下，浏览器不允许在单个网页上的不同域名（或者更具体地说，不同源，包括协议、域名和端口的组合）之间进行请求；这个规则保护用户，使用户们不会被一个网站滥用他们的证书并窃取他们在另一个网站上的数据。站点可以通过使用跨源资源共享（Cross-Origin Resource Sharing，CORS）机制来选择退出该规则，从而在 Web 应用和服务之间开展更广泛的合作。

diff --git a/mobile/userinput.html b/mobile/userinput.html index 0a535431..af158eae 100644 --- a/mobile/userinput.html +++ b/mobile/userinput.html @@ -44,7 +44,10 @@

Technologies in progress

The CSS will-change property is also available to indicate to browsers that a given part of the page will be soon scrolled to and should be pre-rendered.

-

The Push API makes it possible for server-side notifications to alert the user, even if the browser is not running.

+
+

The Push API makes it possible for server-side notifications to alert the user, even if the browser is not running.

+

The Badging API defines a more subtle notification mechanism than Web Notifications, allowing Web applications that have been installed on the device (e.g. through a manifest file) to set an application-wide badge, typically shown next to the application's icon on the home screen, to notify the user when the state of the application has changed and might require their attention (e.g. a new message has arrived).

+

Whether users are speaking commands to their apps or working with them through non-haptic interactions, they risk seeing the screens turned off automatically by their devices screensaver. An early proposal for a Wake Lock API would let developers signal the needs to keep the screen up in these circumstances.

@@ -64,10 +67,6 @@

Exploratory work

Gamepads exist in a variety of flavours, from usual console gamepads to custom devices such as guitars, pedals, dance pads, scratching gamepads, magic wands, or VR/AR controllers. Each of these devices has its own inputs that need to be mapped into native input APIs for them to appear to Web applications, and outputs (LEDs, vibration, etc.) that are mostly unavailable on the Web. WebHID proposes to expose the HID protocol that most of these devices use under the hoods to Web applications, allowing them to support the long tail of HID devices through JavaScript-based logic when the browser lacks support. Looking forward, this proposal could also ease integration between smartphones and all sorts of tangible user interfaces.

-
-

The Badging API defines a more subtle notification mechanism than Web Notifications, allowing Web applications that have been installed on the device (e.g. through a manifest file) to set an application-wide badge, typically shown next to the application's icon on the home screen, to notify the user when the state of the application has changed and might require their attention (e.g. a new message has arrived).

-
-

Applications that need to run long tasks (e.g. when pages are loaded) need to make a tradeoff between loading pages quickly (or reducing task execution duration) and responding to input quickly. The Early detection of input events specification proposes an isInputPending method that long running scripts can call synchronously, without losing time yiedling to other scripts and events processing, to detect whether there are pending input events that their execution might delay from firing.

diff --git a/mobile/userinput.zh.html b/mobile/userinput.zh.html index 8fd8ab3e..8d01b4dd 100644 --- a/mobile/userinput.zh.html +++ b/mobile/userinput.zh.html @@ -44,7 +44,10 @@

开发中的技术

CSS 的 will-change 属性也可以向浏览器指示将会很快被滚动到的部分并指示这部分应该被预渲染。

-

推送API使服务器端的通知可以提醒用户，即使是在浏览器没有运行的情况下。

+
+

推送API使服务器端的通知可以提醒用户，即使是在浏览器没有运行的情况下。

+

除了Web通知以外，标记 API定义了另一种通知机制，允许已经安装在设备上的 Web 应用（例如通过清单文件）设置一个标记，通常显示在主屏幕上应用程序的图标旁边，在应用程序的状态发生变化时通知用户可能需要注意的信息（如新消息）。

+

不论用户使用语音向它们的应用设备下达命令还是通过非触觉交互来处理这些命令，他们都面临着由于屏幕保护程序导致的屏幕自动关闭的风险。唤醒锁 API 让开发者在这种情况下保持屏幕不锁定。

@@ -64,10 +67,6 @@

探索性工作

游戏手柄有各种各样的类型，从一般的游戏机手柄到如吉他、踏板、跳舞毯、魔术棒、VR/AR控制器等定制设备，这些设备中的每一种都有自己的输入和输出方式，需要映射到操作系统的原生API，以便 Web 应用使用他们。WebHID 提议将大多数设备使用的 HID 协议暴露给 Web 应用，使他们在浏览器缺乏支持时通过基于 JavaScript 的逻辑实现。展望未来，该提案还可以简化智能手机与各种有形用户界面之间的集成。

-
-

除了Web通知以外，标记 API定义了另一种通知机制，允许已经安装在设备上的 Web 应用（例如通过清单文件）设置一个标记，通常显示在主屏幕上应用程序的图标旁边，在应用程序的状态发生变化时通知用户可能需要注意的信息（如新消息）。

-
-

需要运行长任务的应用（例如在加载页面时）需要在快速加载页面（或减少任务执行时间）与快速响应输入之间进行权衡。输入事件的早期检测规范提出了 isInputPending 方法，长时间运行的脚本可以同步调用，而不会浪费时间在其他脚本和事件处理上，以检测是否有未处理的输入事件，这些事件的执行可能会延迟触发。

diff --git a/tools/extract-impl-data.js b/tools/extract-impl-data.js index f467649e..ac5b57d7 100644 --- a/tools/extract-impl-data.js +++ b/tools/extract-impl-data.js @@ -302,19 +302,23 @@ let sources = { let res = { ua }; switch (edgestatus) { case 'Shipped': + case 'Supported': res.status = 'shipped'; break; case 'Preview Release': case 'Prefixed': + case 'Partial Support': res.status = 'experimental'; break; case 'In Development': + case 'In Development (Windows & Mac backend services)': res.status = 'indevelopment'; break; case 'Under Consideration': res.status = 'consideration'; break; case 'Not currently planned': + case 'Not Supported': res.status = ''; break; default: