요약
웹 알림은 엔드 유저 알림을 위한 API를 제공합니다.
알림은 이메일 같은, 유저 웹페이지 콘텍스트 밖에 발생시키는 걸 허용합니다.
이 문서의 상태
이 섹션은 이 문서를 공개했을 때 상태에 대해 설명합니다.
다른 문서가 이 문서를 덮어쓸 가능성이 있으니 주의하시길 바랍니다.
이 문서 및 W3C에서 공개한 다른 문서의 최신 버전은
W3C technical reports index at http://www.w3.org/TR/에서
확인 가능합니다.
이 문서는 웹 알림의 W3C 권고안입니다.
이 문서는 W3C 멤버, 소프트웨어 개발자, 그리고 다른 W3C 그룹 및 관계자들이 평가를 진행하여, 디렉터에 의해 W3C 권고안으로 발표했습니다.
이 문서는 안정적이며, 참고자료로 사용하거나 다른 문서에서 인용해도 좋습니다.
스펙 문서의 권고를 통해 W3C가 하는 역할은 스펙 문서에 관심을 모으고 다방면으로 퍼뜨리는 일입니다.
이를 통해 웹의 기능과 상호운용성 향상을 기대할 수 있습니다.
W3C 웹 알림 워킹 그룹은 이 스펙문서를 W3C 권고안으로 발행하는데 책임이 있는 W3C 워킹 그룹입니다.
이 문서에 대한 코멘트를 남기고 싶다면
public-web-notification@w3.org
(subscribe, archive)으로 메일을 보내주시길 바랍니다.
W3C는 [DOM4]나 [WEBIDL] 문서의 권고안 프로세스 진행으로 인한 변화에 따라,
이 권고안에서 정의하는 기술적인 부분에 영향을 받지 않을것이라 기대하고 있습니다.
이 스펙문서에 대한
test suite 및
구현 보고서를 참고하시길 바랍니다.
https://notifications.spec.whatwg.org/에서도
웹에서 사용하는 알림에 대한 스펙 문서를 제공합니다.
최근 주목하고 있는 작업은 서비스 워커와 알림 통합 및 다른 새로운 특징들입니다.
위 스펙 문서에서는 이 스펙문서에는 존재하는 onshow 및 onclose 이벤트를 사용 사례가 부족한 이론적 근거를 이유로 제거하였습니다.
이 문서는 2004년 2월 6일 W3C 특허 정책을 따르는 그룹에서 작성하였습니다.
W3C는 그룹의 성과물에 관련하여 모든 공개 특허 공개 리스트를 관리합니다.
여기에는 특허 공개에 대한 지시사항도 포함합니다.
특허에 대해서 충분한 지식이 있는 사람이, 스펙 문서의 Essential Claim(s)에 인정된다고 파악되는 경우, W3C 특허 정책 제 6장에 의거하여 정보를 공개해야 할 필요가 있습니다.
이 문서는 2015년 9월 1일 W3C 프로세스 문서에 따릅니다.
목차
1 소개
이 스펙 문서는 유저 웹페이지의 콘텍스트 바깥쪽 경고를 위한 알림을 나타내는 API를 제공합니다.
이 스펙문서에서 "desktop" 상 알림 표시를 참고할 때, 일반적으로는 웹페이지의 바깥 정적 디스플레이 영역을 참고합니다.
하지만 여러가지 형태를 취할 수 있습니다:
- 유저 디스플레이의 코너
- 유저 에이전트의 크롬 영역
- 모바일 기기의 "home" 화면
유저 에이전트에서 어떻게 알림을 보여줄지에 대해서는 명확히 정의되어있지 않습니다.
가장 좋은 표현방법은 유저 에이전트가 동작하는 디바이스에 의존하는 것입니다.
API는 표시 옵션에 대하여 유연하게 디자인하고 있습니다.
이 스펙문서는 현존 알림 플랫폼에 가능한한 많이 호환하도록 설계하였으나, 플랫폼에 독립적입니다.
일반적인 플랫폼에서 똑같은 기능을 제공하지 않을 때, 이 스펙은 이벤트가 표시 될지 않을지를 보장합니다.
특히, 여기에서 정의하는 알림은 콘텐츠에 텍스트와 아이콘을 포함할 수 있습니다.
일반적으로, 알림을 위한 이벤트 모델은 최선형입니다.
Notification 객체가 click 이벤트를 제공하는 동안,
어플리케이션은 이벤트를 수신하여 기능을 향상시킬 수 있지만,
그 기능을 제공하지 않는 경우, 플랫폼에서 알림을 제공할 수 없습니다.
이 스펙문서 내에서 예제, 노트, 작성 가이드라인, 다이어그램 및 명시적으로 '이 섹션은 표준에 준하는 내용이 아닙니다'라 표기된 내용은 표준에 준하는 내용이 아닙니다. 그 외는 모두 표준에 준하는 내용입니다.
이 스펙 문서 내 키워드 "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", "OPTIONAL"는 RFC 2119에 기술되어있는대로 해석합니다.
가독성을 위해, 이 스펙문서에서 이 키워드들을 모두 대문자로 표기하지는 않습니다.
2.1 보안
알림은 유저가 알림을 원한다고 알린 때에만 보여져야 합니다.
유저가 부정적인 경험을 생성하지 않기 위함입니다.
3 용어
이 스펙문서에서 사용하는 대부분의 용어는 DOM, HTML, IDL, URL에서 따왔습니다.
[DOM4]
[HTML5]
[WEBIDL]
[URL]
4 모델
알림은 무언가 일어나는 웹페이지 콘텍스트 외부에 이메일 전송같은 경고를 허용합니다.
각 알림은
title, direction,
language, origin을 가집니다.
각 알림은
body, tag, icon URL,
icon image 관련 정보를 가질 수 있습니다.
엔드 유저가 접근 불가능한 아이콘, 소리, 진동을 통한 정보 전달을 권장하지 않습니다.
WCAG에서 더 자세한 내용을 확인할 수 있습니다.
4.1 Direction
이 섹션은 HTML의 렌더링 섹션에서 사용하는 용어를 동일한 의미로 사용하고 있습니다. [HTML5]
유저 에이전트는 알림의 title과 body의
텍스트 유니코드 시맨틱을 존중하리라 기대하고 있습니다.
보여질 때 각 문자열 독립 세트가 쌍방향 알고리즘 규칙의 P1, P2, P3을 포함하여 정의되며, U+000A 라인 피드 (LF) 문자의 줄바꿈 행동을 지원하는 하나 혹은 그 이상의 쌍방향 알고리즘으로 취급될 거라 예상하고 있습니다.
title, body의 각 문장,
알림의 direction은
P2와 P3가 "auto" 외의 값을 갖는 경우 상위 레벨로 룰을 뒤짚어 쓰는 걸 제공합니다. [BIDI]
4.2 언어
알림의
언어는 알림의
title과 body를 위한 기본 언어를 정의합니다.
값은 올바른 BCP 47 언어 태그거나 빈 문자열이어야 합니다.
빈 문자열은 기본 언어 unknown으로 표시됩니다. [LANG]
4.3 권한
알림은 유저 (혹은 유저에이전트)에서 권한을
인정했을 때만 화면에 보일 수 있습니다. 알림 표시 권한을 위한 origin 값에 아래 세 문자열 중 하나를 넣을 수 있습니다.
- "
default"
이 값은 "denied"와 동일하지만, 아직까지 사용자가 명시적으로 선택하지 않은 상태입니다.
- "
denied"
이 값은 유저가 알림을 원하지 않는 상태입니다.
- "
granted"
이 값은 알림이 화면상에 나타날 수 있는 상태입니다.
"default"와 "granted"의 의미가 같지 않습니다.
이 경우, "granted"는 어플리케이션에서 권한을 물어보고 값을 반환받은 상태입니다.
4.4 알림 목록
유저에이전트는 반드시 펜딩 알림 목록과 액티브 알림 목록을 유지해야합니다.
4.5 알림 나타내기
알림을 나타내는 순서는 다음과 같습니다:
알림의 권한을 위한
origin이 "granted"가 아니며,
모든 진행 중 알림의 icon URL fetch를 취소하고,
notification에서 error
이벤트 발생을
태스크에 축적을 진행하고,
이 단계를 없앱니다.
펜딩 알림 목록및 액티브 알림 목록 안에 알림이 있다면,
tag가 notification의 tag와 동일하고 origin이
notification의 origin과 동일합니다.
그 알림과 notification를 위한 replace steps를 실행하고, 이 단계를 없앱니다.
만약 디바이스가 현재 알림 갯수 제한 없이 즉시 알림을 보여주는 걸 허용한다면,
display steps을 작동하고 이 단계를 없앱니다.
만약 디바이스에 현재 알림 갯수 제한이 있다면, 즉시 기본으로 지원하는 대기열 알림 플랫폼에 콜하거나
펜딩 알림 목록에 notification을 넣습니다.
4.6 알림 활성화
알림 notification이 유저에 의해 활성화되었을 때,
알림 플랫폼 지원 활성화 아래에 있으며, 유저 에이전트는 반드시 각 Notification 객체가 notification를 나타내야 하며, Notification 객체에서 click 이벤트 발생을 태스크 큐에 쌓아야 합니다.
웹 플랫폼 전반에 걸쳐 "active"가 "click"으로 잘못 이름지어졌습니다.
유저에이전트는 알림 관련 브라우징 컨텍스트에 집충하는 의미로 click 이벤트 리스너에서
window.focus()를 같이 작동시키는 게 좋습니다.
4.7 알림 닫기
알림을 닫을 때,
유저나 알림 플랫폼 아래에 있을 때, 닫기 스텝이 반드시 동작해야합니다.
notification에서 제공하는 닫기 스텝은 다음과같습니다:
만약 notification이
펜딩 알림 목록이나 액티브 알림 목록에 있는 경우 이 단계를 종료합니다.
펜딩 알림 목록이나
액티브 알림 목록에서 notification을
Queue a task에서 제거하고,
notification에서 close 이벤트를 발생시킵니다.
4.8 펜딩 알림
펜딩 알림 목록이 비어있지 않을 때,
유저 에이전트는 반드시 디바이스상 알림 가능 공간의 변화를 모니터링하고 기다려야합니다.
새로운 알림을 보여줄 수 있는
디바이스상 사용가능 디스플레이 공간이 변할 때,
이전 알림은 사라지고, 유저에이전트는 펜딩 알림 목록 안
첫번째 알림에
디스플레이 스텝을 실행해야 하고,
그를 펜딩 알림 목록에서 제거해야 합니다.
4.9 알림 보이기
notification에서 제공하는 디스플레이 스텝은 다음과 같습니다:
-
알림 플랫폼이 아이콘을 지원하거나,
notification의 icon URL이 세트되어있으나,
아직 fetched되지 않은 경우
이를 fetch받고, 리소스 전체를 다운로드 받습니다.
한 번 fetching이 끝나고
이미지 포맷을 지원한다면
notification의 icon image를 디코드한 리소스로 설정합니다.
-
아래 단계대로 Queue a task를 실행합니다.:
디바이스 상에 notification을 표시합니다.
(예를 들면, 적절한 알림 플랫폼 API 호출을 따라 생성합니다)
만약 표시를 실패하면, (예를 들어, 알림 플랫폼이 error를 리턴한 경우),
notification에서 error 이벤트를 발생시키고 이 스텝을 제거합니다.
액티브 알림 목록에 notification을 넣습니다.
notification에서 show 이벤트를 발생시킵니다..
4.10 알림 변경
old 알림을
new 알림으로
바꾸는 변경 스텝은 아래와 같습니다:
-
만약 알림 플랫폼이 아이콘을 지원하면,
new 알림의 icon URL이 설정되어있으나,
아직 fetched되지 않은 경우,
이를 fetch받고, 리소스 전체를 다운로드 받습니다.
한 번 fetching이 끝나고
이미지 포맷을 지원한다면
new 알림의 icon image를 디코드한 리소스로 설정합니다.
If old 알림은
펜딩 알림 목록에 넣고,
old 알림과 함께 new 알림을 변환하는 작업을 queue a task에 넣고, 같은 포지션상에서,
펜딩 알림 목록 안에서 old 알림에서는 close 이벤트를 발생시킵니다.
-
그 외 경우
old 알림과 함께 new 알림을 변환하는 작업을 queue a task에 넣고, 같은 포지션상에서, 액티브 알림 목록 안에서,
old 알림에서는 close 이벤트를 발생시키고, new 알림에서는 show 이벤트를 발생시킵니다.
만약 알림 플랫폼이 변경을 지원하지 않는다면,
이 요구사항은 old 알림에서 close steps을 실행시킨 뒤,
new 알림에서 display steps를 싱행시킵니다.
알림 플랫폼은 기본 변경을 지원하기를 강하게 권장합니다. 이 동작이 훨씬 좋습니다.
5 API
알림은
Notification 객체로 표현하며
그 constructor로 제작 가능합니다.
[Constructor(DOMString title, optional NotificationOptions options)]
interface Notification : EventTarget {
static readonly attribute NotificationPermission permission;
static void requestPermission(optional NotificationPermissionCallback callback);
attribute EventHandler onclick;
attribute EventHandler onshow;
attribute EventHandler onerror;
attribute EventHandler onclose;
readonly attribute DOMString title;
readonly attribute NotificationDirection dir;
readonly attribute DOMString lang;
readonly attribute DOMString body;
readonly attribute DOMString tag;
readonly attribute DOMString icon;
void close();
};
dictionary NotificationOptions {
NotificationDirection dir = "auto";
DOMString lang = "";
DOMString body;
DOMString tag;
DOMString icon;
};
enum NotificationPermission {
"default",
"denied",
"granted"
};
callback NotificationPermissionCallback = void (NotificationPermission permission);
enum NotificationDirection {
"auto",
"ltr",
"rtl"
};
Notification(title, options)
constructor는 아래 스텝대로 동작해야만 합니다.
Notification 객체에 의해 보여질
새 알림을 notification에 지정합니다.
notification의 title을 title로 지정합니다.
notification의 direction을
options의 dir로 지정합니다.
options의 lang이 올바른 BCP 47 언어 태그거나 빈 문자열이라면,
notification의 language를
options의 lang으로 지정합니다.
그 외의 경우는 빈 문자열로 지정합니다. [LANG]
notifications의 origin을 현재
origin으로 지정합니다.
options의 body가 현재 있는 경우,
notification의 body를 body로 지정합니다.
options의 tag가 현재 있는 경우,
notification의 tag를 tag로 지정합니다.
options의 icon이 현재 있는 경우
entry settings object에서 정의하는
API base URL를 사용하는
icon을 parse하고,
만약 장애를 반환하지 않으면,
notification의 icon URL을 반환 값으로 지정합니다.
notification을 반환하고, 아래 스텝을 비동기식으로 계속해서 실행합니다.
만약 icon URL이 지정되어있고 알림 플랫폼이 아이콘을 지원한다면,
유저 에이전트는 이 시점에 notification의 icon URL fetching을 시작할 수도 있습니다.
notification의 표시 스텝을 실행합니다.
정적
permission
속성은 반드시 permission을 반환해야 합니다.
정적
requestPermission(callback)
메서드는 반드시 아래 스텝대로 동작해야합니다.
반환하되, 아래 스텝을 비동기식으로 실행합니다.
permission을 permission으로 지정합니다.
permission이 "default"라면,
현재 origin에서 알림을 보여주는 걸 허용할지 유저에게 확인합니다.
이 경우 permission은 "granted"로 지정되거나, 그 외의 경우 "denied"로 지정됩니다.
permission을 permission으로 설정하는
태스크 대기행렬에 두고,
callback이 주어진 경우 단일 인수로 permission을 가진 callback을 호출합니다.
플랫폼 알림 설계 상 하나의 인스턴스를 유저에게 허용할지 물어봅니다.
다른 API 스펙에서는 이러한 패턴을 사용하지 않아야하며, 그 대신에
다른 적합 대안책 중 하나를 채택하는 게 좋습니다.
아래 내용은 Notification 객체에서 반드시 지원해야하는 속성을 가진 event handlers에 관한 내용입니다.
(그리고 이는 event handler event types와 상응합니다)
close() 메서드는
알림의 close steps을 실행해야합니다.
title 속성은 반드시
알림의 title을 반환해야합니다.
dir 속성은 반드시
알림의 direction을 반환해야합니다.
lang 속성은 반드시
알림의 language를 반환해야합니다.
body 속성은 반드시
알림의 body를 반환하고 그 외의 경우 빈 문자열을 반환해야합니다.
tag 속성은 반드시
알림의 tag를 반환하거나 태그를 가지지 않은 경우 빈 문자열을 반환해야합니다.
icon 속성은 반드시
알림의 icon URL,
serialized, 그 외의 경우 빈 문자열을 반환해야합니다.
6 예제
6.1 이벤트 사용하기
Notification 객체는 라이프 사이클동안
개발자들에게 원하는 동작을 생성할 때 사용할 수 있는 이벤트를 감지할 수 있습니다.
show 이벤트는
알림이 유저에게 보였을 때 감지됩니다.
—
이는 알림이 제한된 일부 디스플레이 공간과 큐같은 경우 알림 생성 이후 약간 시간이 지난 후 시점일 수 있습니다.
아래 예제에서 이벤트는 알림이 보여질 지에 상관없이, 알림이 15초간 보여질 것을 보장하기 위해 사용합니다.
var notification = new Notification("New Email Received", { icon: "mail.png" })
notification.onshow = function() { setTimeout(notification.close, 15000) }
유저에 의해 사라지는 경우 알림은 close 이벤트를 감지합니다.
개발자들은 알림이 승인될 때 이 이벤트를 성능 액션을 위해 사용할 수 있습니다.
아래 예제에서, 미팅 리마인더 알림이 승인되었을 때,
어플리케이션은 리마인더의 다른 폼을 숨길것입니다.
var notification = new Notification("Meeting about to begin", { icon: "calendar.gif", body: "Room 101" })
notification.onclose = function(event) { cancelReminders(event) }
유저가 여러 브라우저 탭에서 메일 어플리케이션을 실행할 때와 같이,
웹 어플리케이션은 흔히 여러개의 인스턴스를 동시에 작동합니다.
데스크탑에서 리소스를 공유할 때부터,
알림 API는 이런 인스턴스들을 tag 멤버를 사용해 쉽게 결합하는 방법을 제공합니다.
동일한 개념을 나타내는 알림 이벤트는 동일한 방식으로 태그할 수 있으며,
양쪽 다 나타낼 때, 유저는 하나의 알림만 받을 것입니다.
Instance 1 | Instance 2
|
// 인스턴스에서 새로운 메일을 나타냅니다. |
new Notification("New mail from John Doe", |
{ tag: 'message1' }); |
|
| // 약간 지나, 이 인스턴스는 새로운 메일이
| // 있음을 알릴 것입니다.
| new Notification("New mail from John Doe",
| { tag: 'message1' });
이 상태의 결과로, 유저 에이전트가 이 알고리즘을 따른다면, 하나의 알림 "New mail from John Doe"이 노출될 것입니다.
6.3 단일 인스턴스를 위한 tag 멤버 사용하기
tag 멤버는 어플리케이션의 단일 인스턴스에서도 상태 변화에 알림을 가능한한 현재상태를 유지하기 위해 사용할 수 있습니다.
예를 들어, 철수가 영희와 함께 채팅 어플리케이션을 사용하고 있을 때,
철수가 영희에게 여러개의 메시지를 전송한 경우,
어플리케이션에서 영희에게 각 메시지별 데스크탑 알림을 노출하고 싶어하지 않을 것입니다.
// 철수가 "안녕"이라고 말합니다.
new Notification("철수: 안녕", { tag: 'chat_Cheolsu' });
// 철수가 "영희야 오늘밤 여유롭니?"라고 말합니다.
new Notification("철수: 안녕 / 오늘 밤 여유롭니?", { tag: 'chat_Cheolsu' });
이 상황의 결과는 단일 알림을 노출할 것입니다.
두번째 알림은 첫번째 알림이 같은 태그를 가지고 있기 때문에 변경될것입니다.
알림 큐(first-in-first-out) 플랫폼에서, 태그는 알림이 대기행렬 안 포지션을 유지하는 것도 허용합니다.
새로운 알림이 첫번째로 보여질 때 플랫폼은,
close() 메서드를
사용하여 아카이브 하는 것과 비슷한 결과를 보여줍니다.
참고문서
- [BIDI]
- Unicode Bidirectional Algorithm, Mark Davis. Unicode Consortium.
- [DOM4]
- DOM, Anne van Kesteren, Aryeh Gregor, Ms2ger et al.. W3C.
- [HTML5]
- HTML5, Robin Berjon, Steve Faulkner, Travis Leithead et al.. W3C.
- [LANG]
- Tags for Identifying Languages; Matching of Language Tags, Addison Phillips and Mark Davis. IETF.
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels, Scott Bradner. IETF.
- [URL]
- URL, Eric Arvidsson, Michael[tm] Smith. W3C.
- [WEBIDL]
- Web IDL, Cameron McCormack. W3C.
감사의 말
Thanks to
Aharon (Vladimir) Lanin,
Alex Russell,
David Håsäther,
Doug Turner,
Drew Wilson,
Jake Archibald,
Edward O'Connor,
Frederick Hirsch,
Ian Hickson,
James Graham,
Jon Lee,
Jonas Sicking,
Josh Soref,
Michael Cooper,
Michael Henretty,
Olli Pettay, and
Simon Pieters
for being awesome.
Special thanks to Anne van Kesteren for his continuing work on the
WHATWG's Notifications
API Standard.