CSS 뷰포트 모듈 레벨 1

W3C 최초 공개 작업 초안,

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2024/WD-css-viewport-1-20240125/
최신 공개 버전:
https://www.w3.org/TR/css-viewport-1/
에디터스 드래프트:
https://drafts.csswg.org/css-viewport/
이전 버전:
역사:
https://www.w3.org/standards/history/css-viewport-1/
피드백:
CSSWG 이슈 저장소
CSSWG GitHub
명세 내 인라인
에디터:
Florian Rivoal (초청 전문가)
(Mozilla)
이전 에디터:
Matt Rakow (Microsoft)
(Opera Software)
(Adobe Systems)
(Opera Software)
이 명세에 대한 편집 제안:
GitHub 에디터

요약

이 명세서는 작성자가 CSS에서 초기 포함 블록의 기준이 되는 뷰포트의 크기, 확대 비율, 방향을 지정할 수 있는 방법을 제공합니다.

CSS는 구조화된 문서(예: HTML 및 XML)의 화면, 인쇄 등에서의 렌더링을 설명하는 언어입니다.

이 문서의 상태

이 섹션은 이 문서가 출판된 시점에 문서의 상태를 설명합니다. 현재 W3C 발행물 목록과 최신 버전의 기술 보고서는 W3C 기술 보고서 색인 https://www.w3.org/TR/에서 확인할 수 있습니다.

이 문서는 CSS 작업 그룹에 의해 최초 공개 작업 초안으로, 권고안 프로세스를 사용하여 발행되었습니다. 최초 공개 작업 초안으로의 발행은 W3C 및 회원들의 보증을 의미하지 않습니다.

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

피드백은 GitHub 이슈로 등록(권장), 제목에 사양 코드 “css-viewport”를 포함하여, 예시와 같이 남겨주세요: “[css-viewport] …코멘트 요약…”. 모든 이슈와 코멘트는 아카이브됩니다. 또는 (아카이브됨) 공개 메일링 리스트 www-style@w3.org로 보낼 수도 있습니다.

이 문서는 2023년 11월 3일 W3C 프로세스 문서의 적용을 받습니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성되었습니다. W3C는 해당 그룹 결과물과 관련하여 공개된 특허 공개 목록을 유지하며, 해당 페이지에는 특허 공개 방법에 대한 안내도 있습니다. 특정 특허가 필수 청구항을 포함한다고 판단하는 자는 W3C 특허 정책 6절에 따라 공개해야 합니다.

1. 소개

이 섹션은 규범적이지 않습니다.

CSS 2.1 [CSS21]에서는 초기 포함 블록연속 미디어의 경우 뷰포트의 크기로 정의합니다. 뷰포트는 일반적으로 디스플레이보다 크지 않으므로, 휴대폰이나 태블릿과 같은 작은 스크린의 기기에서는 데스크탑이나 노트북과 같은 큰 기기보다 작은 뷰포트가 제공됩니다.

안타깝게도, 많은 문서들이 역사적으로 더 큰 뷰포트를 기준으로 설계되어, 작은 뷰포트에서는 다양한 버그가 발생하는 경우가 흔합니다. 여기에는 의도하지 않은 레이아웃 줄바꿈, 잘린 콘텐츠, 어색한 스크롤 영역, 스크립트 오류 등이 포함됩니다. 이러한 문제를 피하기 위해 모바일 브라우저들은 일반적으로 데스크탑 브라우저의 일반적인 윈도우 크기(보통 980-1024px)를 모방한 고정된 초기 포함 블록의 너비를 사용합니다. 결과적으로 레이아웃은 이용 가능한 화면 크기에 맞게 축소되어 표시됩니다.

이 방식은 위 문제를 완화하지만, 축소됨에 따라 CSS 픽셀의 크기가 CSS 2.1에서 권고된 것보다 더 작아집니다. 따라서 사용자는 콘텐츠를 편하게 보기 위해 확대(zoom)가 필요할 수 있습니다.

하지만 작은 뷰포트에서도 잘 작동하도록 설계된 사이트에서는 이러한 완화 조치가 불필요합니다.

