웹 애플리케이션 매니페스트

W3C 워킹 드래프트

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2025/WD-appmanifest-20251127/
최신 공개 버전:
https://www.w3.org/TR/appmanifest/
최신 에디터 드래프트:
https://w3c.github.io/manifest/
히스토리:
https://www.w3.org/standards/history/appmanifest/
커밋 히스토리
에디터:
Marcos Cáceres (Apple)
Kenneth Rohde Christiansen (Intel Corporation)
Diego González (Microsoft Corporation)
Daniel Murphy (Google Inc.)
Christian Liebel (Thinktecture AG)
이전 에디터:
Matt Giuca (Google Inc.) -
Anssi Kostiainen (Intel Corporation) -
Aaron Gustafson (Microsoft Corporation) -
Mounir Lamouri (Google Inc.)
Rob Dolin (Microsoft Corporation)
Kenneth Rohde Christiansen (Intel Corporation) -
피드백:
GitHub w3c/manifest (풀 리퀘스트, 새 이슈, 오픈 이슈)
브라우저 지원:
caniuse.com

Copyright © 2025 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.

요약

이 명세서는 개발자가 웹 애플리케이션과 관련된 메타데이터를 중앙에서 관리할 수 있도록 하는 JSON 기반 파일 형식을 정의합니다. 이 메타데이터에는 웹 애플리케이션의 이름, 아이콘에 대한 링크, 사용자가 웹 애플리케이션을 실행할 때 열릴 기본 URL 등이 포함됩니다. 매니페스트는 또한 개발자가 웹 애플리케이션의 기본 화면 방향을 선언할 수 있게 하며, 애플리케이션의 표시 모드(예: 전체 화면)도 설정할 수 있습니다. 추가로, 매니페스트를 통해 개발자가 웹 애플리케이션을 특정 URL에 "스코프"로 지정할 수 있습니다. 이는 매니페스트가 적용되는 URL을 제한하며, 다른 애플리케이션에서 웹 애플리케이션으로 "딥 링크"할 수 있는 방법을 제공합니다.

이러한 메타데이터를 사용하면, 사용자 에이전트는 개발자에게 네이티브 애플리케이션과 비슷한 사용자 경험을 만들 수 있는 수단을 제공합니다.

문서 상태

이 섹션은 문서가 공개될 당시의 상태를 설명합니다. 현재 W3C 출판물 목록과 이 기술 보고서의 최신 개정본은 W3C 표준 및 드래프트 인덱스에서 확인할 수 있습니다.

경고

이 문서는 웹 애플리케이션 워킹 그룹에서 Recommendation 트랙을 따라 작업 초안으로 공개되었습니다.

작업 초안으로 공개되었다고 해서 W3C 및 회원들의 승인이나 지지를 의미하지는 않습니다.

이 문서는 초안이며, 언제든지 다른 문서에 의해 업데이트, 대체 또는 폐기될 수 있습니다. 진행 중인 작업 외에 이 문서를 인용하는 것은 부적절합니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성되었습니다. W3C는 공개 특허 공개 목록을 유지 관리합니다. 이 목록은 그룹의 결과물과 관련된 모든 특허 공개를 포함하며, 특허 공개 방법에 대한 안내도 포함되어 있습니다. 특정 특허가 Essential Claim(s)를 포함한다고 생각하는 개인은 W3C 특허 정책 6절에 따라 정보를 공개해야 합니다.

이 문서는 2025년 8월 18일자 W3C 프로세스 문서에 따라 관리됩니다.

1. 웹 애플리케이션 매니페스트

애플리케이션 매니페스트는 웹 애플리케이션이 실행될 때 시작 매개변수와 애플리케이션 기본값을 포함하는 [JSON] 문서입니다.

매니페스트는 매니페스트 URL이 연관되어 있는데, 이는 매니페스트가 가져온 [URL]입니다.

매니페스트는 루트에 아래의 멤버 중 어느 것이든 가질 수 있으며, 모두 선택 사항입니다. 멤버들은 어떤 순서로든 나타날 수 있습니다.

참고

1.1 예시

이 섹션은 규범적인 내용이 아닙니다.

이 섹션은 개발자가 이 명세의 다양한 기능을 어떻게 활용할 수 있는지를 보여줍니다.

1.1.1 일반적인 구조

이 섹션은 규범적인 내용이 아닙니다.

아래는 일반적인 매니페스트 예시입니다.

예시 1: 일반적인 매니페스트 
{
  "lang": "en",
  "dir": "ltr",
  "name": "Super Racer 3000",
  "short_name": "Racer3K",
  "icons": [{
    "src": "icon/lowres.webp",
    "sizes": "64x64",
    "type": "image/webp"
  }, {
    "src": "icon/lowres.png",
    "sizes": "64x64"
  }, {
    "src": "icon/hd_hi",
    "sizes": "128x128"
  }],
  "scope": "/",
  "id": "superracer",
  "start_url": "/start.html",
  "display": "fullscreen",
  "orientation": "landscape",
  "theme_color": "aliceblue",
  "background_color": "red"
}

1.1.3 여러 아이콘 선언하기

이 섹션은 규범적인 내용이 아닙니다.

이 섹션은 icons 멤버를 사용해 웹 애플리케이션에 대한 여러 아이콘을 선언하는 방법을 보여줍니다. 아래 예시에서 개발자는 웹 애플리케이션에 포함된 아이콘에 대해 다음과 같이 선택했습니다:

  • 개발자는 같은 크기의 아이콘 두 개를 서로 다른 포맷으로 포함했습니다. 하나는 type 멤버를 통해 WebP로 명시했습니다. 만약 사용자 에이전트가 WebP를 지원하지 않으면 같은 크기의 두 번째 아이콘을 사용할 수 있습니다. 이 아이콘의 MIME 타입은 HTTP 헤더를 통해 결정되거나, 아이콘의 앞부분 몇 바이트를 통해 사용자 에이전트가 스니핑해서 결정할 수 있습니다.
  • 개발자는 픽셀 기반 아이콘 포맷(예: PNG 파일)에 대해 다양한 크기를 지정했습니다. 이 크기들은 사용자 에이전트가 특정 환경(예: 기기 홈 화면)에 사용할 적합한 아이콘을 결정하는 힌트입니다. 또한 ICO 파일(예: hd_hi.ico)을 포함했는데, 이는 각 디스플레이 크기에 맞게 개별적으로 설계된 래스터 아이콘을 포함합니다. 예를 들어, 256x256 이미지를 그대로 16x16 환경에 다운스케일하면 디테일이 크게 손실되기 때문에, 16x16 환경에 맞게 별도 이미지를 사용하는 것이 일반적입니다. 추가로 SVG 아이콘도 제공해 어떤 아이콘 크기에도 동적으로 리사이즈할 수 있지만, 일부 환경에서는 너무 작거나 흐려질 수 있습니다.

아이콘 목록은 사용자 에이전트에 제공되며, 다양한 환경과 위치에 맞춰 가장 적합한 아이콘이 선택됩니다.

예시 3: 여러 아이콘 
{
  "icons": [
    {
      "src": "icon/lowres.webp",
      "sizes": "48x48",
      "type": "image/webp"
    },{
      "src": "icon/lowres",
      "sizes": "48x48"
    },{
      "src": "icon/hd_hi.ico",
      "sizes": "72x72 96x96 128x128 256x256"
    },{
      "src": "icon/hd_hi.svg"
    }]
}

1.1.4 바로가기 만들기

이 섹션은 규범적인 내용이 아닙니다.

아래 예시에서 개발자는 두 개의 바로가기를 포함했습니다. 매니페스트의 URL이 https://example.com/manifest.webmanifest라고 가정하면:

  • 첫 번째 바로가기는 "Play Later"라는 텍스트로 표시됩니다. 운영체제가 컨텍스트 메뉴 아이콘과 SVG 이미지를 지원한다면, 사용자 에이전트는 https://example.com/icons/play-later.svg를 텍스트 옆에 표시할 수 있습니다. 실행 시, 사용자 에이전트는 새로운 최상위 브라우징 컨텍스트를 인스턴스화하고 https://example.com/play-later로 이동합니다.
  • 두 번째 바로가기는 "Subscriptions"라는 텍스트로 표시됩니다. 실행 시, 사용자 에이전트는 새로운 최상위 브라우징 컨텍스트를 인스턴스화하고 https://example.com/subscriptions?sort=desc로 이동합니다.
예시 4: 바로가기 추가 
{
  "shortcuts": [
    {
      "name": "Play Later",
      "description": "나중에 저장한 팟캐스트 목록 보기",
      "url": "/play-later",
      "icons": [
        {
          "src": "/icons/play-later.svg",
          "type": "image/svg+xml"
        }
      ]
    },
    {
      "name": "Subscriptions",
      "description": "구독 중인 팟캐스트 목록 보기",
      "url": "/subscriptions?sort=desc"
    }
  ]
}

1.1.5 "scope" 이해하기

이 섹션은 규범적인 내용이 아닙니다.

scope 멤버는 브라우저에게 어떤 문서가 웹 애플리케이션에 포함되고 어떤 문서가 아닌지를 알려줍니다. 즉, 사용자가 웹 사이트를 탐색할 때 매니페스트가 "적용"되는 웹 페이지 집합을 지정합니다.

예를 들어, {"scope": "/"}는 매니페스트가 오리진 내 모든 문서에 적용된다는 의미입니다. 반면, {"scope": "/racer/"}는 "/racer/" 경로 내의 문서에만 적용되어 "/racer/race1.html", "/racer/race2.html" 등은 모두 scope 내에 포함되지만, "/elsewhere/"나 루트 "/"는 "scope 밖"이므로 해당 경로의 문서에는 매니페스트가 적용되지 않습니다. 하나의 scope 경로만 지원합니다. 기술적인 상세는 5. 탐색 범위에서 확인할 수 있습니다.

매니페스트를 "적용"한다는 것은 매니페스트에서 프레젠테이션에 영향을 주는 멤버들이 효력을 발휘한다는 뜻입니다(예: 전체화면 디스플레이, 특정 화면 방향 적용 등). 애플리케이션이 scope 내 URL로 탐색되는 동안 브라우저는 계속해서 매니페스트를 적용합니다. 하지만 "scope 밖"으로 이동하면 매니페스트 적용이 중단되고 브라우저의 기본값이 적용됩니다. 예를 들어, 애플리케이션이 더 이상 전체화면이 아닌 브라우저 탭의 일반 웹 페이지로 표시될 수 있습니다. 구현자들은 웹 페이지가 scope 안팎으로 이동할 때의 동작을 자유롭게 결정할 수 있습니다. 자세한 기술 내용은 1.16.5 매니페스트 적용에서 확인할 수 있습니다.

