1. 各種用語
この仕様は、 Infra 標準 `INFRA$r に依存する。 ◎ This specification depends on the Infra Standard. [INFRA]
この仕様にて利用される一部の用語は、次に挙げる仕様にて定義される ⇒ `DOM$r `FETCH$r `HTML$r `WEBIDL$r `SERVICE-WORKERS$r `URL$r `VIBRATION$r ◎ Some terms used in this specification are defined in the DOM, Fetch, HTML, IDL, Service Workers, URL, and Vibration API Standards. [DOM] [FETCH] [HTML] [WEBIDL] [SERVICE-WORKERS] [URL] [VIBRATION]
【 この仕様が参照する `SERVICE-WORKERS$r の~algo `機能的~eventを取扱う@ ( `handle functional event^en )は、その仕様の更新により,異なる引数をとる`機能的~eventを発火する$に置換された。 それに伴い、この仕様も更新する必要がある。 】
2. 通知
`通知@ ( `notification^en )は、起こった何か — ~messageの送達など — の抽象的な表現である。 ◎ A notification is an abstract representation of something that happened, such as the delivery of a message.
各 `通知$には、以下に挙げるものが結付けられる: ◎ ↓
- `~sw登録@nT
- ε (なし), または `~sw登録$ ◎ A notification can have an associated service worker registration.
- `~title@nT
- 文字列。 ◎ A notification has an associated title which is a DOMString.
- `本体@nT
- 文字列。 ◎ A notification has an associated body which is a DOMString.
- `方向@nT
- `NotificationDirection$I 値 — 次のいずれか ⇒# `auto^l, `ltr^l, `rtl^l ◎ A notification has an associated direction which is one of auto, ltr, and rtl.
- `言語@nT
- 空~文字列, または 妥当な BCP 47 言語~tagを表現している文字列。 ◎ A notification has an associated language which is a DOMString representing either a valid BCP 47 language tag or the empty string.
- `~tag@nT
- 文字列。 【同じ概念的~eventを識別する。】 ◎ A notification has an associated tag which is a DOMString.
- `~data@nT
- 【~appが自前の目的に利用できる任意の~data。】 ◎ A notification has an associated data.
- `時刻印@nT
- [ 1970 年 1 月 1 日 00:00:00 UTC ]から[ 当の【概念的】~event用に通知が作成された時点 ]までの時間差を表す,~milli秒単位による数を表現している `DOMTimeStamp$I 値になる。 ◎ A notification has an associated timestamp which is a DOMTimeStamp representing the time, in milliseconds since 00:00:00 UTC on 1 January 1970, of the event for which the notification was created.
- 注記: 時刻印は、通知【の作成~時刻に代えて,その内容が表す現実の~event】の実際の時刻を指示するためにも利用できる。 例えば、[ 機器が~offlineにあるために即時に送達できなかった~message用に通知が利用された時点を指す過去 ]にすることも, [ 開始しつつある会合~用の未来 ]にすることもできる。 ◎ Timestamps can be used to indicate the time at which a notification is actual. For example, this could be in the past when a notification is used for a message that couldn’t immediately be delivered because the device was offline, or in the future for a meeting that is about to start.
- `生成元@nT
- `生成元$ ◎ A notification has an associated origin.
- `再通知-選好~flag@nT
- 初期~時には ~F とする。 ~T の場合、[ 通知を置換する手続きを走らせた後には,末端~利用者に~alertされるべきである ]ことを指示する。 【この記述は、実際の挙動の一部しか捉えていない。】 ◎ A notification has an associated renotify preference flag which is initially unset. When set indicates that the end user should be alerted after the replace steps have run.
- `静音~選好~flag@nT
- 初期~時には ~F とする。 ~T の場合、音響や振動は生じないべきであることを指示する。 【音響の~supportは除去された。】 ◎ A notification has an associated silent preference flag which is initially unset. When set indicates that no sounds or vibrations should be made.
- `対話~選好を要求する~flag@nT
- 初期~時には ~F とする。 ~T の場合、大きさに不足ない~screenを備える機器~上では,通知は 利用者が当の通知を[ 作動化する/退ける ]まで,いつでも可用であり続けるべきであることを指示する。 ◎ A notification has an associated require interaction preference flag which is initially unset. When set, indicates that on devices with a sufficiently large screen, the notification should remain readily available until the user activates or dismisses the notification.
各 `通知$には、以下に挙げるものも結付けられ得る。 初期~時には、いずれも結付けられていないとする — [ これらがとる/これらに設定される ]値 ε は,結付けられていないことを表すとする: ◎ ↓
- `画像~URL@nT
- `~icon~URL@nT
- `~badge~URL@nT
- 順に,[ `画像~資源$nT, `~icon資源$nT, `~badge資源$nT ]の~URLを与える。 ◎ A notification can have these associated graphics: an image URL, icon URL, and badge URL; and their corresponding image resource, icon resource, and badge resource.
- `画像~資源@nT
- `通知$を成す内容の一部として示され,[ `~icon資源$nT, `~badge資源$nT ]より高い視覚的~優先度で表示されるべき絵図を与える†。 より少ない状況下で表示されてもよいが††。 ◎ An image resource is a picture shown as part of the content of the notification, and should be displayed with higher visual priority than the icon resource and badge resource, though it may be displayed in fewer circumstances.
- 【† 言い換えれば、[ `画像~資源$nTとは、挙げられた 3 種の資源のうち,通知~platformにて 一般に最も高い優先度で表示される画像である ]ものと定義される,と捉えることもできる。 】【†† どれを優先するかは、状況に応じて,通知~platformが制御するかもしれない。 】
- `~icon資源@nT
- `通知$を増補する画像(~iconや送信者の写真など)を与える。 ◎ An icon resource is an image that reinforces the notification (such as an icon, or a photo of the sender).
- `~badge資源@nT
- `~badge資源$nTは、当の~web~app — あるいは,~web~appが何種類かの`通知$を送信する場合には、`通知$の種類 — を表現している~iconを与える。 `通知$自体を表示する十分な空間がない場合にも、`通知$を表現するために利用されて~MAY。 `通知$の内側に表示されても~MAYが、その視覚的~優先度は[ `画像~資源$nT, `~icon資源$nT ]より低くされるべきである。 ◎ A badge resource is an icon representing the web application, or the category of the notification if the web application sends a wide variety of notifications. It may be used to represent the notification when there is not enough space to display the notification itself. It may also be displayed inside the notification, but then it should have less visual priority than the image resource and icon resource.
- `振動~pattern@nT
- 【通知-時に生じる振動を表す~dataを与える。】 ◎ A notification can have a vibration pattern.
注記: 開発者には、[ `画像~資源$nT, `~icon資源$nT, `~badge資源$nT, `振動~pattern$nT ]を通して伝達される情報を,末端~利用者が他からも~access可能にすることが奨励される — とりわけ,これらの特色機能を~supportしない通知~platformは、これらを無視するかもしれないので。 ◎ Developers are encouraged to not convey information through an image, icon, badge, or vibration pattern that is not otherwise accessible to the end user, especially since notification platforms that do not support these features might ignore them.
各 `通知$には、 0 個~以上の `動作@nT からなる `動作~list@nT も結付けられる。 各`動作$nTには、次のものが結付けられる:
- `~title@acT
- 文字列。
- `名前@acT
- 文字列。
- `~icon~URL@acT
- ε ( “なし” ), または`~icon資源$acTの~URL。 初期~時は ε とする。
- `~icon資源@acT
- ε ( “なし” ), または画像。 初期~時は ε とする。
利用者は、通知~自体を作動化する代替として,ある`動作$nTを作動化することもある。 ~UAは、通知~platformの拘束の下で~supportされる `最大~動作~数@ を決定し~MUST。 ◎ Users may activate actions, as alternatives to activating the notification itself. The user agent must determine the maximum number of actions supported, within the constraints of the notification platform.
注記: 動作の表示-は~platformに依存するので、開発者には,[ 利用者が通知から呼出せるどの動作も,~web~appの中で可用にする ]ことが奨励される。 ◎ Since display of actions is platform-dependent, developers are encouraged to make sure that any action a user can invoke from a notification is also available within the web application.
注記: 一部の~platformは、`~icon資源$acTを[ 利用者に表示する前に,~platformの視覚的~styleにより良く合致するよう改変する ]かもしれない — 例えば[ 隅を丸める/特定の色で塗る ]などにより。 開発者には、そのような事例に対しても,利用する~iconの重要な情報が[ 隅が切取られる/色が不明瞭になる ]などにより失われないよう,上品に取扱うことが奨励される。 ◎ Some platforms might modify an icon resource to better match the platform’s visual style before displaying it to the user, for example by rounding the corners or painting it in a specific color. Developers are encouraged to use an icon that handles such cases gracefully and does not lose important information through, e.g., loss of color or clipped corners.
`通知$のうち、[ その`~sw登録$nT ~NEQ ε ]なるものは `持続的@ ( `persistent^en ) とされ,他のものは `持続的でない@ ( `non-persistent^en )とされる。 【後者の用語は、単なる前者の否定なので,この訳では単に “`持続的$でない” と記すことにする。】 ◎ A non-persistent notification is a notification without an associated service worker registration. ◎ A persistent notification is a notification with an associated service worker registration.
`通知を作成する@ ときは、所与の ( %~title, %options, %~sw登録 (省略時は ε ) ) に対し,次を走らす: ◎ To create a notification, given a title, options, and optionally a serviceWorkerRegistration, run these steps:
- %通知 ~LET 新たな`通知$ ◎ Let notification be a new notification.
- %通知 の`~sw登録$nT ~SET %~sw登録 ◎ If a serviceWorkerRegistration was provided, set notification’s service worker registration to serviceWorkerRegistration.
-
~IF[ 下に挙げるいずれかが満たされる ] ⇒ ~THROW `TypeError^E
-
[ %~sw登録 ~EQ ε ]~AND[ %options の `actions$mO は空でない ] ◎ If a serviceWorkerRegistration was not provided and options’s actions is not empty, throw a TypeError exception.
注記: 現在,`動作$nTは、`持続的$な通知に限り,~supportされている。 ◎ Actions are only currently supported for persistent notifications.
- [ %options の `silent$mO ~EQ ~T ]~AND[ %options の `vibrate$mO は在する ] ◎ If options’s silent is true and options’s vibrate is present, throw a TypeError exception.
- [ %options の `renotify$mO ~EQ ~T ]~AND[ %options の `tag$mO ~EQ 空~文字列 ] ◎ If options’s renotify is true and options’s tag is the empty string, throw a TypeError exception.
-
- %通知 の `~data$nT ~SET `StructuredSerializeForStorage$A( %options の `data$mO ) (例外投出あり) ◎ Set notification’s data to StructuredSerializeForStorage(options’s data). Rethrow any exceptions.
- %通知 の ⇒# `~title$nT ~SET %~title, `方向$nT ~SET %options の `dir$mO, `言語$nT ~SET %options の `lang$mO, `生成元$nT ~SET `入口~設定群~obj$の`生成元$enV, `本体$nT ~SET %options の `body$mO, `~tag$nT ~SET %options の `tag$mO ◎ Set notification’s title to title. ◎ Set notification’s direction to options’s dir. ◎ Set notification’s language to options’s lang. ◎ Set notification’s origin to the entry settings object’s origin. ◎ Set notification’s body to options’s body. ◎ Set notification’s tag to options’s tag.
- %基底~URL ~LET `入口~設定群~obj$ または`現任の設定群~obj$? により指定される`~API用~基底~URL$enV ◎ Let baseURL be the API base URL specified by the entry settings object. Or incumbent?
-
%通知 の ⇒# `画像~URL$nT ~SET `~URLを得る^i( `image$mO ), `~icon~URL$nT ~SET `~URLを得る^i( `icon$mO ), `~badge~URL$nT ~SET `~URLを得る^i( `badge$mO )
この段の中で `~URLを得る^i ときは、所与の ( %名前 ) に対し,次の下位手続きを走らすとする:
- %url ~LET `失敗^i
- ~IF[ %options に %名前 ~memberは在する ] ⇒ %url ~SET `~URL構文解析する$( その~member値, %基底~URL )
- ~RET[ %url ~EQ `失敗^i ならば ε / ~ELSE_ %url ]
- %通知 の`振動~pattern$nT ~SET [ %options の `vibrate$mO は在するならば `検証して正規化する$( その値 ) の結果 / ~ELSE_ ε ] ◎ If options’s vibrate is present, validate and normalize it and set notification’s vibration pattern to the return value. (Otherwise vibration pattern is not set.)
- %通知 の`時刻印$nT ~SET [ %options の `timestamp$mO は在するならば その値 / ~ELSE_ 次で与えられる値 ] ⇒ [ 1970 年 1 月 1 日 00:00:00 UTC ]から `Notification()$m 構築子が~callされた時点までの時間差を~milli秒単位で表す数 ◎ If options’s timestamp is present, set notification’s timestamp to the value. Otherwise, set notification’s timestamp to the number of milliseconds that passed between 00:00:00 UTC on 1 January 1970 and the time at which the Notification constructor was called.
- %通知 の ⇒# `再通知-選好~flag$nT ~SET %options の `renotify$mO, `静音~選好~flag$nT ~SET %options の `silent$mO, `対話~選好を要求する~flag$nT ~SET %options の `requireInteraction$mO ◎ If options’s renotify is true, set notification’s renotify preference flag. ◎ If options’s silent is true, set notification’s silent preference flag. ◎ If options’s requireInteraction is true, set notification’s require interaction preference flag.
- %通知 の`動作~list$nT ~SET 空~list ◎ Set notification’s list of actions to an empty list, then\
-
%options の `actions$mO 内の~EACH( %~entry ) に対し: ◎ for each entry in options’s actions\
- ~IF[ %通知 の`動作~list$nTの~size ~GTE ~supportされる`最大~動作~数$ ] ⇒ ~BREAK ◎ , up to the maximum number of actions supported (skip any excess entries), perform the following steps:
- %動作 ~LET 次のようにされた新たな`動作$nT ⇒# `名前$acT ~SET %~entry の `action$mA, `~title$acT ~SET %~entry の`title$mA ◎ Let action be a new action. ◎ Set action’s name to the entry’s action. ◎ Set action’s title to the entry’s title.
-
~IF[ %~entry に `icon$mA ~memberは在する ]:
- %url ~LET `~URL構文解析する$( その~member値, %基底~URL )
- ~IF[ %url ~NEQ `失敗^i ] ⇒ %動作 の`~icon~URL$acT ~SET %url
- %通知 の`動作~list$nTに %動作 を付加する ◎ Append action to notification’s list of actions.
- ~RET %通知 ◎ Return notification.
2.1. 存続期間と~UI統合
~UAは、 `通知~list@ を保た~MUST — それは、 0 個~以上の`通知$からなる`~list$である。 ~UAには、次の要件が課される: ◎ The user agent must keep a list of notifications, which is a list of zero or more notifications.
- `持続的$でない通知に対しては,作成した数秒~後には`通知を閉じる$べきである。 ◎ User agents should run the close steps for a non-persistent notification a couple of seconds after they have been created.
- ~platformの “通知~center” が可用であっても,`持続的$でない通知をそこに表示するべきでない。 ◎ User agents should not display non-persistent notification in a platform’s "notification center" (if available).
-
`持続的$な通知を,`通知~list$から除去されるまでは持続化するべきである。 ◎ User agents should persist persistent notifications until they are removed from the list of notifications.
`持続的$な通知は、それを表現するいずれかの `Notification$I ~obj上で `close()$m ~methodを呼出すこともできる。 ◎ A persistent notification could have the close() method invoked of one of its Notification objects.
- ~platformの “通知~center” が可用ならば,`持続的$な通知をそこに表示するべきである。 ◎ User agents should display persistent notifications in a platform’s "notification center" (if available).
2.2. 許可~model
`通知$が表示され得るのは、利用者(または利用者に利する~UA)が `許可@ を是認した場合に限られる。 所与の`生成元$用の`通知$を示す`許可$は、次のいずれかの文字列として与えられる: ◎ Notifications can only be displayed if the user (or user agent on behalf of the user) has granted permission. The permission to show notifications for a given origin is one of three strings:
- `default$l
- `denied$l に等価であるが、利用者は,まだ明示的に選んではいない。 ◎ This is equivalent to "denied", but the user has made no explicit choice thus far.
- `denied$l
- 利用者は`通知$を求めていないことを意味する。 ◎ This means the user does not want notifications.
- `granted$l
- `通知$を表示できることを意味する。 ◎ This means notifications can be displayed.
注記: `granted$l を意味するような `default$l に等価な文字列は無い。 その事例では、単純に `granted$l が返される — ~appに`許可$を尋ねる理由は無いので。【?】 ◎ There is no equivalent to "default" meaning "granted". In that case "granted" is simply returned as there would be no reason for the application to ask for permission.
2.3. 方向
この節における用語 “期待される” は、~HTMLの 具現化~節に利用されるそれ と等価とする。 `HTML$r ◎ This section is written in terms equivalent to those used in the Rendering section of HTML. [HTML]
~UAには、`通知$の`~text内容$における~Unicode意味論を尊守することが期待される — ここでの `~text内容@ とは、[ `~title$nTと`本体$nT, および `動作~list$nT内の各`動作$nTの`~title$acT ]を成す~textの総称である。 各`~text内容$は、表示されるときには[ 1 個~以上の双向~algo段落が成す,互いに独立な集合 ]として,双向~algoの規則[ `P1^i, `P2^i, `P3^i ]に定義されるように扱うことが期待される — 具体例として、文字 U+000A (LF) による段落分断の挙動を~supportすることも含め。 `通知$の`方向$nTに対する `auto^l 以外の値は、`通知$の各`~text内容$を成す各~段落に対し,規則[ `P2^i, `P3^i ]より高~levelの上書きを供する。 `BIDI$r ◎ User agents are expected to honor the Unicode semantics of the text of a notification’s title, body, and the title of each of its actions. Each is expected to be treated as an independent set of one or more bidirectional algorithm paragraphs when displayed, as defined by the bidirectional algorithm’s rules P1, P2, and P3, including, for instance, supporting the paragraph-breaking behavior of U+000A LINE FEED (LF) characters. For each paragraph of the title, body and the title of each of the actions, the notification’s direction provides the higher-level override of rules P2 and P3 if it has a value other than "auto". [BIDI]
`通知$の`方向$nTは、通知~platformが,`通知$の一連の`動作$nTを 利用者~向けに並べて表示する場合に、それらが従うべき順序も決定する。 ◎ The notification’s direction also determines the relative order in which the notification’s actions should be displayed to the user, if the notification platform displays them side by side.
2.4. 言語
`通知$の`言語$nTは、`通知$の`~text内容$用の第一~言語を,文字列で指定する。 空~文字列は、第一~言語は未知であることを指示する。 他の文字列は、言語~tag `LANG$r として解釈され~MUST。 [ 妥当性/整形式性 ]は、施行されない。 ◎ The notification’s language specifies the primary language for the notification’s title, body and the title of each of its actions. Its value is a string. The empty string indicates that the primary language is unknown. Any other string must be interpreted as a language tag. Validity or well-formedness are not enforced. [LANG]
注記: 開発者には、妥当な言語~tagのみを利用することが奨励される。 ◎ Developers are encouraged to only use valid language tags.
2.5. 資源
`通知を~fetchする@ ときは、所与の ( `通知$ %通知 ) に対し: ◎ The fetch steps for a given notification notification are:
-
【以下を簡潔に集約するため,この訳では、この段にて次に与える手続きを導入する。】
この手続きの中で, `資源を~fetchして復号する^i ときは、所与の ( %url ) に対し, %url を`~fetch$した上で,次を`並列的$に走らす:
- %応答 ~SET ~fetchされた結果の`応答$
- %応答 を待機する
- ~IF[ %応答 の`内部~応答$の`種別$rs ~EQ `default$l ] ⇒ 資源を画像として復号することを試みる ⇒ ~IF [ ~UAは 復号された資源の形式を~supportする ] ⇒ 復号された資源を結果として,非同期に完了する
- ε を結果として,非同期に完了する
注記: 画像~資源の場合、この資源を~fetchする意図は, `img^e と同様 であるが、これは 抽象化する必要がある。 ◎ The intent is to fetch this resource similar to an <img>, but this needs abstracting.
◎ ↓ - ( %画像~URL, %~icon~URL, %~badge~URL ) ~LET %通知 の ( `画像~URL$nT, `~icon~URL$nT, `~badge~URL$nT ) ◎ ↓
-
~IF[ 通知~platformは画像を~supportする ]~AND[ %画像~URL ~NEQ ε ] ⇒ `資源を~fetchして復号する^i( %画像~URL ) ⇒ これが %結果 を結果として非同期に完了したときは ⇒ %通知 の`画像~資源$nT ~SET %結果 ◎ If the notification platform supports images, fetch notification’s image URL, if image URL is set. ◎ The intent is to fetch this resource similar to an <img>, but this needs abstracting. ◎ Then, in parallel: • Wait for the response. • If the response’s internal response’s type is "default", then attempt to decode the resource as image. • If the image format is supported, set notification’s image resource to the decoded resource. (Otherwise notification has no image resource.)
- ~IF[ 通知~platformは~iconを~supportする ]~AND[ %~icon~URL ~NEQ ε ] ⇒ `資源を~fetchして復号する^i( %~icon~URL ) ⇒ これが %結果 を結果として非同期に完了したときは ⇒ %通知 の`~icon資源$nT ~SET %結果 ◎ If the notification platform supports icons, fetch notification’s icon URL, if icon URL is set. ◎ The intent is to fetch this resource similar to an <img>, but this needs abstracting. ◎ Then, in parallel: • Wait for the response. • If the response’s internal response’s type is "default", then attempt to decode the resource as image. ◎ If the image format is supported, set notification’s icon resource to the decoded resource. (Otherwise notification has no icon resource.)
-
~IF[ 通知~platformは~badgeを~supportする ]~AND[ %~badge~URL ~NEQ ε ] ⇒ `資源を~fetchして復号する^i( %~badge~URL ) ⇒ これが %結果 を結果として非同期に完了したときは ⇒ %通知 の`~badge資源$nT ~SET %結果 ◎ If the notification platform supports badges, fetch notification’s badge URL, if badge URL is set. ◎ The intent is to fetch this resource similar to an <img>, but this needs abstracting. ◎ Then, in parallel: • Wait for the response. • If the response’s internal response’s type is "default", then attempt to decode the resource as image. • If the image format is supported, set notification’s badge resource to the decoded resource. (Otherwise notification has no badge resource.)
-
~IF[ 通知~platformは動作と動作~iconを~supportする ] ⇒ %通知 の`動作~list$nT内の~EACH( %動作 ) に対し ⇒ ~IF[ %動作 の`~icon~URL$acT ~NEQ ε ] ⇒ `資源を~fetchして復号する^i( %動作 の`~icon~URL$acT ) ⇒ これが %結果 を結果として非同期に完了したときは ⇒ %動作 の`~icon資源$acT ~SET %結果 ◎ If the notification platform supports actions and action icons, then for each action in notification’s list of actions fetch action’s icon URL, if icon URL is set. ◎ The intent is to fetch this resource similar to an <img>, but this needs abstracting. ◎ Then, in parallel: • Wait for the response. • If the response’s internal response’s type is "default", then attempt to decode the resource as image. • If the image format is supported, set action’s icon resource to the decoded resource. (Otherwise action has no icon resource.)
2.6. 通知を示すとき
`通知を示す@ ときは、所与の ( `通知$ %通知 ) に対し,次を走らす: ◎ The show steps for a given notification notification are:
- %通知 用の`通知を~fetchする$手続きの中で走らせた `資源を~fetchして復号する^i 手続きがあれば、それらすべてが非同期に完了するまで待機する ◎ Wait for any fetches to complete and notification’s image resource icon resource, and badge resource to be set (if any), as well as the icon resources for the notification’s actions (if any).
- %示した ~LET ~F ◎ Let shown be false.
- %旧~通知 ~LET `通知~list$内に次を満たす`通知$が[ 在るならば それ / 無いならば ~NULL ] ⇒ [ その`~tag$nT ~EQ %通知 の`~tag$nT ~NEQ 空~文字列 ]~AND[ ( その`生成元$nT, %通知 の`生成元$nT ) は`同一生成元$である ] ◎ Let oldNotification be the notification in the list of notifications whose tag is not the empty string and is notification’s tag, and whose origin is same origin with notification’s origin, if any, and null otherwise.
-
~IF[ %旧~通知 ~NEQ ~NULL ]: ◎ If oldNotification is non-null, then:
- `~close~eventを取扱う$( %旧~通知 ) ◎ Handle close events with oldNotification.
-
~IF[ 通知~platformは置換を~supportする ]: ◎ If the notification platform supports replacement, then:
- `通知~list$内の %旧~通知 を %通知 に`置換する$ ◎ Replace oldNotification with notification, in the list of notifications.
- %示した ~SET ~T ◎ Set shown to true.
注記: 通知~platformには、~nativeな置換 【表示-中の通知を置換する?】 を~supportすることが強く奨励される — その方が利用者~体験は良くなるので。 ◎ Notification platforms are strongly encouraged to support native replacement as it leads to a better user experience.
- ~ELSE ⇒ `通知~list$から %旧~通知 を`除去する$ ◎ Otherwise, remove oldNotification from the list of notifications.
-
~IF[ %示した ~EQ ~F ]: ◎ If shown is false, then:
- `通知~list$に %通知 を`付加する$ ◎ Append notification to the list of notifications.
- 機器~上に %通知 を表示する(通知~platformの適切な~APIを~callするなどにより) ◎ Display notification on the device (e.g., by calling the appropriate notification platform API).
-
~IF[ %示した ~EQ ~F ]~OR[[ %旧~通知 ~NEQ ~NULL ]~AND[ %通知 の`再通知-選好~flag$nT ~EQ ~T ]] ⇒ `通知を~alertする$( %通知 )
【 原文の ~OR, ~AND の優先順がはっきりしないが、 ~OR 優先だと[ %示した ~EQ ~F ]が無為な記述になるので, ~AND 優先と思われる。 】
◎ If shown is false or oldNotification is non-null and notification’s renotify preference flag has been set, then run the alert steps for notification. - ~IF[ %通知 は`持続的$でない ] ⇒ 次を走らす`~taskを~queueする$ ⇒ %通知 を表現している【`唯一の$】 `Notification$I ~objに向けて,名前 `show^et の`~eventを発火する$ ◎ If notification is a non-persistent notification, then queue a task to fire an event named show on the Notification object representing notification.
2.7. 通知の作動化-法
下層の通知~platformは作動化を~supportする下で、[ `通知$ %通知 / %通知 の`動作~list$nTを成すいずれかの`動作$nT ]が利用者により作動化されたときは、~UAは,(他が指定されない限り)次の手続きを走らせ~MUST: ◎ When a notification notification, or one of its actions, is activated by the user, assuming the underlying notification platform supports activation, the user agent must (unless otherwise specified) run these steps:
-
~IF[ %通知 は`持続的$である ]: ◎ If notification is a persistent notification, then:
- %動作~名 ~LET 空~文字列 ◎ Let action be the empty string.
- ~IF[ 利用者により %通知 の`動作~list$nTを成すいずれかの`動作$nTが作動化された ] ⇒ %動作~名 ~SET その`動作$nTの`名前$acT ◎ If one of notification’s actions was activated by the user, then set action to that action’s name.
- %~callback ~LET 引数 %大域 で呼出されたとき次を走らす~algo ⇒ `~sw通知~eventを発火する$( %大域, `notificationclick^et, %通知, %動作~名 ) ◎ Let callback be an algorithm that when invoked with a global, fires a service worker notification event named notificationclick given notification and action on global.
- `機能的~eventを取扱う$( %通知 の`~sw登録$nT, %~callback ) ◎ Then run Handle Functional Event with notification’s service worker registration and callback.
- ~RET ◎ ↓
-
次を走らす`~taskを~queueする$: ◎ Otherwise, queue a task to run these steps:
-
%~focusする ~LET 次を走らせた結果 ⇒ [ %通知 を表現している【`唯一の$】 `Notification$I ~obj ]に向けて,名前 `click^et の`~eventを発火する$ — 次のように初期化して ⇒# `cancelable$m 属性 ~SET ~T ◎ Let intoFocus be the result of firing an event named click on the Notification object representing notification, with its cancelable attribute initialized to true.
注記: ~UAには、[ `click^et ~event用の~event~listenerの中からも, `focus()$m が働くようにする ]ことが奨励される。 ◎ User agents are encouraged to make focus() work from within the event listener for the event named click.
- ~IF[ %~focusする ~EQ ~T ] ⇒ ~UAは %通知 に関係する`閲覧文脈$の表示域に~focusするべきである ◎ If intoFocus is true, then the user agent should bring the notification’s related browsing context’s viewport into focus.
-
注記: ~web~platform全体にわたり、 "`activate^en" ( “作動化-” )は,意図的に "`click^en" と誤って命名されている。 ◎ Throughout the web platform "activate" is intentionally misnamed as "click".
2.8. 通知の~close法
[ 下層の通知~platform/利用者 ]により`通知$が~closeされたときは、`通知を閉じる$手続きを走らせ~MUST。 ◎ When a notification is closed, either by the underlying notification platform or by the user, the close steps for it must be run.
`通知を閉じる@ ときは、所与の ( `通知$ %通知 ) に対し,次を走らす: ◎ The close steps for a given notification are:
- ~IF[ %通知 ~NIN `通知~list$ ] ⇒ ~RET ◎ If the list of notifications does not contain notification, then abort these steps.
- `~close~eventを取扱う$( %通知 ) ◎ Handle close events with notification.
- `通知~list$から %通知 を`除去する$ ◎ Remove notification from the list of notifications.
`~close~eventを取扱う@ ときは、所与の ( %通知 ) に対し,次を走らす: ◎ To handle close events given a notification, run these steps:
-
~IF[ %通知 は`持続的$である ]~AND[ %通知 は利用者により~closeされた ]: ◎ If notification is a persistent notification and notification was closed by the user, then:
- %~callback ~LET 引数 %大域 で呼出されたとき次を走らす~algo ⇒ `~sw通知~eventを発火する$( %大域, `notificationclose^et, %通知 ) ◎ Let callback be an algorithm that when invoked with a global, fires a service worker notification event named notificationclose given notification on global.
- `機能的~eventを取扱う$( %通知 の`~sw登録$nT, %~callback ) ◎ Then run Handle Functional Event with notification’s service worker registration and callback.
- ~IF[ %通知 は`持続的$でない ] ⇒ 次を走らす`~taskを~queueする$ ⇒ %通知 を表現している `Notification$I ~objに向けて,名前 `close^et の`~eventを発火する$ ◎ If notification is a non-persistent notification, then queue a task to fire an event named close on the Notification object representing notification.
2.9. 利用者への~alert法
利用者に `通知を~alertする@ ときは、所与の ( `通知$ %通知 ) に対し,次を走らす: ◎ The alert steps for alerting the user about a given notification are:
- ~IF[ %通知 の`振動~pattern$nT ~NEQ ε ] ⇒ `振動を遂行する$( %通知 の`振動~pattern$nT ) ◎ Perform vibration using notification’s vibration pattern, if any.
3. ~API
[`Constructor$m(DOMString %title, optional `NotificationOptions$I %options), `Exposed$=(Window,Worker)] interface `Notification@I : `EventTarget$I { static readonly attribute `NotificationPermission$I `permission$m; [`Exposed$=Window] static Promise<`NotificationPermission$I> `requestPermission$m(optional `NotificationPermissionCallback$I %deprecatedCallback); static readonly attribute unsigned long `maxActions$m; attribute `EventHandler$I `onclick$m; attribute `EventHandler$I `onshow$m; attribute `EventHandler$I `onerror$m; attribute `EventHandler$I `onclose$m; readonly attribute DOMString `title$m; readonly attribute `NotificationDirection$I `dir$m; readonly attribute DOMString `lang$m; readonly attribute DOMString `body$m; readonly attribute DOMString `tag$m; readonly attribute USVString `image$m; readonly attribute USVString `icon$m; readonly attribute USVString `badge$m; [`SameObject$] readonly attribute FrozenArray<unsigned long> `vibrate$m; readonly attribute `DOMTimeStamp$I `timestamp$m; readonly attribute boolean `renotify$m; readonly attribute boolean `silent$m; readonly attribute boolean `requireInteraction$m; [`SameObject$] readonly attribute any `data$m; [`SameObject$] readonly attribute FrozenArray<`NotificationAction$I> `actions$m; void `close$m(); }; dictionary `NotificationOptions@I { `NotificationDirection$I `dir@mO = "auto"; DOMString `lang@mO = ""; DOMString `body@mO = ""; DOMString `tag@mO = ""; USVString `image@mO; USVString `icon@mO; USVString `badge@mO; `VibratePattern$I `vibrate@mO; `DOMTimeStamp$I `timestamp@mO; boolean `renotify@mO = false; boolean `silent@mO = false; boolean `requireInteraction@mO = false; any `data@mO = null; sequence<`NotificationAction$I> `actions@mO = []; }; enum `NotificationPermission@I { `default@l, `denied@l, `granted@l }; enum `NotificationDirection@I { `auto@l, `ltr@l, `rtl@l }; dictionary `NotificationAction@I { required DOMString `action@mA; required DOMString `title@mA; USVString `icon@mA; }; callback `NotificationPermissionCallback@I = void (`NotificationPermission$I %permission);
`Notification$I ~objは、ある`通知$を表現する: ◎ ↓
- `持続的$でない通知を表現する `Notification$I ~objは、 `Notification()$m 構築子を通して作成でき、通知ごとに 1 個に限られる。 ◎ A non-persistent notification is represented by one Notification object and can be created through Notification's constructor.
- `持続的$な通知を表現する `Notification$I ~objは、通知ごとに 0 個~以上いくつでもあり得る。 そのような`通知$は、 `showNotification()$m ~methodを通して作成できる。 【そのような~objたちは、 `getNotifications()$m を通して/ `~sw通知~eventを発火する$ときに作成される。】 ◎ A persistent notification is represented by zero or more Notification objects and can be created through the showNotification() method.
3.1. ~garbage収集
`Notification$I ~obj %N は、次を満たしている間は~garbage収集されては~MUST_NOT ⇒ [ %N が表現している`通知$ ~IN `通知~list$ ]~AND[ %N には次に挙げるいずれかの型の`~event~listener$が~~登録されている ] ⇒ `click^et, `show^et, `close^et, `error^et ◎ A Notification object must not be garbage collected while the list of notifications contains its corresponding notification and it has an event listener whose type is click, show, close, or error.
3.2. 構築子
`Notification(title, options)@m 構築子の被呼出時には、次を走らせ~MUST: ◎ The Notification(title, options) constructor, when invoked, must run these steps:
- ~IF[ `現在の大域~obj$は `ServiceWorkerGlobalScope$I ~objである ] ⇒ ~THROW `TypeError^E ◎ If the current global object is a ServiceWorkerGlobalScope object, then throw a TypeError exception.
- %通知 ~LET `通知を作成する$( %title, %options ) (例外投出あり) ◎ Let notification be the result of creating a notification given title and options. Rethrow any exceptions.
- %N ~LET %通知 を表現する新たな `Notification$I ~obj ◎ Let n be a new Notification object associated with notification.
-
この段は`並列的$に走らす: ◎ Run these steps in parallel:
- ~IF[ %通知 の`生成元$nT用の`許可$ ~NEQ `granted$l ] ⇒ 次を走らす`~taskを~queueする$ ⇒ %N に向けて,名前 `error^et の`~eventを発火する$ ◎ If permission for notification’s origin is not "granted", then queue a task to fire an event named error on n,\
-
~ELSE: ◎ and abort these steps.
- `通知を~fetchする$( %通知 ); ◎ Run the fetch steps for notification.
- `通知を示す$( %通知 ) ◎ Run the show steps for notification.
- ~RET %N ◎ Return n.
3.3. 静的~member
- `permission@m
- この静的~属性の取得子は、次を返さ~MUST ⇒ `入口~設定群~obj$の`生成元$enV用の`許可$ ◎ The static permission attribute’s getter must return permission for the entry settings object’s origin.
- 注記: 標準を編集する者は、上を複製するのは慎むこと。 同期的な許可は、同期的な入出力の様なものであり,不良な案である。 ◎ If you edit standards please refrain from copying the above. Synchronous permissions are like synchronous IO, a bad idea.
- `requestPermission(deprecatedCallback)@m
-
この静的~methodの被呼出時には、次を走らせ~MUST: ◎ The static requestPermission(deprecatedCallback) method, when invoked, must run these steps:
- %~promise ~LET 新たな~promise ◎ Let promise be a new promise.
-
この段は`並列的$に走らす: ◎ Run these steps in parallel:
- %入口~生成元 ~LET `入口~設定群~obj$の`生成元$enV ◎ ↓
- %許可 ~LET %入口~生成元 用の`許可$ ◎ Let permission be permission for entry settings object’s origin.
- ~IF[ %許可 ~EQ `default$l ] ⇒ [ %入口~生成元 用の通知は受容-可能かどうか ]を示して,利用者に尋ねる ⇒ %許可 ~SET 利用者からの可否に応じて ⇒ 可ならば `granted$l / 否ならば `denied$l ◎ If permission is "default", ask the user whether showing notifications for the entry settings object’s origin is acceptable. If it is, set permission to "granted", and "denied" otherwise.
-
次を走らす`~taskを~queueする$: ◎ Queue a task to run these steps:
- %入口~生成元 用の`許可$ ~SET %許可 ◎ Set permission for the entry settings object’s origin to permission.
- ~IF[ %deprecatedCallback ~NEQ ε ] ⇒ %deprecatedCallback( %許可 ) を呼出す ⇒ 例外が投出されたときは ⇒ その`例外を報告する$ ◎ If deprecatedCallback is given, invoke deprecatedCallback with permission as single argument. If this throws an exception, report the exception.
- %許可 で %~promise を解決する ◎ Fullfil promise with permission.
- ~RET %~promise ◎ Return promise.
- 通知は、[ 前もって利用者に何かを尋ねることに~~意味があるもの ]として知られている一つである。 他の~API用の仕様は、この~patternは利用せずに, より相応しい数多の代替 いずれかを使役するべきである。 ◎ Notifications are the one instance thus far where asking the user upfront makes sense. Specifications for other APIs should not use this pattern and instead employ one of the many more suitable alternatives.
- `maxActions@m
- この静的~属性の取得子は、次を返さ~MUST ⇒ ~supportされる`最大~動作~数$ ◎ The static maxActions attribute’s getter must return the maximum number of actions supported.
3.4. ~obj~member
次に挙げる`~event~handler$(および対応する`~event~handler~event型$)は、 `Notification$I ~objの属性として~supportされ~MUST: ◎ The following are the event handlers (and their corresponding event handler event types) that must be supported as attributes by the Notification object.
`~event~handler$ | `~event~handler~event型$ |
---|---|
`onclick@m | `click^et |
`onshow@m | `show^et |
`onerror@m | `error^et |
`onclose@m | `close^et |
【 以下の[ 属性/~method ]定義に現れる`通知$は、当の `Notification$I ~objが表現するそれを表す。 】
- `close()@m
- 被呼出時には、次を走らせ~MUST ⇒ `通知を閉じる$( `通知$ ) ◎ The close() method, when invoked, must run the close steps for the notification.
- `title@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`~title$nT ◎ The title attribute’s getter must return the notification’s title.
- `dir@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`方向$nT ◎ The dir attribute’s getter must return the notification’s direction.
- `lang@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`言語$nT ◎ The lang attribute’s getter must return the notification’s language.
- `body@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`本体$nT ◎ The body attribute’s getter must return the notification’s body.
- `tag@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`~tag$nT ◎ The tag attribute’s getter must return the notification’s tag.
- `image@m
- 取得子は、`通知$の`画像~URL$nT %url に応じて,次を返さ~MUST ⇒# ε ならば空~文字列 / ~ELSE_ `~URLを直列化する$( %url ) ◎ The image attribute’s getter must return the notification’s image URL, serialized, and the empty string if there is no notification’s image URL otherwise.
- `icon@m
- 取得子は、`通知$の`~icon~URL$nT %url に応じて,次を返さ~MUST ⇒# ε ならば空~文字列 / ~ELSE_ `~URLを直列化する$( %url ) ◎ The icon attribute’s getter must return the notification’s icon URL, serialized, and the empty string if there is no notification’s icon URL otherwise.
- `badge@m
- 取得子は、`通知$の`~badge~URL$nT %url に応じて,次を返さ~MUST ⇒# ε ならば空~文字列 / ~ELSE_ `~URLを直列化する$( %url ) ◎ The badge attribute’s getter must return the notification’s badge URL, serialized, and the empty string if there is no notification’s badge URL otherwise.
- `vibrate@m
- 取得子は、`通知$の`振動~pattern$nT %~pattern に応じて,次を返さ~MUST ⇒# ε ならば空~list / ~ELSE_ %~pattern ◎ The vibrate attribute’s getter must return the notification’s vibration pattern, if any, and the empty list otherwise.
- `timestamp@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`時刻印$nT ◎ The timestamp attribute’s getter must return the notification’s timestamp.
- `renotify@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`再通知-選好~flag$nT ◎ The renotify attribute’s getter must return the notification’s renotify preference flag.
- `silent@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`静音~選好~flag$nT ◎ The silent attribute’s getter must return the notification’s silent preference flag.
- `requireInteraction@m
- 取得子は、次を返さ~MUST ⇒ `通知$の`対話~選好を要求する~flag$nT ◎ The requireInteraction attribute’s getter must return the notification’s require interaction preference flag.
- `data@m
- 取得子は、次を走らせた結果 — ただし,例外が投出されたときは ~NULL — を返さ~MUST ⇒ `StructuredDeserialize$A( `通知$の`~data$nT, 此れに`関連する~Realm$ ) ◎ The data attribute’s getter must return StructuredDeserialize(notification’s data, context object’s relevant Realm). If this throws an exception, then return null.
- `actions@m
-
取得子は、次を走らせた結果を返さ~MUST: ◎ The actions attribute’s getter must return the result of the following steps:
-
%動作~list ~LET 新たな空の
sequence<`NotificationAction$I>
型~値 ◎ Let frozenActions be an empty list of type NotificationAction. -
`通知$の`動作~list$nT内の ~EACH( %~entry ) に対し: ◎ For each entry in the notification’s list of actions, perform the following steps:
- %動作 ~LET 次のようにされた新たな `NotificationAction$I 型~値 ⇒# `action$mA ~SET %~entry の`名前$acT, `title$mA ~SET %~entry の`~title$acT, `icon$mA ~SET %~entry の`~icon~URL$acT ◎ Let action be a new NotificationAction. ◎ Set action’s action to entry’s name. ◎ Set action’s title to entry’s title. ◎ Set action’s icon to entry’s icon URL.
- %動作 上で `Object.freeze$c を~callする — これは、~scriptによる不用意な変異を防止する。 ◎ Call Object.freeze on action, to prevent accidental mutation by scripts.
- %動作~list に %動作 を付加する ◎ Append action to frozenActions.
- `凍結~配列を作成する$( %動作~list ) ◎ Create a frozen array from frozenActions.
-
%動作~list ~LET 新たな空の
3.5. 例
3.5.1. 頁からの~eventの利用-法
`持続的$でない通知を表現する `Notification$I ~objには、その存続中に~eventが配送される — 開発者は、それを利用して,自身が欲する挙動を生成できる。 ◎ Non-persistent Notification objects dispatch events during their lifecycle, which developers can use to generate desired behaviors.
`click^et ~eventは、利用者が通知を作動化したときに配送される。 ◎ The click event dispatches when the user activates a notification.
var %not = new Notification("Gebrünn Gebrünn by Paul Kalkbrenner", { icon: "newsong.svg", tag: "song" }); %not.onclick = function() { displaySong(this); };
3.5.2. ~swからの動作の利用-法
`持続的$な通知は、 `ServiceWorkerGlobalScope$I に向けて `notificationclick^et ~eventを発火する。 ◎ Persistent notifications fire notificationclick events on the ServiceWorkerGlobalScope.
次の例の~swは、 1 個の “~archive” `動作$nTを伴うある通知を示して、[ 利用者が、~websiteを開かずに,この通知から この共通的な~taskを遂行する ]ことも可能にする(例えば,通知~platformは、通知~上に~buttonを示すかもしれない)。 利用者は、通知の本体を作動化して,その受信箱を開くこともできる。 ◎ Here a service worker shows a notification with a single "Archive" action, allowing users to perform this common task from the notification without having to open the website (for example the notification platform might show a button on the notification). The user can also activate the main body of the notification to open their inbox.
self.registration.showNotification("甲さんから新たな~mailです", { actions: [{action: 'archive', title: "~archive"}] }); self.addEventListener('notificationclick', function(%event) { %event.notification.close(); if (%event.action === 'archive') { silentlyArchiveEmail(); } else { clients.openWindow("/受信箱"); } }, false);
3.5.4. 単独の~instance用の `tag^mO ~memberの利用-法
`tag$mO ~memberは、~appの単独の~instanceからも利用できる — 自身の通知を,状態~変化に伴い可能な限り最新に保つために。 ◎ The tag member can also be used by a single instance of an application to keep its notifications as current as possible as state changes.
例えば、甲さんが~chat~appを利用していて,相手の乙さんは甲が “遊休中”† の間に複数の~messageを送信した場合、~appは,[ 甲が各~messageに対する~desktop通知をいちいち見ない ]ことを選好することもできる。 【†~appがどうやって “遊休中” を検出するかは、~appに委ねられる。】 ◎ For example, if Alice is using a chat application with Bob, and Bob sends multiple messages while Alice is idle, the application may prefer that Alice not see a desktop notification for each message.
/* 乙からの "こんにちは" */ new Notification("乙さん: こんにちは", { tag: 'chat_乙' }); /* 乙からの "今日の午後は~~空いてますか?" */ new Notification("乙さん: こんにちは / 今日の午後は~~空いてますか?", { tag: 'chat_乙' });
この状況における結果は、1 個の通知になる。 2 個目の通知は、同じ~tagが伴われた最初の通知を置換する。 通知を~queueする(~queueされた順に通知する)~platformにおいては、~tagを用いれば,~queue内での通知の位置も保守-可能になる。 最新の通知を最初に示すような~platformにおいては、 `close()$m ~methodを用いて同様の結果を達成することもできる。 ◎ The result of this situation is a single notification; the second one replaces the first having the same tag. In a platform that queues notifications (first-in-first-out), using the tag allows the notification to also maintain its position in the queue. Platforms where the newest notifications are shown first, a similar result could be achieved using the close() method.
4. ~sw~API
dictionary `GetNotificationOptions@I { DOMString `tag@mGO = ""; }; partial interface `ServiceWorkerRegistration$I { Promise<void> `showNotification$m(DOMString %title, optional `NotificationOptions$I %options); Promise<sequence<`Notification$I>> `getNotifications$m(optional `GetNotificationOptions$I %filter); }; [Constructor(DOMString %type, `NotificationEventInit$I %eventInitDict), `Exposed$=ServiceWorker] interface `NotificationEvent@I : `ExtendableEvent$I { readonly attribute `Notification$I `notification@mE; readonly attribute DOMString `action@mE; }; dictionary `NotificationEventInit@I : `ExtendableEventInit$I { required `Notification$I `notification@mNI; DOMString `action@mNI = ""; }; partial interface `ServiceWorkerGlobalScope$I { attribute `EventHandler$I `onnotificationclick$m; attribute `EventHandler$I `onnotificationclose$m; };
`showNotification(title, options)@m ~method, 被呼出時には、次を走らせ~MUST: ◎ The showNotification(title, options) method, when invoked, must run these steps:
- %~promise ~LET 新たな~promise ◎ Let promise be a new promise.
- ~IF[ 此れにて`作動中の~worker$ ~EQ ~NULL ] ⇒# `TypeError^E 例外で %~promise を却下する; ~RET %~promise ◎ If the context object’s active worker is null, then reject promise with a TypeError exception and return promise.
- %~sw登録 ~LET 此れ ◎ Let serviceWorkerRegistration be the context object.
- %通知 ~LET `通知を作成する$( %title, %options, %~sw登録 ) ⇒ 例外が投出されたときは ⇒# その例外で %~promise を却下する; ~RET %~promise ◎ Let notification be the result of creating a notification given title, options, and serviceWorkerRegistration. If this threw an exception, reject promise with that exception and return promise.
-
この段は`並列的$に走らす: ◎ Run these steps in parallel:
- ~IF[ %通知 の`生成元$nT用の`許可$ ~NEQ `granted$l ] ⇒ `TypeError^E 例外で %~promise を却下する ◎ If permission for notification’s origin is not "granted", then reject promise with a TypeError exception\
-
~ELSE: ◎ , and abort these steps.
- `通知を~fetchする$( %通知 ) ◎ Run the fetch steps for notification.
- `通知を示す$( %通知 ) ◎ Run the show steps for notification.
- `undefined^jv で %~promise を解決する ◎ Resolve promise with undefined.
- ~RET %~promise ◎ Return promise.
`getNotifications(filter)@m ~method, 被呼出時には、次を走らせ~MUST: ◎ The getNotifications(filter) method, when invoked, must run these steps:
- %~promise ~LET 新たな~promise ◎ Let promise be a new promise.
-
この段は`並列的$に走らす: ◎ Run these steps in parallel:
- %~tag ~LET %filter の `tag^c ◎ Let tag be filter’s tag.
- %~obj配列 ~LET 新たな~JS配列 ◎ ↓
-
`通知~list$内の~EACH( `通知$ %通知 ) に対し,作成~順序で:
-
~IF[ ( %通知 の`生成元$nT, `入口~設定群~obj$の`生成元$enV ) は`同一生成元$でない† ]~OR[ %通知 の`~sw登録$nT ~NEQ 此れ ] ⇒ ~CONTINUE
【† “同一生成元でない” は訳者による推定。原文には単に “is not” としか記されていない。】 - ~IF[ %~tag ~NEQ 空~文字列 ]~AND[ %通知 の`~tag$nT ~NEQ %~tag ] ⇒ ~CONTINUE
- %~obj配列 に[ %通知 を表現している新たな `Notification$I ~obj ]を付加する
-
- %~obj配列 で %~promise を解決する ◎ Resolve promise with objects.
- ~RET %~promise ◎ Return promise.
注記: この~methodは、 0 個~以上の新たな `Notification$I ~objを返す — それらが表現する下層の`通知$には、すでに存在する `Notification$I ~objのそれと同じものもあるかもしれない。 ◎ This method returns zero or more new Notification objects which might represent the same underlying notification of Notification objects already in existence.
`~sw通知~eventを発火する@ ときは、所与の ( %~obj, %~event名, %通知, %動作 【省略時は空~文字列?】 ) に対し、 %~obj に向けて,名前 %~event名 の`~eventを発火する$ — `NotificationEvent$I ~interfaceを利用し,次のように初期化して ⇒# `notification$mE 属性 ~SET %通知 を表現している新たな `Notification$I ~obj, `action$mE 属性 ~SET %動作 ◎ To fire a service worker notification event named e given notification and action, fire an event named e, using NotificationEvent, with the notification attribute initialized to a new Notification object representing notification and the action attribute initialized to action.
- `notification$mE
- 取得子は、初期化-時の値を返さ~MUST ◎ The notification attribute’s getter must return the value it was initialized to.
- `action$mE
- 取得子は、初期化-時の値を返さ~MUST ◎ The action attribute’s getter must return the value it was initialized to.
次に挙げる`~event~handler$(および対応する`~event~handler~event型$)は、 `ServiceWorkerGlobalScope$I ~objの属性として~supportされ~MUST: ◎ The following is the event handler (and its corresponding event handler event type) that must be supported as attribute by the ServiceWorkerGlobalScope object:
`~event~handler$ | `~event~handler~event型$ |
---|---|
`onnotificationclick@m | `notificationclick^et |
`onnotificationclose@m | `notificationclose^et |
謝辞
Thanks to Addison Phillips, Aharon (Vladimir) Lanin, Alex Russell, Anssi Kostiainen, Arkadiusz Michalski, Boris Zbarsky, David Håsäther, Doug Turner, Drew Wilson, Ehsan Akhgari, Frederick Hirsch, Ian Hickson, Jake Archibald, James Graham, John Mellor, Jon Lee, Jonas Sicking, Michael Cooper, Michael Henretty, Michael™ Smith, Michael van Ouwerkerk, Nicolás Satragno, Olli Pettay, Peter Beverloo, Philip Jägenstedt, Reuben Morais, Rich Tibbett, Robert Bindar, 박상현 (Sanghyun Park), Simon Pieters, Theresa O’Connor, timeless, and triple-underscore for being awesome.
This standard is written by Anne van Kesteren (Mozilla, annevk@annevk.nl). An earlier iteration was written by John Gregg (Google, johnnyg@google.com).
Copyright © 2018 WHATWG (Apple, Google, Mozilla, Microsoft). This work is licensed under a Creative Commons Attribution 4.0 International License.