이 명세서는 구현 관점에서 작성되어 읽기에 다소 어렵다고 여겨질 수 있습니다. 다양한 독자층을 위해 더 이해하기 쉽게 하려면 상당한 편집 작업이 필요합니다. 또한 여러 js API가 참조하는 뷰포트가 무엇인지 명확하게 해야 합니다. 이러한 이슈에 대한 더 좋은 논의는 이 블로그 글(ppk)을 참조하세요.

이 명세와 관련 명세들에 대한 여러 이슈들이 이 보고서에 정리되어 있습니다.

2. 뷰포트

CSS 2.1에서 뷰포트연속 미디어를 위한 사용자 에이전트의 기능이며 연속 미디어의 초기 포함 블록을 설정하는 데 사용됩니다. 페이지 미디어의 경우, 초기 포함 블록은 페이지 영역을 기반으로 합니다. 페이지 영역은 @page 규칙으로 설정할 수 있습니다.

이 명세는 사용자 에이전트(UA)가 제공하는 뷰포트의 크기를 재정의할 방법을 도입합니다. 따라서 초기 뷰포트실제 뷰포트의 차이를 정의해야 합니다.

초기 뷰포트
이것은 UA의 윈도우(또는 표시 영역)에 의해 주어진 기본 뷰포트가 UA 또는 작성자 스타일로 재정의되기 전을 의미합니다. 초기 뷰포트의 크기는 윈도우 또는 표시 영역의 크기에 따라 달라집니다.
실제 뷰포트
이것은 뷰포트 <meta> 태그 처리 후의 뷰포트입니다.

실제 뷰포트를 레이아웃 뷰포트로 하고, visual viewport를 정의하세요.

만약 실제 뷰포트가 윈도우나 표시 영역 안에 들어가지 못하는 경우(즉, 실제 뷰포트초기 뷰포트보다 크거나 확대 비율로 인해 실제 뷰포트의 일부만 보이는 경우), UA는 스크롤 또는 패닝 메커니즘을 제공해야 합니다.

문서의 기본 방향이 ltr인 경우 최초에는 실제 뷰포트와 윈도우(표시 영역)의 좌상단 모서리가 정렬되는 것이 권장됩니다. rtl인 경우에는 우상단 모서리가 정렬되어야 합니다. 문서의 기본 방향은 HTML 또는 XHTML 문서에서 첫 번째 <BODY> 요소의 direction 속성의 계산값으로 정의됩니다. 다른 문서 유형에서는 루트 요소의 계산된 direction 값이 사용됩니다.

3. 뷰포트 <meta> 요소

명세 추가 필요

3.1. 속성

뷰포트 <meta> 요소에서 인식되는 속성들은 다음과 같습니다:

3.2. 파싱 알고리즘

아래는 아이폰의 Safari로 테스트한 <meta> 태그의 content 속성 파싱 알고리즘입니다. 테스트는 iPhone OS 4가 탑재된 iPod touch로 진행했습니다. 브라우저 UA 문자열: "Mozilla/5.0 (iPod; U; CPU iPhone OS 4_0 like Mac OS X; en-us) AppleWebKit/532.9 (KHTML, like Gecko) Version/4.0.5 Mobile/8A293 Safari/6531.22.7". 사용된 의사코드 표기는 [Algorithms]에서 사용하는 형식을 따릅니다.

whitespace 클래스에는 다음 문자가 포함됩니다 (ascii):

속성과 값 쌍의 구분자로, Safari 구현에서는 콤마(,)를 인식합니다. 일부 구현체는 콤마와 세미콜론(;)을 모두 지원합니다. 그래서 기존 콘텐츠에서는 콤마 대신 세미콜론을 사용하는 경우도 있습니다. 모든 UA에서 정상 동작을 보장하려면 저자는 콤마를 사용하는 것이 좋지만, 구현자는 기존 콘텐츠의 상호운용성을 위해 둘 다 지원할 수 있습니다.