마지막으로, 사용자가 오리진 내 어떤 문서에서든 웹 애플리케이션을 설치할 수 있으므로, 항상 매니페스트에 scope 멤버를 선언하는 것이 좋습니다. 만약 매니페스트에 scope 멤버가 없다면 start_url 멤버의 경로가 대체로 사용됩니다. 그리고 start_url마저 없으면, 웹 애플리케이션을 설치한 문서의 URL이 scope로 사용됩니다. 예기치 않은 탐색 동작을 피하려면 저자는 항상 scope 멤버를 포함시키고, 가능하다면 "/"로 설정하는 것이 바람직합니다.

1.2 dir 멤버

매니페스트의 dir 멤버는 기본 방향을 현지화 가능한 멤버에 대해 지정합니다. dir 멤버 값은 텍스트 방향으로 설정할 수 있습니다.

텍스트 방향은 다음과 같으며, 현지화 가능한 멤버의 기본값을 의미합니다:

"ltr"
왼쪽에서 오른쪽으로 쓰는 텍스트입니다.
"rtl"
오른쪽에서 왼쪽으로 쓰는 텍스트입니다.
"auto" (기본값)
텍스트 방향을 알 수 없습니다. 사용자 에이전트는 텍스트 표시를 추정하기 위해 휴리스틱을 사용해야 하며, 예를 들어 [UAX9]에 서술된 first-strong 알고리즘을 사용할 수 있습니다.

텍스트 방향 목록은 리스트 « "ltr", "rtl", "auto" » 입니다.

dir 멤버를 처리하려면, ordered map json과 ordered map manifest가 주어졌을 때:

  1. manifest["dir"]을 "auto"로 설정한다.
  2. json["dir"]이 존재하지 않거나, json["dir"]이 문자열이 아니면, 리턴한다.
  3. ASCII 앞뒤 공백 제거를 json["dir"]에 수행한다.
  4. ASCII 소문자화를 json["dir"]에 수행한다.
  5. 텍스트 방향 목록에 json["dir"]이 포함되지 않으면, 리턴한다.
  6. manifest["dir"]을 json["dir"]로 설정한다.

1.3 lang 멤버

매니페스트의 lang 멤버는 문자열 형태의 언어 태그로, 매니페스트의 현지화 가능한 멤버 값의 언어를 지정합니다. lang 멤버가 지정되지 않으면, 언어는 알 수 없는 것으로 처리됩니다.

참고

언어를 지정하면 사용자 에이전트가 폰트, 스타일, 하이픈 적용, 접근성을 위한 텍스트-음성 변환 등에서 가장 적절한 처리나 리소스를 선택할 수 있어 사용자 경험이 개선됩니다.

언어 태그는 [BCP47]에서 정의된 올바른 Language-Tag 생산식과 일치하는 문자열입니다.

참고

언어 태그는 대소문자를 구분하지 않습니다. 언어 태그 예시로는 'fr'(프랑스어), 'en-AU'(호주 영어), 'zh-Hans-CN'(중국 간체 한자)이 있습니다.

lang 멤버를 처리하려면, ordered map json과 ordered map manifest가 주어졌을 때:

  1. json["lang"]이 존재하지 않거나, json["lang"]이 문자열이 아니면 리턴한다.
  2. ASCII 앞뒤 공백 제거를 json["lang"]에 수행한다.
  3. IsStructurallyValidLanguageTag를 json["lang"]에 호출하여 false를 반환하면 리턴한다.
  4. Set manifest["lang"]을 json["lang"]에 CanonicalizeUnicodeLocaleId 추상 연산의 결과로 설정한다.

1.4 name 멤버

매니페스트의 name 멤버는 문자열이며, 웹 애플리케이션의 이름을 나타내며, 일반적으로 사용자에게 표시됩니다(예: 다른 애플리케이션 목록, 아이콘 라벨 등).

name 멤버는 현지화 가능한 멤버입니다.

name 멤버는 접근 가능한 이름으로 설치된 웹 애플리케이션에 사용됩니다.

참고: `name` 멤버 처리

매니페스트 처리 시 텍스트 멤버 처리 알고리즘을 사용하여 name 멤버를 처리합니다.

1.5 short_name 멤버

매니페스트의 short_name 멤버는 문자열로, 웹 애플리케이션 이름의 짧은 버전을 나타냅니다. 전체 이름을 표시할 공간이 충분하지 않은 경우에 사용됩니다.

short_name 멤버는 현지화 가능한 멤버입니다.

참고: `short_name` 멤버 처리

매니페스트 처리 시 텍스트 멤버 처리 알고리즘을 사용하여 short_name 멤버를 처리합니다.

1.6 scope 멤버

매니페스트의 scope 멤버는 문자열로, 해당 웹 애플리케이션의 탐색 범위를 나타내며, 애플리케이션 컨텍스트에 적용됩니다.

참고: 기본 scope

scope 멤버 처리 방법: ordered map json과 ordered map manifest가 주어졌을 때:

  1. manifest["scope"]에 파싱 "."을 manifest["start_url"]을 기준(base URL)으로 하여 결과를 할당한다.
  2. json["scope"]가 빈 문자열이면 리턴한다.
  3. scope을 파싱 json["scope"]를 manifest URL을 기준으로 하여 결과로 한다.
  4. scope이 실패(failure)이면 리턴한다.
  5. scope의 query와 fragment를 null로 설정한다.
  6. manifest["start_url"]이 scope 내가 아니면 리턴한다.
  7. 그 외의 경우, manifest["scope"]를 scope로 설정한다.

1.7 icons 멤버

매니페스트의 icons 멤버는 다양한 환경에서 웹 애플리케이션을 상징적으로 나타내는 이미지입니다. 예를 들어, 다른 애플리케이션 목록에서 웹 애플리케이션을 표시하거나, OS의 작업 전환기 또는 시스템 설정에 통합할 때 사용할 수 있습니다.

icons 멤버는 현지화 가능한 멤버입니다.

참고

1.8 display 멤버

매니페스트의 display 멤버는 웹 애플리케이션의 표시 모드에 대한 개발자의 선호를 나타냅니다. 값은 display mode입니다.

display 멤버 처리 방법: ordered map json과 ordered map manifest가 주어졌을 때:

  1. manifest["display"]를 "browser"로 설정한다.
  2. json["display"]가 존재하지 않거나 json["display"]가 문자열이 아니면 리턴한다.
  3. ASCII 앞뒤 공백 제거를 json["display"]에 수행한다.
  4. ASCII 소문자화를 json["display"]에 수행한다.
  5. display modes list에 json["display"]가 포함되지 않으면, 리턴한다.
  6. manifest["display"]를 json["display"]로 설정한다.

1.9 orientation 멤버

매니페스트의 orientation 멤버는 문자열로, 웹 애플리케이션의 모든 최상위 브라우징 컨텍스트의 기본 화면 방향 역할을 합니다. 가능한 값은 OrientationLockType 열거형의 값이며, 본 명세에서는 orientation values ("any", "natural", "landscape", "portrait", "portrait-primary", "portrait-secondary", "landscape-primary", "landscape-secondary")로 불립니다.

사용자 에이전트가 orientation 멤버의 값을 기본 화면 방향으로 지원한다면, 그 값이 웹 애플리케이션의 생명주기 동안 기본 화면 방향으로 동작합니다(런타임에 다른 방법으로 재정의하지 않는 한). 즉, 사용자 에이전트는 orientation이 unlock될 때마다 반드시(MUST) 기본 화면 방향으로 되돌려야 하며, 최상위 브라우징 컨텍스트가 탐색(navigated)될 때도 마찬가지입니다.

참고

명세는 [SCREEN-ORIENTATION]의 OrientationLockType에 의존하지만, 사용자 에이전트가 [SCREEN-ORIENTATION] API를 구현하는 것은 옵션(OPTIONAL)입니다. 물론 해당 API 지원을 권장합니다.

UI/UX 및 플랫폼 관례에 따라 일부 화면 방향과 함께 사용할 수 없는 표시 모드가 존재할 수 있습니다. 어떤 방향과 표시 모드가 함께 사용할 수 없는지는 구현자의 재량에 맡깁니다. 예를 들어, 일부 사용자 에이전트에서는 기본 화면 방향을 browser 표시 모드에서 변경하는 것이 이상할 수 있습니다.

참고

웹 애플리케이션이 실행 중일 때, 다른 방법(예: [SCREEN-ORIENTATION] API 등)으로 최상위 브라우징 컨텍스트의 방향을 변경할 수 있습니다.

orientation 멤버 처리 방법: ordered map json과 ordered map manifest가 주어졌을 때:

  1. json["orientation"]이 존재하지 않거나 json["orientation"]이 문자열이 아니면 리턴한다.
  2. ASCII 앞뒤 공백 제거를 json["orientation"]에 수행한다.
  3. ASCII 소문자화를 json["orientation"]에 수행한다.
  4. json["orientation"]이 포함하지 않으면 orientation values 중 아무것도, 리턴한다.
  5. manifest["orientation"]을 json["orientation"]로 설정한다.

1.10 start_url 멤버

매니페스트의 start_url 멤버는 문자열로, 시작 URL을 나타냅니다. 즉, 사용자가 웹 애플리케이션을 실행할 때(예: 기기 앱 메뉴나 홈 화면에서 아이콘을 클릭할 때) 사용자 에이전트가 로드하길 개발자가 원하는 URL입니다.

start_url 멤버는 권고적(advisory)이며, 사용자 에이전트는 MAY 무시하거나 최종 사용자가 사용하지 않을 선택권을 제공할 수 있습니다. 또한, 예를 들어 웹 애플리케이션에 대한 북마크를 만들 때나 그 이후에도, 사용자 에이전트는 최종 사용자가 URL을 수정하도록 허용할 수 있습니다(MAY).

start_url 멤버 처리 방법: ordered map json, ordered map manifest, URL manifest URL, URL document URL이 주어졌을 때:

  1. manifest["start_url"]을 document URL로 설정한다.
  2. json["start_url"]이 존재하지 않거나 json["start_url"]이 문자열이 아니면 리턴한다.
  3. json["start_url"]의 타입이 문자열이 아니거나, 빈 문자열이면 리턴한다.
  4. start URL을 파싱 json["start_url"]을 manifest URL을 기준으로 하여 얻는다.
  5. start URL이 실패(failure)이면 리턴한다.
  6. start URL이 document URL과 same origin이 아니면 리턴한다.
  7. 그 외의 경우, manifest["start_url"]을 start URL로 설정한다.

1.10.1 개인정보 보호 고찰: start_url 추적

start_url이 브라우저 외부에서 애플리케이션이 실행되었음을 나타내도록 설계될 수도 있습니다(예: "start_url": "index.html?launcher=homescreen"). 이는 분석(analytics)이나 기타 커스텀 기능에 유용할 수 있습니다. 그러나 개발자가 start_url에 사용자 고유 식별자(예: 서버에서 할당된 식별자, "?user=123", "/user/123/", "https://user123.foo.bar")를 인코딩할 수도 있습니다. 이는 사용자가 인지하지 못하는 지문/개인정보 민감 정보가 될 수 있습니다.

