{{DefaultAPISidebar("Page Visibility API")}}
-使用选项卡式浏览，任何给定网页都有可能在后台，因此对用户不可见。页面可见性 API提供了您可以观察的事件，以便了解文档何时可见或隐藏，以及查看页面当前可见性状态的功能。
+使用选项卡式浏览，任何给定网页都有可能在后台，因此对用户不可见。页面可见性 API 提供了您可以观察的事件，以便了解文档何时可见或隐藏，以及查看页面当前可见性状态的功能。
注意：页面可见性 API对于节省资源和提高性能特别有用，它使页面在文档不可见时避免执行不必要的任务。
+注意：页面可见性 API 对于节省资源和提高性能特别有用，它使页面在文档不可见时避免执行不必要的任务。
当用户最小化窗口或切换到另一个选项卡时，API会发送{{event("visibilitychange")}}事件，让监听者知道页面状态已更改。你可以检测事件并执行某些操作或行为不同。例如，如果您的网络应用正在播放视频，则可以在用户将标签放入背景时暂停视频，并在用户返回标签时恢复播放。 用户不会在视频中丢失位置，视频的音轨不会干扰新前景选项卡中的音频，并且用户在此期间不会错过任何视频。
+当用户最小化窗口或切换到另一个选项卡时，API 会发送{{event("visibilitychange")}}事件，让监听者知道页面状态已更改。你可以检测事件并执行某些操作或行为不同。例如，如果您的网络应用正在播放视频，则可以在用户将标签放入背景时暂停视频，并在用户返回标签时恢复播放。 用户不会在视频中丢失位置，视频的音轨不会干扰新前景选项卡中的音频，并且用户在此期间不会错过任何视频。
-{{HTMLElement("iframe")}}的可见性状态与父文档相同。使用CSS属性（例如{{cssxref("display", "display: none;")}}）隐藏<iframe>不会触发可见性事件或更改框架中包含的文档的状态。
{{HTMLElement("iframe")}}的可见性状态与父文档相同。使用 CSS 属性（例如{{cssxref("display", "display: none;")}}）隐藏<iframe>不会触发可见性事件或更改框架中包含的文档的状态。
在页面可见性API之外，用户代理会采取许多策略来减轻背景或隐藏选项卡对性能的影响。这些可能包括：
+在页面可见性 API 之外，用户代理会采取许多策略来减轻背景或隐藏选项卡对性能的影响。这些可能包括：
visible : 页面内容至少是部分可见。 在实际中，这意味着页面是非最小化窗口的前景选项卡。hidden : 页面内容对用户不可见。 在实际中，这意味着文档可以是一个后台标签，或是最小化窗口的一部分，或是在操作系统锁屏激活的状态下。prerender : 页面内容正在被预渲染且对用户是不可见的(被document.hidden当做隐藏). 文档可能初始状态为prerender，但绝不会从其它值转为该值。>prerender : 页面内容正在被预渲染且对用户是不可见的 (被 document.hidden 当做隐藏). 文档可能初始状态为 prerender，但绝不会从其它值转为该值。>unloaded : 页面正在从内存中卸载。x, y 坐标。这是一段简单的代码片段，使用 SVG path data 创建一个 Path2D 路径。路径将会移动到点 (M10 10) ，然后向右侧水平移动80个点 (h 80)，然后向下80个点 (v 80)，然后向左80个点(h -80)，最后回到起始点(z)。
这是一段简单的代码片段，使用 SVG path data 创建一个 Path2D 路径。路径将会移动到点 (M10 10) ，然后向右侧水平移动 80 个点 (h 80)，然后向下 80 个点 (v 80)，然后向左 80 个点 (h -80)，最后回到起始点 (z)。
var canvas = document.getElementById("canvas");
var ctx = canvas.getContext("2d");
diff --git a/files/zh-cn/web/api/payment_request_api/concepts/index.html b/files/zh-cn/web/api/payment_request_api/concepts/index.html
index a6a40972369361..6f6133fdcd7e90 100644
--- a/files/zh-cn/web/api/payment_request_api/concepts/index.html
+++ b/files/zh-cn/web/api/payment_request_api/concepts/index.html
@@ -11,7 +11,7 @@
- 应用程序接口
- 指南
- 支付
- - 支付请求API
+ - 支付请求 API
- 收款方
- 贸易
translation_of: Web/API/Payment_Request_API/Concepts
@@ -19,15 +19,15 @@
---
{{securecontext_header}}{{DefaultAPISidebar("Payment Request API")}}
-交易请求API使在网站或应用上进行的交易变得更便捷。在这篇文档中，我们将了解此接口如何运作，以及各个组件的功能。
+交易请求 API使在网站或应用上进行的交易变得更便捷。在这篇文档中，我们将了解此接口如何运作，以及各个组件的功能。
术语
-在深入了解此API的工作方式前，你应该了解以下术语。
+在深入了解此 API 的工作方式前，你应该了解以下术语。
交易处理机是通过支付方式识别码识别的。交易方式识别码是一个指向唯一交易处理机的字符串，它可以是一套已成标准的识别码，也可以是一个URL。后者被交易处理服务同时用于两种用途：自证身份和处理交易。
+交易处理机是通过支付方式识别码识别的。交易方式识别码是一个指向唯一交易处理机的字符串，它可以是一套已成标准的识别码，也可以是一个 URL。后者被交易处理服务同时用于两种用途：自证身份和处理交易。
目前注册在案的只有一套标准化交易方式识别码。（未来可能会添加更多。）
基本卡（basic-card, 输入一次银行卡信息后即可多次消费的支付方式）基本卡（basic-card，输入一次银行卡信息后即可多次消费的支付方式）这种识别方式的具体使用将会极大程度地依赖不同服务各自的规范。比如，某种服务可能使用多个URL链接，不同URL的使用依赖于API的版本和通信方式等。
+这种识别方式的具体使用将会极大程度地依赖不同服务各自的规范。比如，某种服务可能使用多个 URL 链接，不同 URL 的使用依赖于 API 的版本和通信方式等。
https://apple.com/apple-payhttps://google.com/pay{{Glossary("user agent")}}内部机制支持不同类型的交易。另外，你还可以调用交易处理API来支持更多相应的支付方式提供方（前提是你使用的浏览器支持这些API的使用）。不论使用哪种方式，交易处理机的功能都是如下几条：
+{{Glossary("user agent")}}内部机制支持不同类型的交易。另外，你还可以调用交易处理 API来支持更多相应的支付方式提供方（前提是你使用的浏览器支持这些 API 的使用）。不论使用哪种方式，交易处理机的功能都是如下几条：
在这个例子中，由fetchValidationData()方法加载由validationURL提供的认证信息。要注意到的是，这个方法必须由商家服务器转发，因为通常情况下，客户端不会主动访问用于认证的URL。
在这个例子中，由fetchValidationData()方法加载由validationURL提供的认证信息。要注意到的是，这个方法必须由商家服务器转发，因为通常情况下，客户端不会主动访问用于认证的 URL。
然后，该数据（或用来解析该数据的{{jsxref("Promise")}}）被传送给交易处理机的complete()方法。交易处理机可以用该数据获取更多信息或是进行更多重的算法解析，以认证商家对处理机的使用权。
因此，注意到如下事实很重要：{{Glossary("user agent")}}永远不会发送{{event("merchantvalidation")}}事件，除非用户代理自身装载了交易处理机。例如，Safari浏览器本身即支持Apple Pay，而Apple Pay的交易处理机可据此向客户端发送merchantvalidation、指示客户端获取服务器上的认证信息，并将其传送给交易处理机的complete()，来为商品进行支付。
因此，注意到如下事实很重要：{{Glossary("user agent")}}永远不会发送{{event("merchantvalidation")}}事件，除非用户代理自身装载了交易处理机。例如，Safari 浏览器本身即支持 Apple Pay，而 Apple Pay 的交易处理机可据此向客户端发送merchantvalidation、指示客户端获取服务器上的认证信息，并将其传送给交易处理机的complete()，来为商品进行支付。
支付请求API为商家和支付者提供了统一的用户体验。它并非提供一种新的支付方式，而是让用户可以在原有的支付方式中进行选择，并使商家可以获悉用户的支付情况。
+支付请求 API 为商家和支付者提供了统一的用户体验。它并非提供一种新的支付方式，而是让用户可以在原有的支付方式中进行选择，并使商家可以获悉用户的支付情况。
在网上购物时，使许多用户中止购物车结算的原因都可以被归结为填写支付信息表单时的步骤繁多导致的费时费力。支付请求API正是被用以减少支付步骤，逐步彻底消除表单的填写。它的目的是简化结算流程，而实现此目的的方式是通过保存用户相关信息并传送给商家。在理想的情况下，用户将不需要填写HTML表单。
+在网上购物时，使许多用户中止购物车结算的原因都可以被归结为填写支付信息表单时的步骤繁多导致的费时费力。支付请求 API正是被用以减少支付步骤，逐步彻底消除表单的填写。它的目的是简化结算流程，而实现此目的的方式是通过保存用户相关信息并传送给商家。在理想的情况下，用户将不需要填写 HTML 表单。
-使用支付请求API中“保存卡信息并自动扣款”（使用银行卡支付时）的优点：
+使用支付请求 API 中“保存卡信息并自动扣款”（使用银行卡支付时）的优点：
当用户在页面上进行操作发起一次支付，比如点击“购买”按钮时，网页会相应地创建一个{{domxref("PaymentRequest")}}对象。PaymentRequest对象允许网页与用户代理交互，传送用户输入的用以交易的信息。
你可以在Using the Payment Request API中查看完整指南。
注意：此API只有在设置了{{htmlattrxref("allowpaymentrequest","iframe")}}属性时才支持{{htmlelement("iframe")}}元素的跨域使用。
+注意：此 API 只有在设置了{{htmlattrxref("allowpaymentrequest","iframe")}}属性时才支持{{htmlelement("iframe")}}元素的跨域使用。
None; 而且, PeriodicWave 不继承任何属性。
None; 而且，PeriodicWave 不继承任何属性。
None; 而且, PeriodicWave 继承任何属性。
None; 而且，PeriodicWave 继承任何属性。
{{APIRef("Permissions API")}}{{SeeCompatTable}}
-Permissions API的Permissions接口提供核心PermissionAPI功能，例如查询和撤消权限的方法。
+Permissions API的 Permissions 接口提供核心 PermissionAPI 功能，例如查询和撤消权限的方法。
请求使用给定API的权限，目前此功能尚未在任何浏览器中被支持。
+请求使用给定 API 的权限，目前此功能尚未在任何浏览器中被支持。
更多特性将逐步实现。
diff --git a/files/zh-cn/web/api/pictureinpicturewindow/index.html b/files/zh-cn/web/api/pictureinpicturewindow/index.html index a67dcf8a15f309..10070e4bd62f0f 100644 --- a/files/zh-cn/web/api/pictureinpicturewindow/index.html +++ b/files/zh-cn/web/api/pictureinpicturewindow/index.html @@ -7,7 +7,7 @@PictureInPictureWindow接口是一个对象，它可以通过编程的方式获得浮动视频窗口的宽度和高度，并调整浮动视频窗口的大小。
使用{{domxref("HTMLVideoElement.requestPictureInPicture()")}}返回一个具有此接口的promise值
+使用{{domxref("HTMLVideoElement.requestPictureInPicture()")}}返回一个具有此接口的 promise 值
{{DefaultAPISidebar("Pointer Events")}}
-目前绝大多数的Web内容都假设用户的指针定点设备为鼠标。然而，近年来的新兴设备支持更多不同方式的指针定点输入，如各类触控笔和触摸屏幕等。这就有必要扩展现存的定点设备事件模型，以有效追踪各类指针事件。
+目前绝大多数的 Web 内容都假设用户的指针定点设备为鼠标。然而，近年来的新兴设备支持更多不同方式的指针定点输入，如各类触控笔和触摸屏幕等。这就有必要扩展现存的定点设备事件模型，以有效追踪各类指针事件。
-指针事件 - Pointer events 是一类可以为定点设备所触发的DOM事件。它们被用来创建一个可以有效掌握各类输入设备（鼠标、触控笔和单点或多点的手指触摸）的统一的DOM事件模型。所谓 指针 是指一个可以明确指向屏幕上某一组坐标的硬件设备。建立这样一个单独的事件模型可以有效的简化Web站点与应用所需的工作，同时也便于提供更加一致与良好的用户体验，无需关心不同用户和场景在输入硬件上的差异。另外，对于某些需要处理特定设备的场景，指针事件也定义了一个 {{domxref("PointerEvent.pointerType","pointerType")}} 属性用以查看触发事件的设备类型。
+指针事件 - Pointer events 是一类可以为定点设备所触发的 DOM 事件。它们被用来创建一个可以有效掌握各类输入设备（鼠标、触控笔和单点或多点的手指触摸）的统一的 DOM 事件模型。所谓 指针 是指一个可以明确指向屏幕上某一组坐标的硬件设备。建立这样一个单独的事件模型可以有效的简化 Web 站点与应用所需的工作，同时也便于提供更加一致与良好的用户体验，无需关心不同用户和场景在输入硬件上的差异。另外，对于某些需要处理特定设备的场景，指针事件也定义了一个 {{domxref("PointerEvent.pointerType","pointerType")}} 属性用以查看触发事件的设备类型。
这些事件需要能够处理 {{domxref("MouseEvent","mouse events")}} 之类较为通用的指针输入（mousedown/pointerdown, mousemove/pointermove, 等）。 因此，指针事件的类型，很大程度上类似于当前的鼠标事件类型。
此外，一个指针事件，也同时包含了鼠标事件中所常见的属性（client coordinates, target element, button states，等）以及适用于其他输入设备的新属性：pressure, contact geometry, tilt, 等等。实际上，{{domxref("PointerEvent")}} 接口继承了所有 {{domxref("MouseEvent","MouseEvent")}} 中的属性，以保障原有为鼠标事件所开发的内容能更加有效的迁移到指针事件。
+此外，一个指针事件，也同时包含了鼠标事件中所常见的属性（client coordinates, target element, button states，等）以及适用于其他输入设备的新属性：pressure, contact geometry, tilt，等等。实际上，{{domxref("PointerEvent")}} 接口继承了所有 {{domxref("MouseEvent","MouseEvent")}} 中的属性，以保障原有为鼠标事件所开发的内容能更加有效的迁移到指针事件。
-1 to 1, where 0 is the neutral position of the control.对于{{domxref("Element")}}接口有以下一些扩展：
@@ -136,7 +136,7 @@属性 {{domxref("Navigator.maxTouchPoints")}} 被设计用来指明在同一时间点所支持的最大的触摸点数量。
@@ -264,7 +264,7 @@对于某些指针设备来说，比如鼠标或者压感笔，设备上可能有一个或多个按钮可以同时或依次序按动。比如在某个按钮释放后立刻按下其他按钮。为了确定这些按钮的按压状态，指针事件使用{{domxref("MouseEvent.button","button")}}与 {{domxref("MouseEvent.buttons","buttons")}}等{{domxref("MouseEvent")}}接口中的事件 （{{domxref("PointerEvent")}}继承于此）表明相应的状态。下表提供了各类设备的按钮状态与button和buttons属性的属性值对应关系。
+对于某些指针设备来说，比如鼠标或者压感笔，设备上可能有一个或多个按钮可以同时或依次序按动。比如在某个按钮释放后立刻按下其他按钮。为了确定这些按钮的按压状态，指针事件使用{{domxref("MouseEvent.button","button")}}与 {{domxref("MouseEvent.buttons","buttons")}}等{{domxref("MouseEvent")}}接口中的事件（{{domxref("PointerEvent")}}继承于此）表明相应的状态。下表提供了各类设备的按钮状态与 button 和 buttons 属性的属性值对应关系。
| 2 | |||
| 鼠标X1（前进） | +鼠标 X1（前进） | 3 | 8 |
| 鼠标X2（后退） | +鼠标 X2（后退） | 4 | 16 |