separator 클래스에는 다음 문자가 포함됩니다 (ascii). 콤마가 기본 구분자이고 세미콜론은 선택적입니다:

Parse-Content(S)
i ← 1
while ilength[S]
  do while ilength[S] and S[i] in [whitespace, separator, '=']
    do ii + 1
  if ilength[S]
    then iParse-Property(S, i)

Parse-Property(S, i)
starti
while ilength[S] and S[i] not in [whitespace, separator, '=']
  do ii + 1
if i > length[S] or S[i] in [separator]
  then return i
property-nameS[start .. (i - 1)]
while ilength[S] and S[i] not in [separator, '=']
  do ii + 1
if i > length[S] or S[i] in [separator]
  then return i
while ilength[S] and S[i] in [whitespace, '=']
  do ii + 1
if i > length[S] or S[i] in [separator]
  then return i
starti
while ilength[S] and S[i] not in [whitespace, separator, '=']
  do ii + 1
property-valueS[start .. (i - 1)]
Set-Property(property-name, property-value)
return i

Set-Property나열된 속성 이름과 대소문자를 구분하지 않고 일치시킵니다. property-value 문자열의 해석 방법은 다음과 같습니다:

  1. property-value의 접두사가 strtod를 통해 숫자로 변환될 수 있으면, 그 값이 사용됩니다. 나머지 문자열은 무시됩니다.
  2. 위 방법으로 숫자로 변환할 수 없는 경우, 전체 property-value 문자열이 다음 문자열들과 대소문자 무시하고 비교됩니다: yes, no, device-width, device-height
  3. 만약 어떤 문자열과도 일치하지 않으면, 그 값은 알 수 없음이 됩니다.

3.3. extend-to-zoom

viewport meta 태그의 extend-to-zoom 동작 규정 필요

3.4. interactive-widget

visual viewport 정의를 CSSOM-View에서 이 명세로 이동 필요.

interactive-widget 속성은 인터랙티브 UI 위젯이 페이지 뷰포트에 미치는 영향을 지정합니다. 이 속성은 위젯이 뷰포트를 오버레이할지, 아니면 위젯이 표시될 때 뷰포트가 완전히 보이도록 축소할지를 정의합니다. 인터랙티브 UI 위젯은 사용자가 입력을 제공할 수 있도록 하는 임시 사용자 에이전트 또는 OS UI입니다.

가장 일반적인 UI 위젯은 가상 키보드입니다.

interactive-widget의 유효 값과 연관된 뷰포트 리사이징 동작 목록은 다음과 같습니다:

overlays-content
인터랙티브 UI 위젯은 리사이즈해서는 안 됩니다. 초기 뷰포트visual viewport를 리사이즈하지 않습니다. 사용자 에이전트는 VirtualKeyboard.overlaysContenttrue로 설정한 것과 동일한 단계를 수행해야 합니다.
resizes-content
인터랙티브 UI 위젯은 리사이즈해야 합니다. 초기 뷰포트가 위젯에 의해 리사이즈됩니다.
visual viewport의 크기는 초기 뷰포트에서 파생되므로, resizes-content는 초기/visual 두 뷰포트를 모두 리사이즈하게 됩니다.
resizes-visual
인터랙티브 UI 위젯은 리사이즈해야 합니다. visual viewport만 리사이즈를 해야 하며, 초기 뷰포트리사이즈하지 않아야 합니다.

interactive-widget에 값이 없거나 잘못된 값이 설정된 경우, 기본값으로 resizes-visual 동작이 사용됩니다.

인터랙티브 위젯에 의해 뷰포트를 리사이즈할 때는, 뷰포트 사각형과 위젯의 OS 보고 바운딩 사각형이 겹치는 부분만큼 뷰포트에서 빼줍니다. 이 결과가 비직사각형 뷰포트가 된다면, 동작은 UA가 정의한 대로입니다.

예시로, 결과가 비직사각형이 되는 경우: 플로팅 또는 분할 키보드, 또는 뷰포트의 일부만 차지하는 키보드 등이 있습니다.

3.4.1. virtualKeyboard.overlaysContent와의 상호작용