참고: start URL에 식별자 추가 금지

개발자가 start URL에 사용자 고유 정보를 포함하는 것은 좋지 않은 습관입니다. 이는 사용자가 사이트 데이터를 삭제해도 지문이 남을 수 있습니다. 하지만 본 명세는 이를 실질적으로 방지할 방법을 제공하지 않습니다.

위의 이유로, 설치 시 또는 그 이후에라도, 사용자 에이전트가 사용자가 애플리케이션의 start URL을 검사 및 필요 시 수정할 수 있도록 허용하는 것이 권장(RECOMMENDED)됩니다.

사용자 에이전트는 이런 형태의 지문(식별) 방지책을 제공할 수 있습니다(MAY). 예를 들어, 사용자가 오리진의 데이터를 삭제할 때, 사용자 에이전트는 해당 오리진의 scope 내 애플리케이션을 제거하여 start URL에 남은 지문을 함께 삭제할 수 있습니다.

1.11 id 멤버

매니페스트의 id 멤버는 문자열로, 애플리케이션의 고유 식별자(identity)를 나타냅니다. 고유 식별자(identity)는 URL 형태를 가지며, start URL과 동일한 오리진입니다.

고유 식별자는 사용자 에이전트가 애플리케이션을 전역적으로 고유하게 식별하는 데 사용됩니다. 사용자 에이전트가 고유 식별자가 기존에 설치된 애플리케이션과 일치하지 않는 매니페스트를 발견하면, 그 매니페스트를 별도의 애플리케이션으로 간주해야 합니다(SHOULD). 동일한 URL에서 제공되더라도 별도 애플리케이션으로 처리합니다. 반대로, manifest["id"]가 이미 설치된 애플리케이션의 고유 식별자와 동일(equal)하면(옵션으로 프래그먼트 제외 설정 가능), 그 매니페스트는 기존 애플리케이션의 매니페스트를 대체하는 것으로 간주해야 합니다(SHOULD). 이전과 다른 URL에서 제공되어도 별도 애플리케이션으로 취급하지 않습니다.

참고: 프래그먼트 제외가 최선의 관행
참고

고유 식별자는 웹 애플리케이션 목록을 수집하는 서비스에서 개별 애플리케이션을 고유하게 식별하는 데 사용할 수 있습니다.

참고

고유 식별자는 URL처럼 처리되지만, 탐색할 수 있는 리소스를 가리키지 않으므로 scope 내일 필요는 없습니다.

id 멤버 처리 방법: ordered map json, ordered map manifest가 주어졌을 때:

  1. manifest["id"]를 manifest["start_url"]로 설정한다.
  2. json["id"]의 타입이 문자열이 아니면 리턴한다.
  3. json["id"]가 빈 문자열이면 리턴한다.
  4. base origin을 manifest["start_url"]의 origin으로 한다.
  5. id를 파싱 json["id"]를 base origin을 기준으로 하여 얻는다.
  6. id가 실패(failure)이면 리턴한다.
  7. id가 manifest["start_url"]와 동일 오리진이 아니면 리턴한다.
  8. id의 fragment를 null로 설정한다.
  9. manifest["id"]를 id로 설정한다.

1.12 theme_color 멤버

매니페스트의 theme_color 멤버는 애플리케이션 컨텍스트의 기본 테마 색상 역할을 합니다. 테마 색상의 정의는 [HTML]에 있습니다.

사용자 에이전트가 theme_color 멤버 값을 기본 테마 색상으로 적용하면, 해당 색상은 매니페스트가 적용된 모든 브라우징 컨텍스트의 테마 색상이 됩니다. 단, 사용자 에이전트는 MAY 기본 테마 색상을, 문서의 URL이 scope 내이고 그 애플리케이션 컨텍스트의 매니페스트에 meta 요소가 있고 name 속성이 "theme-color"일 때, 이를 통해 오버라이드할 수 있습니다. 하지만 사용자 에이전트는 SHOULD NOT scope 밖 문서의 URL에 대해 name="theme-color" meta 요소로 기본 테마 색상을 오버라이드해서는 안 됩니다. 애플리케이션이 해당 문서들을 제어할 수 없기 때문입니다.

사용자 에이전트는 MAY 테마 색상의 알파 컴포넌트를 환경에 따라 무시할 수 있습니다. 예를 들어, 대부분의 환경에서는 테마 색상에 투명값을 사용할 수 없습니다.

구현자는 MAY theme_color 멤버로 정의된 값을 prefers-color-scheme 지원을 위해 오버라이드할 수 있습니다.

참고

매니페스트를 처리할 때, 색상 멤버 처리 알고리즘을 사용해 theme_color 멤버를 처리합니다.

1.13 background_color 멤버

매니페스트의 background_color 멤버는 웹 애플리케이션의 예상 배경색을 설명합니다. 이는 애플리케이션 스타일시트에 이미 정의되어 있지만, 사용자 에이전트가 매니페스트를 알고 있고 실제 파일(네트워크에서 가져오거나 디스크에서 읽기 전)이 아직 준비되지 않았을 때 배경색을 그리는 데 사용할 수 있습니다.

background_color 멤버는 웹 애플리케이션이 로딩되는 동안 사용자 경험을 개선하기 위한 용도이며, 사용자 에이전트가 웹 애플리케이션의 스타일시트가 적용된 이후에는 배경색으로 사용해서는 안 됩니다(MUST NOT).

구현자는 MAY background_color 멤버로 정의된 값을 prefers-color-scheme 지원을 위해 오버라이드할 수 있습니다.

참고

매니페스트를 처리할 때, 색상 멤버 처리 알고리즘을 사용해 background_color 멤버를 처리합니다.

1.14 shortcuts 멤버

매니페스트의 shortcuts 멤버는 웹 애플리케이션 내 핵심 작업에 접근할 수 있는 목록(list) 형태의 shortcut item들입니다.

참고

바로가기가 어떻게 표시되고 몇 개가 사용자에게 노출되는지는 사용자 에이전트 및/또는 운영체제의 재량입니다.

shortcuts 멤버 처리 방법: ordered map json, ordered map manifest, URL manifest URL이 주어졌을 때:

  1. processedShortcuts를 새 목록(list)으로 생성한다.
  2. Set manifest["shortcuts"]를 processedShortcuts로 설정한다.
  3. json["shortcuts"]가 존재하지 않거나, json["shortcuts"]가 목록(list)이 아니면 리턴한다.
  4. 각각 entry에 대해 json["shortcuts"]:
    1. shortcut을 process a shortcut에 entry, manifest URL, manifest["scope"], manifest["dir"]를 넘겨서 얻는다.
    2. shortcut이 실패라면 continue.
    3. Append shortcut을 processedShortcuts에 추가한다.

사용자 에이전트는 SHOULD 운영체제의 앱 아이콘 컨텍스트 메뉴 노출 방식과 일관된 인터페이스(예: 우클릭, 롱프레스 등)로 바로가기를 노출해야 합니다. 바로가기는 매니페스트에 제공된 순서대로 렌더링해야 하며, 컨텍스트 메뉴 노출 방식과 일관되게 표현해야 합니다. 운영체제의 관행이나 제한에 맞추기 위해 바로가기 목록을 잘라내 MAY 일부만 보여줄 수 있습니다.

1.15 *_localized 멤버

현지화 가능한 멤버(localizable member)는 매니페스트의 현지화가 가능한 멤버입니다. 각 현지화 가능한 멤버에는 *_localized 멤버가 대응하며, *는 실제 멤버 이름을 나타냅니다.

언어 맵(language map)은 ordered map으로, 키는 언어 태그(language tag)이고 값은 localized value입니다. localized value는 키에 지정된 언어로 현지화된 콘텐츠입니다.

현지화 가능한 멤버에 할당된 값은 기본 표현(default representation)입니다. *_localized 멤버들은 언어 맵을 포함하며, 애플리케이션 내 해당 현지화 가능한 멤버에 대해 localized value를 정의합니다. 사용자 에이전트는 SHOULD 사용자의 현지화 설정에 따라 언어 태그 키가 사용자의 선호와 가장 잘 일치하는 localized value를 선택해야 합니다. 해당 localized value가 없는 경우, 기본 표현(default representation)을 사용합니다.

1.15.1 텍스트 값의 지역화

localized text object는 다음 속성을 가지는 ordered map입니다:

value
지역화된 문자열입니다.
dir (선택)
텍스트 방향입니다.
lang (선택)
언어 태그입니다.

지역화 가능한 멤버가 문자열을 허용하는 경우, *_localized 멤버의 language map은 문자열 또는 localized text object를 localized value로 허용합니다.

문자열을 사용하는 경우나 dir 멤버가 localized text object에 없으면, 기본 방향(매니페스트의 dir 멤버)이 적용됩니다.

Note

문자열을 사용하는 경우나 lang 멤버가 localized text object에 없으면, language tag(language map의 key)가 적용됩니다.

Note

*_localized 텍스트 멤버 처리는 ordered map json, ordered map map, string member, text-direction defaultDirection을 입력으로 다음과 같이 동작합니다:

  1. member가 json에 존재하지 않으면 return.
  2. languageMap을 json[member]로 설정.
  3. languageMap이 ordered map이 아니면 return.
  4. languageTags를 languageMap의 키들로 설정.
  5. map[member]를 새 ordered map으로 설정.
  6. 각 languageTag를 languageTags에서 반복하여 localized text object 처리를 languageMap[languageTag], languageTag, map, member, defaultDirection에 대해 실행.

localized text object 처리는 문자열 또는 ordered map localizedValue, string defaultLanguageTag, ordered map map, string member, text-direction defaultDirection을 입력으로 다음과 같이 동작합니다:

  1. normalizedValue를 새 ordered map으로 설정.
  2. localizedValue가 문자열이면, 앞뒤 ASCII 공백 제거 후 normalizedValue["value"]에 localizedValue를 설정.
  3. localizedValue가 ordered map이면:
    1. "value"가 존재하고 localizedValue["value"]가 문자열이면, 앞뒤 ASCII 공백 제거 후 normalizedValue["value"]에 할당.
    2. "lang"이 존재하고 localizedValue["lang"]가 문자열이면, 앞뒤 ASCII 공백 제거 후 normalizedValue["lang"]에 할당.
    3. "dir"이 존재하고 localizedValue["dir"]가 문자열이면:
      1. 앞뒤 ASCII 공백 제거 후 localizedValue["dir"]에 적용.
      2. text-direction list가 포함하면 normalizedValue["dir"]에 할당.
  4. "value"가 존재하지 않으면 return.
  5. "lang"이 존재하지 않으면, normalizedValue["lang"]에 defaultLanguageTag 할당.
  6. "dir"이 존재하지 않으면, normalizedValue["dir"]에 defaultDirection 할당.
  7. IsStructurallyValidLanguageTag를 normalizedValue["lang"] 또는 defaultLanguageTag에 호출해서 false면 return.
  8. Set map[member][defaultLanguageTag] = normalizedValue.
Note

localized text object 처리 알고리즘은 문자열 또는 localized text object 모두를 localized value로 받을 수 있지만, 처리 결과는 value, lang, dir 멤버가 설정된 localized text object로 정규화됩니다.

1.15.2 이미지 리소스의 지역화

지역화 가능한 멤버가 리스트의 image resources를 허용하는 경우, *_localized 멤버의 language map은 리스트의 image resources를 localized value로 허용합니다.

*_localized 이미지 리소스 멤버 처리는 ordered map json, ordered map map, string member, URL manifest URL을 입력으로 다음과 같이 동작합니다:

  1. member가 json에 존재하지 않으면 return.
  2. languageMap을 json[member]로 설정.
  3. languageMap이 ordered map이 아니면 return.
  4. languageTags를 languageMap의 키들로 설정.
  5. map[member]를 새 ordered map으로 설정.
  6. 각 languageTag를 languageTags에서 반복:
    1. IsStructurallyValidLanguageTag를 languageTag에 호출해서 false면 continue.
    2. 이미지 리소스 처리를 실행하며, languageMap[languageTag]을 리스트의 image resources로, map[member], manifest URL, languageTag를 member로 전달.

1.16 매니페스트 생명주기

이 절에서는 매니페스트 처리와 매니페스트 적용 알고리즘을 정의합니다. 매니페스트.

사용자 에이전트는 반드시 "manifest" 링크 타입과 연결된 리소스를 가져오고 처리하는 단계들을 지원해야 합니다.

1.16.1 매니페스트 처리

무시하도록 지시받았을 때, 사용자 에이전트는 해당 조건을 유발한 매니페스트, 멤버 또는 값을 없는 것처럼 동작해야 합니다.

다음 알고리즘은 처리 확장 지점을 제공합니다: 매니페스트에 새로운 멤버를 추가하는 다른 명세들은 이 알고리즘의 이 지점에 연결하는 것이 권장됩니다. 기존 manifest 객체의 값을 수정해서는 안 됩니다.

Note

처리 확장 지점은 몽키 패치와 관련된 문제를 피하기 위해 고안되었습니다.

매니페스트 처리 단계는 다음 알고리즘에 의해 제공됩니다. 이 알고리즘은 URL document URL, URL manifest URL, 그리고 바이트 시퀀스 bodyBytes를 입력으로 받습니다.

  1. json을 parse JSON bytes to an Infra value를 bodyBytes에 적용한 결과로 설정합니다.
  2. json이 파싱 예외이거나 json이 ordered map이 아닌 경우:
    1. json을 빈 ordered map으로 설정합니다.
  3. manifest를 빈 ordered map으로 설정합니다.
  4. dir 멤버 처리를 json과 manifest에 적용합니다.
  5. lang 멤버 처리를 json과 manifest에 적용합니다.
  6. 텍스트 멤버 처리를 json, manifest, 그리고 "name"에 적용합니다.
  7. *_localized 텍스트 멤버 처리를 json, manifest, "name_localized", 그리고 manifest["dir"]에 적용합니다.
  8. 텍스트 멤버 처리를 json, manifest, 그리고 "short_name"에 적용합니다.
  9. *_localized 텍스트 멤버 처리를 json, manifest, "short_name_localized", 그리고 manifest["dir"]에 적용합니다.
  10. start_url 멤버 처리를 json, manifest, manifest URL, 그리고 document URL에 적용합니다.
  11. id 멤버 처리를 json과 manifest에 적용합니다.
  12. document의 processed manifest가 null이 아니고, document의 processed manifest의 id가 manifest["id"]와 같지 않다면, return.
  13. scope 멤버 처리를 json, manifest, 그리고 manifest URL에 적용합니다.
  14. 컬러 멤버 처리를 json, manifest, 그리고 "theme_color"에 적용합니다.
  15. 컬러 멤버 처리를 json, manifest, 그리고 "background_color"에 적용합니다.
  16. display 멤버 처리를 json과 manifest에 적용합니다.
  17. 이미지 리소스 처리를 json["icons"], manifest, manifest URL, 그리고 "icons"에 적용합니다.
  18. *_localized 이미지 리소스 멤버 처리를 json, manifest, "icons_localized", 그리고 manifest URL에 적용합니다.
  19. orientation 멤버 처리를 json, manifest에 적용합니다.
  20. shortcuts 멤버 처리를 json, manifest, 그리고 manifest URL에 적용합니다.
  21. 처리 확장 지점에서 알고리즘에 지원되는 프로프라이어터리 및 기타 멤버를 처리합니다.
  22. document의 processed manifest를 manifest로 설정합니다.

1.16.2 컬러 멤버 처리

Note: 지원되는 색상

sRGB 색상과, 사용자 에이전트가 외부 정보 없이 sRGB로 변환할 수 있는 색상(예: "AliceBlue")만 지원됩니다. 예를 들어, lab(…) 또는 color(display-p3, …)는 외부 정보 없이 sRGB로 변환할 수 있지만, color(--custom-profile, …)는 매니페스트에서 지정할 수 없는 "@color-profile" 규칙을 찾아야 하므로 지원되지 않습니다.

컬러 멤버 처리는 ordered map json, ordered map map, 그리고 string member를 입력으로 받습니다:

  1. json[member]가 존재하지 않거나 json[member]가 string이 아니면, return.
  2. 앞뒤 ASCII 공백 제거를 json[member]에 적용합니다.
  3. color를 CSS 색상으로 파싱한 결과로 설정합니다.
  4. color가 실패이면, return.
  5. color가 사용자 에이전트가 내재적으로 알고 있는 정보만으로 sRGB로 변환할 수 있으면, color를 sRGB로 변환합니다.
  6. color가 sRGB 색상이 아니면, return.
  7. map[member]를 color로 설정합니다.

1.16.3 텍스트 멤버 처리

텍스트 멤버 처리는 ordered map json, ordered map map, 그리고 string member를 입력으로 받습니다:

  1. json[member]가 존재하지 않거나 json[member] 가 string이 아니면, return.
  2. 앞뒤 ASCII 공백 제거를 json[member]에 적용합니다.
  3. map[member]를 json[member]의 값으로 설정합니다.

1.16.4 문서 없이 매니페스트 처리

매니페스트 처리 단계는 [HTML]의 link 요소 처리 단계에서 호출되지만, 사용자 에이전트가 문서와 연결되지 않은 매니페스트를 처리하기 위해 적용할 수도 있습니다.

이 경우, [HTML]의 해당 단계에서 보장하는 것과 일치시키기 위해, 사용자 에이전트는 최소한 과거에 다음을 권장합니다:

Note: 이러한 체크의 근거

1.16.5 매니페스트 적용

처리된 매니페스트는 적용되어 최상위 브라우징 컨텍스트에 영향을 줍니다. 즉, 매니페스트의 멤버들이 브라우징 컨텍스트의 표시 또는 동작에 영향을 미칩니다. 사용자 에이전트는 적용할 수 있습니다 매니페스트 적용을 탐색 시작 전에 할 수 있습니다.

Note

매니페스트가 적용된 최상위 브라우징 컨텍스트는 애플리케이션 컨텍스트로 불립니다.

애플리케이션 컨텍스트가 사용자가 navigate를 통해 딥 링크로 이동하도록 요청한 결과로 생성된 경우, 사용자 에이전트는 즉시 navigate를 딥 링크에 대해 historyHandling을 "replace"로 설정하여 수행해야 합니다. 그렇지 않으면 애플리케이션 컨텍스트가 생성될 때, 사용자 에이전트는 즉시 navigate를 start URL에 대해 historyHandling을 "replace"로 설정하여 수행해야 합니다.

Note

1.16.6 매니페스트 업데이트

manifest 링크 관계에 명시된 대로, 매니페스트는 모든 페이지 로드 시 가져오고 처리됩니다. 매니페스트 처리가 성공하면, 사용자 에이전트는 업데이트된 매니페스트를 현재 및 미래의 애플리케이션 컨텍스트에 적용할 수 있습니다.

업데이트 목적상, 다음 멤버는 보안 민감 멤버입니다. 이들은 설치 및 실행 화면에서 표시됩니다:

  1. short_name와 short_name_localized의 지역화 표현,
  2. icons 및 icons_localized의 지역화 표현,
  3. name 및 name_localized의 지역화 표현.

보안 민감 멤버는 방향에 관계없이 [UTS55]에서 설명한 대로 양방향 격리하여 표시해야 합니다.

사용자 에이전트는 사용자의 명시적 허가 없이 보안 민감 멤버 변경을 자동 적용해서는 안 됩니다.

대신, 사용자 에이전트는 보안 민감 멤버 변경을 적절한 관리 옵션과 함께 표시하여 사용자가 웹 애플리케이션 업데이트에 대해 정보를 바탕으로 결정할 수 있도록 해야 합니다.

만약 업데이트에 보안 민감 멤버 변경이 없다면, 사용자 에이전트는 변경을 자동 적용할 수 있습니다.

사용자가 지역화 설정을 변경하면, 사용자 에이전트는 자동으로 실행 화면에 표시되는 보안 민감 멤버를 *_localized 멤버에 지정된 지역화 표현으로 조정할 수 있습니다. 이 변경은 사용자가 웹 애플리케이션을 다음에 열 때 표시되어야 합니다.

Note: 사용자 에이전트는 부분 업데이트를 적용하지 않음

2. 매니페스트 이미지 리소스

각 매니페스트 이미지 리소스는 웹 애플리케이션의 개념적 일부로, 멤버의 의미에 따라 다양한 컨텍스트(예: 애플리케이션 메뉴의 아이콘 등)에서 사용할 수 있는 이미지 리소스입니다.

매니페스트 이미지 리소스는 이미지 리소스와 달리 purpose 멤버를 추가로 가질 수 있습니다.

사용자 에이전트는 이미지 리소스를 플랫폼의 시각적 스타일에 더 잘 맞도록(예: 모서리 둥글게, 특정 색상으로 칠하기 등) 수정해서 사용자에게 표시할 수 있습니다. 개발자는 색상 변경이나 모서리 잘림 등으로 중요한 정보가 손실되지 않도록 이미지를 준비하는 것이 좋습니다.

2.1 purpose 멤버

purpose 멤버는 공백으로 구분된 고유 토큰의 순서 없는 집합입니다. 허용되는 값은 아이콘 목적입니다.

매니페스트 이미지 리소스가 아이콘으로 사용될 때, 개발자는 해당 이미지가 운영체제(OS) 내에서 특별한 목적(더 나은 통합 등)을 위해 사용된다는 힌트를 줄 수 있습니다. 사용자 에이전트는 명시된 아이콘 목적이 아닌 용도로 아이콘을 사용해서는 안 됩니다.

Note