[VIRTUAL-KEYBOARD]overlays-content 동작을 VirtualKeyboard.overlaysContent 속성을 통해 명령형(Imperative)으로 적용하는 API를 제공합니다. 이 속성은 interactive-widget에서 설정한 값을 덮어씁니다. 즉:

VirtualKeyboard.overlaysContenttrue로 설정되면, UA는 인터랙티브 위젯 리사이즈 동작 결정 시 interactive-widget의 값을 무시해야 합니다.

VirtualKeyboard.overlaysContentfalse로 설정되면, UA가 interactive-widget의 값을 따라야 하며(값이 없다면 기본 동작 사용), 이를 근거로 인터랙티브 위젯 리사이즈 동작을 결정해야 합니다.

VirtualKeyboard.overlaysContent 값을 가져오는 경우, 이전에 설정한 값만 반환해야 합니다.

즉, 이전에 값이 설정되지 않았다면 VirtualKeyboard.overlaysContentinteractive-widget=overlays-content<meta> 태그로 설정되어 있어도 항상 false를 반환합니다.

부록 A. 변경 사항

이 부록은 비규범적입니다.

2016년 3월 29일 작업 초안 이후

2011년 9월 15일 최초 공개 작업 초안 이후.

적합성

문서 규약

적합성 요구 사항은 서술적 명제와 RFC 2119 용어의 조합으로 표현됩니다. 규범적 부분에서 “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”이라는 단어는 RFC 2119에 정의된 대로 해석되어야 합니다. 하지만 가독성을 위해, 이 명세서에서는 이 단어들은 모두 대문자로 표기되지 않습니다.

이 명세의 본문 전체는 별도로 비규범적임, 예제, 노트로 표시된 부분을 제외하면 규범적입니다. [RFC2119]

이 명세서의 예제는 “for example”라는 말로 도입하거나, 또는 아래처럼 class="example"로 표기하여 본문과 구별합니다:

이것은 정보 제공용 예제입니다.

비규범적 노트는 “Note”라는 단어로 시작하며, class="note" 표기가 붙어 본문과 구분됩니다:

참고: 이것은 정보 제공용 노트입니다.

Advisement(권고)는 눈에 띄게 스타일링된 규범 부분으로, <strong class="advisement">로 구분되며, 다음과 같이 사용합니다: UA는 반드시 접근 가능한 대안을 제공해야 합니다.

적합성 클래스

이 명세서에 대한 적합성은 세 가지 적합성 클래스로 정의됩니다:

스타일 시트
CSS 스타일 시트.
렌더러
UA로, 스타일시트의 의미를 해석하고, 그 스타일시트를 사용하는 문서를 렌더링하는 프로그램입니다.
저작 도구
스타일시트를 작성하는 UA.

스타일 시트가 이 명세서에 적합하려면, 이 모듈에서 정의한 문법을 사용하는 모든 명령문이 CSS의 일반 문법 및 각 기능별 개별 문법에 따라 유효해야 합니다.

렌더러가 이 명세서에 적합하려면, 스타일시트를 적절한 명세에 따라 해석하는 것 외에도, 이 명세서에서 정의한 모든 기능을 올바르게 파싱 및 문서 렌더링을 할 수 있어야 합니다. 다만, 기기의 한계로 인한 문서 렌더링 실패는 적합성에 영향을 주지 않습니다. (예: 흑백 모니터에서는 색상을 렌더링할 필요 없음)

저작 도구가 이 명세서에 적합하려면, 이 모듈의 일반 CSS 문법 및 기능별 개별 문법에 따라 문법적으로 올바른 스타일시트를 작성하고, 이 모듈에 기술된 모든 스타일시트 적합성 요구 사항을 충족해야 합니다.

부분 구현

작성자가 미래 호환 파싱 규칙을 활용해 fallback 값을 지정할 수 있도록, CSS 렌더러는 지원할 수 없는 at-규칙, 속성, 속성 값, 키워드 등 구문 구조물을 무시해야 합니다(적절하게 무시). 특히 사용자 에이전트는 하나의 멀티 값 속성 선언에서 지원되는 값만 선택적으로 인식하고 지원되지 않는 값을 무시해서는 안 되며: 하나라도 값이 잘못되면(지원하지 않는 값 포함), CSS 규칙상 전체 선언을 무시해야 합니다.