예를 들어, "monochrome" 목적의 아이콘은 배지나 고정 아이콘 등 단색으로 채워진, 애플리케이션의 전체 색상 실행 아이콘과 시각적으로 구별되는 용도로 사용할 수 있습니다. 사용자 에이전트는 purpose 멤버의 값을 힌트로 사용하여 아이콘이 어디서, 어떻게 표시될지 결정합니다. 개발자가 별도로 선언하지 않았다면, 사용자 에이전트는 아이콘을 아무 목적에 사용할 수 있습니다.

아이콘 목적은 다음과 같습니다:

monochrome
사용자 에이전트는 단색 아이콘이 필요한 곳에 이 아이콘을 사용할 수 있습니다. 아이콘의 색상 정보는 버려지고 알파 데이터만 사용됩니다. 이후 사용자 에이전트는 아이콘을 어떤 단색 위에 마스크처럼 사용할 수 있습니다.
maskable
이미지는 아이콘 마스크와 안전 영역을 염두에 두고 디자인되어, 이미지의 안전 영역 밖의 부분은 사용자 에이전트가 무시하거나 마스킹해도 안전합니다.
any (기본값)
사용자 에이전트는 purpose가 필요하지 않은 곳에 아이콘을 자유롭게 표시할 수 있습니다. 예를 들어, "any" 목적의 매니페스트 이미지 리소스는 "monochrome"이 필요한 컨텍스트에서는 사용되지 않습니다.

아이콘 목적 리스트는 리스트 « "monochrome", "maskable", "any" »입니다.

Note

아이콘이 여러 목적을 포함하면 그 중 어느 목적에도 사용할 수 있습니다. 명시된 목적이 하나도 인식되지 않으면 아이콘은 완전히 무시됩니다. 예를 들어, 아이콘이 "monochrome fizzbuzz" 목적을 가지면 "monochrome"이 유효하므로 단색 아이콘으로 사용할 수 있습니다. 하지만 "fizzbuzz"만 있으면 무시됩니다.

이미지 목적 결정은 ordered map json을 받아 다음과 같이 동작합니다:

  1. json["purpose"]가 존재하지 않거나 json["purpose"]가 string이 아니면:
    1. set « "any" »를 반환합니다.
  2. keywords를 ASCII 공백으로 분리한 json["purpose"]의 결과로 설정합니다.
  3. purposes를 새 set으로 설정합니다.
  4. 각 keyword를 keywords에서 반복:
    1. 아이콘 목적 리스트에 keyword가 포함되지 않으면, continue.
    2. 그렇지 않으면 append keyword를 purposes에 추가합니다.
  5. purposes가 비어 있으면, 실패를 반환합니다.
  6. purposes를 반환합니다.

2.2 콘텐츠 보안 정책

아이콘 이미지를 가져올 수 있는지에 대한 보안 정책은 매니페스트 소유 Document에 연결된 img-src 지시어 [CSP3]에 의해 결정됩니다.

2.3 아이콘 마스크와 안전 영역

일부 플랫폼은 고유의 아이콘 모양을 선호하지만, 웹 애플리케이션은 여러 플랫폼에서 동작해야 하므로 maskable 목적을 추가하여 아이콘에 사용자 에이전트가 마스크를 적용할 수 있음을 나타낼 수 있습니다. 이를 통해 플랫폼에서 아이콘이 일관성 있게 보이도록 하고, 플랫폼 곳곳에서 다양한 마스크와 배경색을 적용할 수 있습니다.

안전 영역은 maskable 아이콘 내에서 사용자 에이전트의 선택과 관계없이 항상 표시되는 영역입니다. 아이콘 중심에 위치한, 반지름이 아이콘 크기의 2/5(40%)인 원으로 정의됩니다. 아이콘이 정사각형이 아니라면 너비와 높이 중 작은 쪽을 기준으로 합니다.

Note

maskable 아이콘의 디자이너는 모든 중요한 부분이 안전 영역 안에 있도록 해야 합니다.

safe zone illustrated
Figure 1 안전 영역은 아이콘의 너비와 높이 중 작은 값의 2/5(40%) 반지름을 가진 중심 원입니다.

이 영역의 모든 픽셀은 모든 마스크에서 항상 보장됩니다. 안전 영역 밖의 픽셀은 적용된 마스크에 따라 보이지 않을 수도 있습니다.

사용자 에이전트는 임의 크기의 마스크를 적용할 수 있으며, 중심(안전 영역)에서 아이콘 크기의 2/5 이상 떨어진(최소 너비, 높이) 픽셀을 투명하게 만들 수 있습니다.

사용자 에이전트는 안전 영역 내의 픽셀을 투명하게 해서는 안 됩니다.

사용자 에이전트는 아이콘에 패딩을 추가하여 확대할 수 있습니다.

아이콘에 투명 픽셀이 있으면, 사용자 에이전트는 반드시 임의의 단색(예: 흰색) 위에 아이콘을 합성해야 합니다.

Note

maskable 아이콘에는 투명 픽셀 사용을 피하는 것이 좋습니다.

2.3.1 마스크 예시

Note

안전 영역 안에만 내용이 있으면 대부분의 아이콘은 상하좌우 약 10% 패딩(내용 없음 또는 배경 등)이 생깁니다. 모든 안전 영역 외부가 마스크 처리될 때 아이콘을 점검하는 것이 좋습니다.

2.3.1.1 "maskable" 목적 아이콘
An icon over a checkerboard background
Figure 2 이미지 투명 배경의 기본 이미지
An icon in a purple circle (40% of the size) over a yellow background
Figure 3 안전 영역 아이콘 크기 2/5(40%) 반지름의 원
2.3.1.2 마스크 예시
An icon inside a rounded yellow square on a purple background
Figure 4 둥근 사각형 Android
An icon inside an extremely rounded yellow square on a purple background
Figure 5 스퀴클 Android
An icon inside a rounded yellow circle on a purple background
Figure 6 원 Android
An icon inside a somewhat rounded yellow square on a purple background
Figure 7 둥근 사각형 iOS
An icon on a yellow background
Figure 8 풀블리드 Windows

2.4 단색 아이콘과 단색 채우기

일부 플랫폼은 아이콘을 단색 채우기로(한 가지 색상) 표시하도록 강제하며, 아이콘의 투명도만 매니페스트에서 지정할 수 있습니다. 여러 플랫폼에서 동작해야 하므로, monochrome 목적을 추가하여 아이콘에 사용자 에이전트가 색상을 지정할 수 있음을 나타낼 수 있습니다. 이렇게 하면 플랫폼에서 아이콘이 일관성 있게 보이고, 다양한 색상과 패딩을 적용할 수 있습니다.

monochrome 아이콘을 표시할 때, 사용자 에이전트는 픽셀의 빨강, 초록, 파랑 성분을 독립적으로 표시해서는 안 됩니다. 픽셀의 원래 알파값은 그대로, 빨강/초록/파랑 값은 사용자 에이전트가 임의로 선택하여 표시해야 합니다. 모든 픽셀에 같은 색 값을 사용하는 것이 권장됩니다.

Note

monochrome 아이콘의 디자이너는 모든 픽셀을 검정색으로 하고 투명도로 실루엣만 표현할 수 있습니다.

사용자 에이전트는 아이콘에 패딩을 추가해 확대할 수 있습니다.

사용자 에이전트는 투명 픽셀 뒤에 임의의 색상 배경을 추가할 수 있고, 배경이 아이콘과 충분한 대비를 갖도록 해야 합니다.

2.4.1 단색 아이콘 사용 예시

2.4.1.1 사용 예시
A black icon over a checkerboard background
Figure 9 이미지 색상이 없는 기본 이미지.
A dark gradient icon over a checkerboard background
Figure 10 그라데이션 채움 이미지가 그라데이션으로 채워짐.
A dark yellow icon over a light gray background
Figure 11 단색 채움과 패딩 매니페스트의 테마 색상으로 채워짐.

2.5 이미지 리소스 처리

이미지 리소스 처리는 list images, ordered map map, manifest URL 및 string member를 입력으로 받아 다음과 같이 동작합니다:

  1. imageResources를 새 리스트로 설정합니다.
  2. map[member]를 imageResources로 설정합니다.
  3. images가 리스트가 아니면, return.
  4. 각 potential image를 images에서 반복:
    1. image를 process an image resource from JSON을 potential image와 manifest URL로 실행한 결과로 설정합니다.
    2. image가 실패이면, continue.
    3. purposes를 이미지 목적 결정을 potential image에 실행한 결과로 설정합니다.
    4. purposes가 실패이면, continue.
    5. image["purpose"]를 purposes로 설정합니다.
    6. Append image를 imageResources에 추가합니다.

3. 바로가기 항목

각 바로가기 항목은 ordered map이며, 웹 앱 내의 주요 작업 또는 페이지로의 링크를 나타냅니다. 다음 멤버를 가집니다:

사용자 에이전트는 이러한 멤버를 사용하여 운영체제에서 웹 앱의 아이콘을 사용할 때 표시할 컨텍스트 메뉴를 구성할 수 있습니다. 사용자가 운영체제 메뉴에서 바로가기를 실행할 때, 사용자 에이전트는 실행해야 합니다 바로가기 실행.

3.1 name 멤버

바로가기 항목의 name 멤버는 string이며, 컨텍스트 메뉴에 사용자에게 일반적으로 표시되는 바로가기의 이름을 나타냅니다.

name 멤버는 지역화 가능한 멤버입니다.

3.2 short_name 멤버

바로가기 항목의 short_name 멤버는 string 타입이며, 바로가기 이름의 짧은 버전을 나타냅니다. 전체 이름을 표시할 공간이 부족할 때 사용됩니다.

short_name 멤버는 지역화 가능한 멤버입니다.

3.3 description 멤버

바로가기 항목의 description 멤버는 string 타입이며, 개발자가 바로가기에 대한 목적을 설명할 수 있도록 합니다. 사용자 에이전트는 이 정보를 접근성 기술에 노출할 수 있습니다.

description 멤버는 지역화 가능한 멤버입니다.

3.4 url 멤버

바로가기 항목의 url 멤버는 처리된 매니페스트의 범위 내에 있는 URL로, 관련 바로가기가 활성화될 때 열립니다.

3.5 icons 멤버

바로가기 항목의 icons 멤버는 다양한 컨텍스트에서 바로가기를 상징적으로 표현하는 이미지 목록입니다.

icons 멤버는 지역화 가능한 멤버입니다.

3.6 바로가기 실행

바로가기 항목 shortcut이 manifest와 함께 호출되면, 웹 애플리케이션 실행 단계를 manifest와 shortcut.url로 실행합니다.

3.7 바로가기 항목 처리