불안정 및 독점 기능의 구현

미래의 안정적인 CSS 기능과 충돌을 피하기 위해, CSSWG는 베스트 프랙티스를 따르며 불안정 기능 및 독점 확장을 구현할 것을 권장합니다.

비실험적 구현

명세가 Candidate Recommendation 단계에 도달하면, 비실험적 구현이 가능하며, 구현자는 규격에 맞게 올바르게 구현한 CR 수준 기능을 prefix 없이 배포해야 합니다.

CSS의 구현 간 상호운용성을 확립·유지하기 위해 CSS 작업 그룹은 비실험적인 CSS 렌더러가 prefix 없이 CSS 기능을 배포하기 전에 구현 보고서(및 필요할 경우 해당 테스트케이스)를 W3C에 제출할 것을 요청합니다. 제출된 테스트케이스는 CSS 작업 그룹의 리뷰 및 교정을 거칠 수 있습니다.

테스트케이스 및 구현 보고서 제출 관련 정보는 CSS 작업 그룹 웹사이트 https://www.w3.org/Style/CSS/Test/에서 확인할 수 있습니다. 문의는 public-css-testsuite@w3.org 메일링 리스트로 해주십시오.

색인

이 명세서에서 정의된 용어

참조로 정의된 용어

참고 문헌

규범적 참고 문헌

[CSS-PAGE-3]
Elika Etemad. CSS Paged Media Module Level 3. 2023년 9월 14일. WD. URL: https://www.w3.org/TR/css-page-3/
[CSS-VIEWPORT]
CSS Viewport Module Level 1. Editor's Draft. URL: https://drafts.csswg.org/css-viewport/
[CSS-WRITING-MODES-3]
Elika Etemad; Koji Ishii. CSS Writing Modes Level 3. 2019년 12월 10일. REC. URL: https://www.w3.org/TR/css-writing-modes-3/
[CSS21]
Bert Bos; et al. Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. 2011년 6월 7일. REC. URL: https://www.w3.org/TR/CSS21/
[CSS3-CONDITIONAL]
David Baron; Elika Etemad; Chris Lilley. CSS Conditional Rules Module Level 3. 2022년 1월 13일. CR. URL: https://www.w3.org/TR/css-conditional-3/
[CSSOM-VIEW-1]
Simon Pieters. CSSOM View Module. 2016년 3월 17일. WD. URL: https://www.w3.org/TR/cssom-view-1/
[MEDIAQUERIES-5]
Dean Jackson; et al. Media Queries Level 5. 2021년 12월 18일. WD. URL: https://www.w3.org/TR/mediaqueries-5/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. 1997년 3월. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[VIRTUAL-KEYBOARD]
Anupam Snigdha. VirtualKeyboard API. 2022년 5월 5일. WD. URL: https://www.w3.org/TR/virtual-keyboard/

참고용 참고 문헌

[Algorithms]
Thomas H. Cormen; et al. Introduction to Algorithms, Second Edition, MIT Press.

이슈 색인

이 명세서는 구현 중심으로 작성되어 읽기에 다소 어렵습니다. 다양한 독자층에게 더 이해하기 쉽도록 하려면 상당한 편집 작업이 필요할 수 있습니다. 또한 여러 js API가 참조하는 뷰포트가 무엇인지 명확하게 해야 합니다. 이러한 이슈 논의는 ppk의 블로그 글 참고.
이 명세 및 관련 명세들에 대한 여러 이슈들은 이 보고서에서 정리되어 있습니다.
실제 뷰포트를 레이아웃 뷰포트로, visual viewport를 정의해야 합니다.
명세 추가 필요
viewport meta 태그의 extend-to-zoom 동작 규정 필요
visual viewport 정의를 CSSOM-View에서 이 명세로 이동 필요.