바로가기 처리는 ordered map item, URL manifest URL, URL scope, 그리고 text-direction defaultDirection을 입력으로 받아 다음과 같이 동작합니다:

  1. 다음 조건 중 하나라도 해당하면 실패 반환:
  2. url을 파싱 item["url"]에 manifest URL을 base URL로 하여 생성.
  3. url이 실패면 실패 반환.
  4. url이 범위 내가 아니면 실패 반환.
  5. shortcut을 ordered map «[ "url" → url, "name" → item["name"] ]»로 설정.
  6. *_localized 텍스트 멤버 처리를 item, shortcut, "name_localized", 그리고 defaultDirection에 적용.
  7. "short_name"이 존재하고, item["short_name"]이 string이면, set shortcut["short_name"]을 item["short_name"]으로 설정.
  8. *_localized 텍스트 멤버 처리를 item, shortcut, "short_name_localized", 그리고 defaultDirection에 적용.
  9. "description"이 존재하고, item["description"]이 string이면, set shortcut["description"]을 item["description"]으로 설정.
  10. *_localized 텍스트 멤버 처리를 item, shortcut, "description_localized", 그리고 defaultDirection에 적용.
  11. 이미지 리소스 처리를 item["icons"], shortcut, manifest URL, 그리고 "icons"에 적용.
  12. *_localized 이미지 리소스 멤버 처리를 item, shortcut, "icons_localized", 그리고 manifest URL에 적용.
  13. shortcut 반환.

4. 설치 가능한 웹 애플리케이션

모든 웹사이트는 설치 가능한 웹 애플리케이션입니다.

사용자 에이전트는 최종 사용자가 웹 애플리케이션을 자신의 기기에 설치할 수 있도록 하는 방법을 제공할 수 있으며, 사용자가 매니페스트의 멤버가 적용된 새로운 최상위 브라우징 컨텍스트를 인스턴스화할 수 있게 합니다.

웹 애플리케이션이 설치되면 설치된 웹 애플리케이션으로 간주됩니다. 즉, 매니페스트의 멤버 또는 기본값이 웹 애플리케이션의 최상위 브라우징 컨텍스트에 적용됩니다. 이는 기존 북마크와 구별되며, 기존 북마크에서 웹 페이지를 열면 매니페스트의 속성이 적용되지 않습니다.

Note

예를 들어, 설치를 지원하는 사용자 에이전트에서는 웹 애플리케이션이 홈 화면, 런처, 시작 메뉴 등에서 라벨이 붙은 아이콘처럼 표시되고 실행될 수 있습니다. 웹 애플리케이션 실행 시, 매니페스트는 최상위 브라우징 컨텍스트에 적용되며, 시작 URL이 로드되기 전에 적용됩니다. 이를 통해 사용자 에이전트는 매니페스트의 관련 값을 적용할 수 있으며, 웹 애플리케이션의 표시 모드나 화면 방향을 변경할 수 있습니다. 또는, 사용자 에이전트가 자체적으로 북마크 목록에 웹 앱을 설치할 수도 있습니다.

4.1 애플리케이션 이름

애플리케이션 이름은 name 또는 short_name 멤버에서 파생됩니다. 사용자 에이전트는 먼저 각 *_localized 멤버에서 지역화된 값을 해석해야 합니다.

name 멤버 또는 short_name 멤버가 없거나 비어 있거나 타입이 잘못된 경우, 사용자 에이전트는 name 멤버를 short_name의 대체로, 또는 short_name 멤버를 name의 대체로 사용할 수 있습니다.

name와 short_name 멤버가 모두 없거나 비어 있거나 타입이 잘못된 경우, 사용자 에이전트는 Document에서 적절한 대체 값을 찾을 수 있습니다(예: application-name을 name 또는 short_name 대신 사용). 또는, 사용자 에이전트는 플랫폼 규칙에 따라 기본 이름(예: "Untitled")을 지정해야 하며, 최종 사용자가 애플리케이션 이름을 직접 입력하도록 허용할 수도 있습니다.

name와 short_name 멤버가 모두 있는 경우, 구현체에서 사용 공간에 적합한 멤버를 선택합니다(예: 아이콘 아래 공간에는 short_name가 더 적합할 수 있음).

4.2 웹 애플리케이션 실행

운영체제 또는 사용자 에이전트의 재량에 따라, 웹 애플리케이션 실행 단계를 처리된 매니페스트로 실행합니다.

Note

이는 사용자가 앱 실행 UI(예: 홈 화면, 런처, 시작 메뉴)에서 설치된 웹 앱을 선택할 때 일반적으로 발생합니다.

웹 애플리케이션 실행 단계는 다음 알고리즘에 의해 정의됩니다. 이 알고리즘은 처리된 매니페스트 manifest, 선택적 URL target URL, 선택적 POST resource POST resource를 입력으로 받아 애플리케이션 컨텍스트를 반환합니다.

target URL이 주어진 경우, 반드시 매니페스트의 범위 내에 있어야 합니다.

다른 명세는 이 알고리즘을 자체 알고리즘으로 대체할 수 있습니다. 이 대체는 웹 애플리케이션 실행의 모든 호출에 적용됩니다.

Note

이 알고리즘은 실험적 launch_handler manifest 필드를 통해 웹 앱 실행 동작을 구성할 수 있도록 대체할 수 있습니다. 대체 알고리즘은 기본적으로 새로운 애플리케이션 컨텍스트 생성을 호출하지만, 특정 조건에서는 다르게 동작합니다.

  1. 새로운 애플리케이션 컨텍스트 생성 단계를 manifest, target URL, POST resource로 실행한 결과 반환.

새로운 애플리케이션 컨텍스트 생성 단계는 다음 알고리즘에 의해 정의됩니다. 이 알고리즘은 처리된 매니페스트 manifest, 선택적 URL target URL, 선택적 POST resource POST resource를 입력으로 받아 애플리케이션 컨텍스트를 반환합니다.

  1. target URL이 주어지지 않았다면, target URL을 start URL로 설정.
  2. traversable을 새 최상위 traversable 생성 단계를 target URL, POST resource로 실행한 결과로 설정.
  3. browsing context를 traversable의 active browsing context로 설정.
  4. manifest 적용을 manifest, browsing context에 실행.
  5. browsing context 반환.

4.3 프라이버시 및 보안 고려 사항

웹 애플리케이션을 설치할 수 있는 UI에서는 아이콘, 이름, start URL, origin 등 정보를 확인할 수 있도록 하는 것이 권장됩니다. 이는 최종 사용자가 웹 애플리케이션 설치 전에 정보를 확인하고, 필요시 수정할 수 있도록 하며, 다른 웹 앱을 모방하는지(예: 예상치 못한 아이콘/이름 사용) 판별할 기회를 제공합니다.

사용자 에이전트는 다른 애플리케이션이 시스템에 설치된 앱 목록을 파악하지 못하도록(권장됨) 해야 합니다(예: 캐시의 타이밍 공격 방지). 예를 들어, 설치 후 매니페스트에서 연결된 리소스(아이콘 등)를 사용자 에이전트 캐시에서 무효화하거나 일반 웹 탐색용 캐시와 별도의 캐시를 사용할 수 있습니다.

4.4 제거

사용자 에이전트는 설치된 웹 애플리케이션을 사용자가 제거할 수 있는 메커니즘을 제공해야 합니다.

제거 시점에, 애플리케이션과 관련된 기타 영구 데이터 및 설정(권한, 영구 저장소 등)을 사용자가 취소(revoke)할 기회를 제공하는 것이 권장됩니다.

6. 표시 모드

표시 모드는 웹 애플리케이션이 OS 내에서 어떻게 표시되는지를 나타냅니다(예: 전체화면 등). 표시 모드는 플랫폼의 UI 메타포와 기능에 대응하며, 실제 UI 규칙은 참고용이며 구현자가 해석에 자유를 갖습니다.

이 명세는 다음 표시 모드를 정의합니다:

fullscreen
브라우저 UI 요소를 숨기고, 사용 가능한 전체 화면을 모두 차지하여 웹 애플리케이션을 엽니다.
standalone
웹 애플리케이션을 독립 실행형 네이티브 앱처럼 보이고 동작하도록 엽니다. 별도 창, 런처 아이콘 등 포함. 이 모드에서 사용자 에이전트는 URL 바 등 표준 브라우저 UI를 제외하지만, 상태 바나 시스템 뒤로가기 버튼 등 시스템 UI는 포함할 수 있습니다.
minimal-ui
standalone과 비슷하지만, 최소한의 네비게이션 UI(뒤로, 앞으로, 새로고침, 주소 보기 등)를 제공합니다. 사용자 에이전트는 "공유", "인쇄" 등 플랫폼별 UI 요소도 추가할 수 있습니다.
browser (기본값)
플랫폼의 하이퍼링크 열기 규칙(예: 브라우저 탭, 새 창)에 따라 웹 애플리케이션을 엽니다.
Note

fullscreen 표시 모드는 Fullscreen API Standard와 독립적으로 동작합니다. 표시 모드는 브라우저 창의 전체화면 상태를, API는 뷰포트 내 요소의 전체화면을 제어합니다. 따라서 표시 모드가 fullscreen이어도 document.fullScreenElement는 null이고, fullscreenEnabled는 false일 수 있습니다.

사용자 에이전트가 특정 표시 모드를 적용하면, 해당 최상위 브라우징 컨텍스트의 기본 표시 모드가 되며, 창 이동 시에도 사용됩니다. 사용자 에이전트는 보안이나 기타 이유로 기본 표시 모드를 변경할 수 있으며, 사용자가 다른 표시 모드로 전환할 수 있는 수단을 제공할 수 있습니다.

display 멤버가 없거나 유효하지 않으면, 사용자 에이전트는 browser 표시 모드를 기본 표시 모드로 사용합니다. 따라서 사용자 에이전트는 browser 표시 모드를 반드시 지원해야 합니다.

모든 표시 모드는 폴백 체인이 있으며, 이는 표시 모드들의 리스트입니다. 폴백 체인은 다음과 같습니다:

  1. browser는 «».
  2. minimal-ui는 « "browser" ».
  3. standalone는 « "minimal-ui", "browser" ».
  4. fullscreen는 « "standalone", "minimal-ui", "browser" ».

웹 앱의 선택된 표시 모드 결정 단계 알고리즘은 다음과 같습니다. 처리된 매니페스트 manifest를 받아서 표시 모드를 반환합니다.

  1. processing extension-point: 이 지점에서 기타 지원되는 표시 모드 처리.
  2. 사용자 에이전트가 manifest["display"]를 지원하면, manifest["display"] 반환.
  3. 각 fallback_mode를 폴백 체인에서 반복:
    1. 사용자 에이전트가 fallback_mode를 지원하면 fallback_mode 반환.
Note

위 반복문은 항상 값을 반환합니다. 왜냐하면 모든 모드의 browser가 폴백 체인에 포함되어 있고, 모든 사용자 에이전트는 browser 표시 모드를 지원해야 하기 때문입니다.

표시 모드 리스트는 리스트 « "fullscreen", "standalone", "minimal-ui", "browser" »입니다.

사용자 에이전트는 웹 애플리케이션에 적용된 표시 모드를 display-mode 미디어 특성으로 반영해야 합니다.

Note

사용자 에이전트는 실제 적용 중인 표시 모드를 display-mode 미디어 특성(CSS, JS 접근 가능)으로 노출합니다. 이 미디어 특성은 매니페스트 적용 여부와 관계없이 반영될 수 있습니다. 예를 들어 사용자가 페이지를 전체화면으로 전환하면, 사용자 에이전트는 CSS/스크립트에 이를 반영합니다.

7. 개인정보 및 보안 고려사항

이 명세는 직접적으로 고가치 데이터를 다루지 않습니다. 하지만 설치된 웹 애플리케이션과 그 데이터는 "고가치"로 간주될 수 있습니다(특히 개인정보 관점에서).

매니페스트 형식은 JSON이며 [UNICODE]로 인코딩됩니다. 따라서 [JSON]과 [UNICODE-SECURITY]에서 설명된 보안 고려사항이 적용됩니다. 또한, 개발자가 매니페스트에 자유로운 데이터를 포함하는 것을 막을 방법이 없으므로, 구현자들은 제약이 없는 멤버 타입 값에 대해 서비스 거부 공격 방지, 메모리 고갈 방지, 플랫폼별 한계 대응 등을 위해 자체적인 제한을 두어야 합니다.

웹 애플리케이션은 일반적으로 ECMAScript, HTML, CSS 파일 및 기타 미디어를 포함하며, 샌드박스 환경에서 실행됩니다. 따라서 구현자들은 지원하는 타입에 대한 보안 영향을 인지해야 합니다. 특히, 다음 명세들에서 설명하는 보안 고려사항을 반드시 참고해야 합니다: [CSS-MIME], [ECMAScript-MIME], [HTML].

웹 애플리케이션은 로컬 디바이스와 원격 호스트 모두와 동시 상호작용할 수 있는 콘텐츠를 포함할 수 있으므로, 구현자는 개인정보가 원격 호스트에 노출되는 것에 대한 영향을 고려해야 합니다. 방어 및 심층 보호 조치는 구현 책임이며, 본 명세에서 구체적으로 규정하지 않습니다. 하지만 이러한 조치 설계 시 사용자가 정보 공유를 인지할 수 있도록 하고, 권한 취소 인터페이스에 쉽게 접근할 수 있게 하는 것이 바람직합니다.

본 명세는 매니페스트의 일부 멤버에서 URL 선언을 허용하므로, 구현자는 [URL] 명세에서 논의한 보안 고려사항도 참고해야 합니다. 매니페스트에 포함된 IRIs 및 IDNA 주소를 표시하려는 구현체는 [UNICODE-SECURITY]에서 제시한 보안 권고를 따르는 것이 강력히 권장됩니다.

개발자는 [CSP3] 명세 전반에서 논의된 보안 고려사항을 인지해야 하며, 특히 data:를 매니페스트 인라인 목적으로 유효한 소스로 허용하는 것과 관련해 주의해야 합니다. 이를 허용하면 매니페스트를 문서 내에 직접 포함시켜 XSS 공격이 가능해질 수 있으므로, 완전히 피하는 것이 바람직합니다.

웹 애플리케이션을 설치할 수 있는 UI는 아이콘, 이름, start URL, 오리진 등 정보를 확인할 수 있도록 하는 것이 권장됩니다. 이는 최종 사용자가 설치 전 웹 애플리케이션의 정보를 확인하고, 필요시 수정할 수 있도록 하기 위함입니다. 또한, 웹앱이 다른 앱을 모방하는지(예: 예상치 못한 아이콘/이름 사용) 판별할 기회를 제공합니다.

사용자 에이전트는 다른 애플리케이션이 시스템에 설치된 앱 목록을 파악하지 못하도록(권장됨) 해야 합니다(예: 캐시의 타이밍 공격 방지). 예를 들어, 설치 후 매니페스트에서 연결된 리소스(아이콘 등)를 사용자 에이전트 캐시에서 무효화하거나, 일반 웹 탐색용 캐시와 별도의 캐시를 사용할 수 있습니다.

바로가기 url이 브라우저 외부에서 앱이 실행된 것처럼 보이게(예: "url": "/task/?from=homescreen") 구성될 수 있습니다. 또한 개발자가 url에 서버 할당 UUID와 같이 사용자를 고유하게 식별할 수 있는 문자열을 인코딩할 수도 있습니다. 이는 지문/개인정보에 민감한 정보이며, 사용자가 인지하지 못할 수 있습니다.

웹 애플리케이션이 실행 중일 때, 사용자 에이전트는 최종 사용자가 오리진, 시작/현재 URL, 승인된 권한, 아이콘 등 일반 정보를 확인할 수 있는 수단을 제공하는 것이 권장됩니다. 이러한 정보 노출 방식은 구현자 재량입니다.

또한, 매니페스트를 적용할 때 display mode가 "browser"가 아닌 경우, 사용자 에이전트는 사용자가 웹 브라우저의 일반 탐색 컨텍스트를 벗어났음을 명확히 알려주는 것이 권장됩니다. 이상적으로는 앱 실행 또는 전환이 호스트 플랫폼에서 다른 애플리케이션을 실행/전환하는 방식과 일관되게 수행되어야 합니다. 예를 들어, 길고 명확한 애니메이션 전환, "애플리케이션 X 실행 중" 음성 안내 등이 있습니다.

display 멤버는 오리진이 사용자 에이전트의 네이티브 UI 일부를 제어할 수 있게 합니다. 전체화면을 차지한 후, 다른 앱의 UI를 흉내낼 수도 있습니다. 이는 'display-mode' 미디어 특성 [MEDIAQUERIES-5]을 통해서도 가능하며, 스크립트는 이를 통해 웹앱의 표시 모드를 알 수 있습니다.

A. IANA 고려사항

mime 타입 application/manifest+json 은 애플리케이션 매니페스트 미디어 타입입니다. mime 타입과 .webmanifest 파일 확장자는 인터넷 네임버 할당 기관(IANA)에 등록되어 있습니다.

A.1 미디어 타입 등록

매니페스트가 전송되는 프로토콜이 [MIME-TYPES] 명세(예: HTTP)를 지원한다면, 매니페스트에 애플리케이션 매니페스트 미디어 타입을 지정하는 것이 권장됩니다.

타입 이름:
application
서브타입 이름:
manifest+json
필수 파라미터:
N/A
선택 파라미터:
N/A
인코딩 고려사항:
application/json과 동일 ([RFC7159] section 8.1)
개인정보 및 보안 고려사항:
7. 개인정보 및 보안 고려사항 참고.
이 MIME 타입을 사용하는 애플리케이션:
웹 브라우저
추가 정보:
매직 넘버:
N/A
파일 확장자:
.webmanifest
매킨토시 파일 타입 코드:
TEXT
추가 정보 문의 담당자:
Web Applications Working Group에 문의 가능. public-webapps@w3.org.
의도된 사용 범위:
COMMON
사용 제한:
없음
작성자:
W3C Web Applications Working Group.
변경 관리:
W3C.

B. 적합성

비규범으로 표시된 섹션뿐 아니라, 이 명세서의 모든 저작 지침, 다이어그램, 예시, 노트는 비규범적입니다. 그 외 모든 내용은 규범적입니다.

이 문서에서 MAY, MUST, MUST NOT, OPTIONAL, RECOMMENDED, SHOULD, SHOULD NOT와 같은 키워드는 BCP 14 [RFC2119] [RFC8174] 에서 설명된 대로 해석되어야 하며, 반드시 대문자로 표기된 경우에만 해당합니다.

이 명세에 적합성을 주장할 수 있는 제품 클래스는 하나뿐입니다: user agent입니다.

Note

이 명세는 주로 웹 브라우저를 대상으로 하지만, 다른 소프트웨어도 적합하게 구현할 수 있습니다. 예를 들어, 검색 엔진이나 크롤러는 매니페스트를 찾아 처리하여 설치 가능한 웹앱 카탈로그를 구축할 수 있습니다.

B.1 확장성

이 섹션은 비규범적입니다.

이 명세는 확장 가능하도록 설계되었습니다. 다른 명세들에서 매니페스트에 새로운 멤버를 정의하는 것이 권장됩니다. 단, 이 경우 반드시 본 명세서의 컨벤션을 따르십시오. 특히, processing extension-point를 이용하여 매니페스트 처리 단계에 연결하세요. 또한, 본 명세서에서 제시한 방식대로 해당 멤버의 처리 단계를 명확히 명시해야 합니다. 이렇게 하면 플랫폼의 일관성을 유지할 수 있습니다.

커뮤니티가 확장 기능을 쉽게 찾을 수 있도록 Extensions Registry에 추가해 주십시오.

새로운 멤버를 지정할 때, 본 명세에서 정의된 내용을 오버라이드하거나 monkey patch하지 마십시오. 또한, 멤버가 다른 멤버보다 먼저 혹은 나중에 처리된다고 가정하지 마십시오. 새로운 멤버와 그 처리 과정은 원자적이고 독립적으로 유지해야 합니다. 구현체는 인식하지 못하거나 지원하지 않는 멤버를 자유롭게 무시할 수 있습니다.

에디터가 임시로 구현체를 돕기 위해 이 명세를 패치하려면, 이슈를 등록하여 커뮤니티에 알리십시오.

B.1.1 독점 매니페스트 멤버

이 섹션은 비규범적입니다.

독점 확장은 바람직하지 않지만, 현실적으로 피할 수 없습니다. 사용자 에이전트가 본 문서에 정의되지 않은 매니페스트 JSON 멤버를 해석하기로 선택한다면 주의해서 구현해야 합니다.

독점 확장을 추가하는 구현자는 표준이 될 수 있을지 고려해야 합니다(즉, 다른 플랫폼의 두 번째 사용자 에이전트도 해당 멤버를 쓸 수 있는지). 그렇다면 API를 벤더 중립적으로 설계하고 표준으로 제안해주십시오. 새 멤버가 진정으로 독점적이라면, 해당 에코시스템의 약어로 접두어를 붙여 이름 충돌을 피하십시오.

나중에 표준이 되면 제거할 목적의 벤더 프리픽스(접두어)는 사용하지 마십시오(영구적으로 남는 경우가 많음). 지금과 미래 모두 합리적인 프리픽스만 사용하십시오.

독점 확장도 Extensions Registry에 추가해주십시오. 이를 통해 커뮤니티가 벤더/웹 커뮤니티가 정의하고 문서화한 확장을 추적할 수 있습니다. 주기적으로 표준화 여부를 검토합니다.

아래는 가상의 독점 확장 예시입니다.

Example 13: 독점 확장 예시 
{
  ...
  "kpl_fancy_feature": "some/url/img",
  "gmpc_awesome_thing": { ... },
  "blitzly_site_verification": "KEY_9864D0966935"
  ...
}
Note

이 예시에서는 일부 외부 사이트나 서비스의 이름(가상)이 접두어로 사용되었습니다. 이는 브라우저나 브라우저 벤더의 이름이 아니라, 독점 서비스의 접두어입니다.

C. 애플리케이션 정보

이 섹션은 비규범적입니다.

웹 애플리케이션 매니페스트의 여러 멤버는 디지털 스토어, 설치 대화상자, 또는 웹앱이 마케팅/배포되는 기타 영역에서 어떻게 표시될지를 위한 추가 메타데이터를 제공합니다. 이러한 요구를 더 잘 지원하기 위해, 아래 멤버들은 Web App Manifest - Application Information로 이동되었습니다:

E. JSON 스키마

이 섹션은 비규범적입니다.

매니페스트 문서 검증에 관심있는 개발자는 매니페스트 형식용 비공식 JSON 스키마를 schemastore.org에서 확인할 수 있습니다. 이 스키마는 Apache 2.0으로 라이선스되며, Mads Kristensen가 관리합니다. 문제를 발견하면 이슈 등록 바랍니다(GitHub의 SchemaStore 저장소).

Note: 웹 매니페스트 JSON 스키마

F. 국제화

이 섹션은 비규범적입니다.

저자는 매니페스트 콘텐츠를 다음 중 한 방법으로 지역화하는 것이 기대됩니다:

매니페스트 내 지역화 값:
저자는 지역화 값을 지역화 가능한 멤버에 제공할 수 있습니다. 사용자 에이전트는 모든 지역화 값을 운영체제에 전달합니다. 사용자가 OS에서 locale을 변경하면, OS가 설치된 웹 애플리케이션의 업데이트된 지역화 값을 표시할 수 있습니다.
언어 동적 설정:
예를 들어, 사용자의 선호 언어를 묻고 그에 따라 문서에 연결된 매니페스트 링크를 동적으로 추가/교체할 수 있습니다(예: "manifest.php?lang=fr"와 같이).
서버에서 콘텐츠 협상, 지오타게팅 등 사용:
웹앱을 호스팅하는 서버는 지오타게팅이나 콘텐츠 협상(예: HTTP "Accept-Language" 헤더 [RFC9110], 또는 커스텀 HTTP 헤더)으로 사용자의 언어를 미리 결정할 수 있습니다.

위 방법을 고려할 때, 사용자의 언어 선호도는 개인정보와 관련되어 있으므로 주의가 필요합니다: 사용자가 웹앱에 명시적으로 언어 선호도를 지정한 경우(단순히 UA 기본 언어 설정 사용이 아님), 이를 네트워크상에서 평문으로 전송하는 것은 부적절합니다. 이는 사용자의 개인정보를 노출시키기 때문입니다. 따라서 [TLS]를 사용하여 웹앱의 감시 위험을 줄일 것을 권장합니다([RFC7258]).

G. 사용 사례 및 요구사항

본 문서는 설치 가능한 웹앱의 사용 사례 및 요구사항을 다루고자 합니다.

H. 이슈 요약

이 명세서에는 이슈가 없습니다.

I. 변경 로그

이 섹션은 비규범적입니다.

아래는 First Public Working Draft 이후 주요 변경 사항입니다:

J. 감사의 글

이 섹션은 비규범적입니다.

본 문서는 [HTML] 명세의 라이선스에 따라 해당 명세의 텍스트를 재사용했습니다.

Dave Raggett와 Dominique Hazael-Massieux는 HTML5Apps 프로젝트를 통해 이 명세에 기여했습니다.

아이콘 예제 이미지에 대해 Claudio Gomboli에게 감사드립니다.

Indiana University Bloomington의 보안 연구자들은 범위 밖 네비게이션과 관련된 잠재적 위험을 보고하여 이 명세에 기여했습니다.

K. 색인

K.1 이 명세에서 정의한 용어

K.2 참조로 정의된 용어

L. 참고문헌

L.1 규범 참고문헌

[accname-1.2]
접근 가능한 이름 및 설명 계산 1.2. Bryan Garaventa; Melanie Sumner. W3C. 2025년 10월 23일. W3C 워킹 드래프트. URL: https://www.w3.org/TR/accname-1.2/
[BCP47]
언어 식별 태그. A. Phillips, Ed.; M. Davis, Ed. IETF. 2009년 9월. 베스트 커런트 프랙티스. URL: https://www.rfc-editor.org/rfc/rfc5646
[CSP3]
콘텐츠 보안 정책 3단계. Mike West; Antonio Sartori. W3C. 2025년 11월 6일. W3C 워킹 드래프트. URL: https://www.w3.org/TR/CSP3/
[css-color-4]
CSS 색상 모듈 4단계. Chris Lilley; Tab Atkins Jr.; Lea Verou. W3C. 2025년 4월 24일. CRD. URL: https://www.w3.org/TR/css-color-4/
[CSS-MIME]
text/css 미디어 타입. H. Lie; B. Bos; C. Lilley. IETF. 1998년 3월. 정보 제공용. URL: https://www.rfc-editor.org/rfc/rfc2318
[css-syntax-3]
CSS 구문 모듈 3단계. Tab Atkins Jr.; Simon Sapin. W3C. 2021년 12월 24일. CRD. URL: https://www.w3.org/TR/css-syntax-3/
[dom]
DOM 표준. Anne van Kesteren. WHATWG. 라이빙 스탠다드. URL: https://dom.spec.whatwg.org/
[ECMA-402]
ECMAScript 국제화 API 명세. Ecma International. URL: https://tc39.es/ecma402/
[ECMAScript-MIME]
스크립팅 미디어 타입. B. Hoehrmann. IETF. 2006년 4월. 정보 제공용. URL: https://www.rfc-editor.org/rfc/rfc4329
[fetch]
Fetch 표준. Anne van Kesteren. WHATWG. 라이빙 스탠다드. URL: https://fetch.spec.whatwg.org/
[HTML]
HTML 표준. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. 라이빙 스탠다드. URL: https://html.spec.whatwg.org/multipage/
[image-resource]
이미지 리소스. Aaron Gustafson; Rayan Kanso; Marcos Caceres. W3C. 2021년 6월 4일. W3C 워킹 드래프트. URL: https://www.w3.org/TR/image-resource/
[infra]
Infra 표준. Anne van Kesteren; Domenic Denicola. WHATWG. 라이빙 스탠다드. URL: https://infra.spec.whatwg.org/
[JSON]
자바스크립트 객체 표기법(JSON) 데이터 교환 형식. T. Bray, Ed. IETF. 2017년 12월. 인터넷 표준. URL: https://www.rfc-editor.org/rfc/rfc8259
[MEDIAQUERIES-5]
미디어 쿼리 5단계. Dean Jackson; Florian Rivoal; Tab Atkins Jr.; Daniel Libby. W3C. 2021년 12월 18일. W3C 워킹 드래프트. URL: https://www.w3.org/TR/mediaqueries-5/
[MIME-TYPES]
멀티퍼포스 인터넷 메일 확장(MIME) 파트2: 미디어 타입. N. Freed; N. Borenstein. IETF. 1996년 11월. 드래프트 스탠다드. URL: https://www.rfc-editor.org/rfc/rfc2046
[permissions]
권한. Marcos Caceres; Mike Taylor. W3C. 2025년 10월 6일. W3C 워킹 드래프트. URL: https://www.w3.org/TR/permissions/
[RFC2119]
RFC에서 요구 수준을 나타내는 핵심 용어. S. Bradner. IETF. 1997년 3월. 베스트 커런트 프랙티스. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC7159]
자바스크립트 객체 표기법(JSON) 데이터 교환 형식. T. Bray, Ed. IETF. 2014년 3월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc7159
[RFC8174]
RFC 2119 핵심 용어의 대문자/소문자 애매함. B. Leiba. IETF. 2017년 5월. 베스트 커런트 프랙티스. URL: https://www.rfc-editor.org/rfc/rfc8174
[SCREEN-ORIENTATION]
스크린 방향. Marcos Caceres. W3C. 2025년 10월 21일. W3C 워킹 드래프트. URL: https://www.w3.org/TR/screen-orientation/
[UAX9]
유니코드 양방향 알고리즘. Manish Goregaokar मनीष गोरेगांवकर; Robin Leroy. Unicode Consortium. 2025년 8월 13일. 유니코드 표준 부록 #9. URL: https://www.unicode.org/reports/tr9/tr9-51.html
[UNICODE]
유니코드 표준. Unicode Consortium. URL: https://www.unicode.org/versions/latest/
[UNICODE-SECURITY]
유니코드 보안 고려 사항. Mark Davis; Michel Suignard. Unicode Consortium. 2014년 9월 19일. 유니코드 기술 보고서 #36. URL: https://www.unicode.org/reports/tr36/tr36-15.html
[URL]
URL 표준. Anne van Kesteren. WHATWG. 라이빙 스탠다드. URL: https://url.spec.whatwg.org/
[UTS55]
유니코드 소스 코드 처리. Robin Leroy; Mark Davis. Unicode Consortium. 2024년 1월 29일. 유니코드 기술 표준 #55. URL: https://www.unicode.org/reports/tr55/tr55-5.html

L.2 비규범 참고문헌

[FULLSCREEN]
전체 화면 API 표준. Philip Jägenstedt. WHATWG. Living Standard. URL: https://fullscreen.spec.whatwg.org/
[i18n-glossary]
국제화 용어집. Richard Ishida; Addison Phillips. W3C. 2024년 10월 17일. W3C 워킹 그룹 노트. URL: https://www.w3.org/TR/i18n-glossary/
[manifest-app-info]
웹 앱 매니페스트 - 애플리케이션 정보. Aaron Gustafson. W3C. 2023년 8월 21일. W3C 워킹 그룹 노트. URL: https://www.w3.org/TR/manifest-app-info/
[mimesniff]
MIME 스니핑 표준. Gordon P. Hemsley. WHATWG. Living Standard. URL: https://mimesniff.spec.whatwg.org/
[RFC7258]
광범위한 모니터링은 공격이다. S. Farrell; H. Tschofenig. IETF. 2014년 5월. 베스트 커런트 프랙티스. URL: https://www.rfc-editor.org/rfc/rfc7258
[RFC9110]
HTTP 시맨틱스. R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed. IETF. 2022년 6월. 인터넷 표준. URL: https://httpwg.org/specs/rfc9110.html
[SERVICE-WORKERS-1]
Service Workers Nightly. Monica CHINTALA; Yoshisato Yanagisawa. W3C. 2025년 11월 26일. CRD. URL: https://www.w3.org/TR/service-workers/
[TLS]
전송 계층 보안(TLS) 프로토콜 버전 1.2. T. Dierks; E. Rescorla. IETF. 2008년 8월. 제안 표준. URL: https://www.rfc-editor.org/rfc/rfc5246
[webidl]
Web IDL 표준. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/