<picture> 요소는 자체적으로 아무것도 렌더링하지 않고, 대신 내부 <img> 요소의 결정 엔진 역할을 하여 렌더링할 내용을 알려줍니다. <picture>는 <audio> 및 <video> 요소에서 이미 설정된 선례를 따릅니다. 이는 개별 <source> 요소를 포함하는 래퍼 요소입니다.
<picture>
<source …>
<source …>
<img …>
</picture …>
이 내부 <img>는 반응형 이미지를 지원하지 않고 이전 브라우저를 위한 안정적인 대체 패턴을 제공합니다. <picture> 요소가 사용자의 브라우저에서 인식되지 않으면 무시됩니다. 그런 다음 <source> 요소도 삭제됩니다. 브라우저가 요소를 전혀 인식하지 못하거나 <video> 또는 <audio> 상위 요소가 없으면 의미 있는 컨텍스트를 갖지 않기 때문입니다.
하지만 내부 <img> 요소는 모든 브라우저에서 인식되며 src에 지정된 소스는 예상대로 렌더링됩니다.
<picture>의 '예술 감독' 이미지
페이지 내 이미지 크기에 따라 이미지의 콘텐츠나 가로세로 비율을 변경하는 것을 일반적으로 '아트 디렉션' 반응형 이미지라고 합니다. srcset 및 sizes는 보이지 않게 작동하도록 설계되어 사용자의 브라우저에 따라 소스가 원활하게 교체됩니다.
그러나 페이지 레이아웃을 조정하는 것과 동일한 방식으로 중단점에서 소스를 변경하여 콘텐츠를 더 강조해야 하는 경우도 있습니다.
예를 들어 중앙에 작은 포커스가 있는 전체 너비 헤더 이미지는 큰 표시 영역에서 잘 작동할 수 있습니다.
그러나 작은 표시 영역에 맞게 축소하면 이미지의 중심 초점이 사라질 수 있습니다.
이러한 이미지 소스의 제목은 동일하지만 시각적으로 주제에 더 집중하려면 중단점에서 이미지 소스의 비율을 변경하는 것이 좋습니다. 예를 들어 이미지 중앙을 더 크게 확대하면 가장자리의 일부 디테일이 잘립니다.
이러한 종류의 '자르기'는 CSS를 통해 실행할 수 있지만 사용자가 이미지를 구성하는 모든 데이터를 요청하게 됩니다. 사용자가 최종적으로 이미지를 보지 못할 수도 있습니다.
각 source 요소에는 해당 source의 선택을 위한 조건을 정의하는 속성이 있습니다. 이 속성은 미디어 쿼리를 허용하는 media과 미디어 유형 (이전의 'MIME 유형'이라고 함)을 허용하는 type입니다. 사용자의 현재 탐색 컨텍스트와 일치하는 소스 순서의 첫 번째 <source>가 선택되고, 해당 source에 있는 srcset 속성의 콘텐츠가 해당 컨텍스트에 적합한 후보를 결정하는 데 사용됩니다. 이 예에서는 media 속성이 사용자의 표시 영역 크기와 일치하는 첫 번째 source가 선택됩니다.
<picture>
<source media="(min-width: 1200px)" srcset="wide-crop.jpg">
<img src="close-crop.jpg" alt="…">
</picture>
항상 내부 img를 순서에 따라 마지막에 지정해야 합니다. media 또는 type 기준과 일치하는 source 요소가 없으면 이미지가 '기본' 소스 역할을 합니다. min-width 미디어 쿼리를 사용한다면 위 코드에서와 같이 소스가 가장 큰 것이 좋습니다. max-width 미디어 쿼리를 사용할 때는 가장 작은 소스를 먼저 배치해야 합니다.
<picture>
<source media="(max-width: 400px)" srcset="mid-bp.jpg">
<source media="(max-width: 800px)" srcset="high-bp.jpg">
<img src="highest-bp.jpg" alt="…">
</picture>
지정한 기준에 따라 소스가 선택되면 source의 srcset 속성이 <img> 자체에 정의된 것처럼 <img>에 전달됩니다. 즉, 자유롭게 sizes를 사용하여 아트 디렉팅 이미지 소스를 최적화할 수 있습니다.
<picture>
<source media="(min-width: 800px)" srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w">
<source srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w">
<img src="fallback.jpg" alt="…" sizes="calc(100vw - 2em)">
</picture>
물론 선택한 <source> 요소에 따라 달라질 수 있는 이미지의 비율은 성능 문제를 일으킵니다.
<img>는 단일 width 및 height 속성만 지원하지만 이러한 속성을 생략하면 사용자 환경이 크게 악화될 수 있습니다.
이를 설명하기 위해 HTML 사양에 비교적 최신이지만 잘 지원됨하면 <source> 요소에서 height 및 width 속성을 사용할 수 있습니다. 이는 <img>에서와 마찬가지로 레이아웃 변경을 줄이기 위해 작동하며, 어떤 <source> 요소가 선택되건 간에 레이아웃에 적절한 공간이 확보됩니다.
<picture>
<source
media="(min-width: 800px)"
srcset="high-bp-1600.jpg 1600w, high-bp-1000.jpg 1000w"
width="1600"
height="800">
<img src="fallback.jpg"
srcset="lower-bp-1200.jpg 1200w, lower-bp-800.jpg 800w"
sizes="calc(100vw - 2em)"
width="1200"
height="750"
alt="…">
</picture>
아트 디렉션은 표시 영역 크기를 기반으로 한 결정 이상의 경우에 사용될 수 있으며, 이러한 경우 대부분 srcset/sizes를 사용하면 더 효율적으로 처리할 수 있다는 점을 고려할 때 사용해야 합니다. 예를 들어 사용자의 환경설정에 따라 지정된 색 구성표에 더 적합한 이미지 소스를 선택하는 것은 다음과 같습니다.
<picture>
<source media="(prefers-color-scheme: dark)" srcset="hero-dark.jpg">
<img srcset="hero-light.jpg">
</picture>
type 속성
type 속성을 사용하면 <picture> 요소의 단일 요청 결정 엔진을 사용하여 이미지 형식을 지원하는 브라우저에만 이미지 형식을 제공할 수 있습니다.
이미지 형식 및 압축에서 알아본 것처럼 브라우저가 파싱할 수 없는 인코딩은 이미지 데이터로도 인식할 수 없습니다.
<picture> 요소를 도입하기 전에는 새로운 이미지 형식을 제공하는 데 가장 적합한 프런트엔드 솔루션을 사용하려면 브라우저에서 이미지 파일을 요청하고 파싱한 후 이미지 파일을 삭제하고 대체를 로드할지 결정해야 했습니다. 일반적인 예로 다음 행의 스크립트가 있습니다.
<img src="image.webp"
data-fallback="image.jpg"
onerror="this.src=this.getAttribute('data-fallback'); this.onerror=null;"
alt="...">
이 패턴을 사용하면 모든 브라우저에서 image.webp 요청이 계속 발생합니다. 즉, WebP를 지원하지 않는 브라우저의 전송이 낭비됩니다. 그런 다음 WebP 인코딩을 파싱할 수 없는 브라우저는 onerror 이벤트를 발생시키고 data-fallback 값을 src로 바꿉니다. 낭비가 많았지만 이와 같은 접근 방식이 프런트엔드에서 사용할 수 있는 유일한 옵션이었습니다. 브라우저에서 맞춤 스크립팅이 실행되거나 파싱되기 전에 이미지 요청을 시작하기 때문에 이 프로세스를 선점할 수 없습니다.
<picture> 요소는 명시적으로 이러한 중복 요청을 방지하도록 설계되었습니다. 브라우저가 지원하지 않는 형식을 요청하지 않고 인식할 수 있는 방법은 아직 없지만, type 속성은 소스 인코딩에 관해 브라우저에 미리 경고하므로 요청 여부를 결정할 수 있습니다.
type 속성에서 각 <source>의 srcset 속성에 지정된 이미지 소스의 미디어 유형 (이전의 MIME 유형)을 제공합니다. 이를 통해 브라우저에는 source에서 제공하는 이미지 후보를 외부 요청 없이 디코딩할 수 있는지 즉시 결정하는 데 필요한 모든 정보가 제공됩니다. 미디어 유형이 인식되지 않으면 <source>와 모든 후보가 무시되고 브라우저가 계속됩니다.
<picture>
<source type="image/webp" srcset="pic.webp">
<img src="pic.jpg" alt="...">
</picture>
여기에서 WebP 인코딩을 지원하는 모든 브라우저는 <source> 요소의 type 속성에 지정된 image/webp 미디어 유형을 인식하고 <source>를 선택합니다. 그런 다음 srcset에 단일 후보만 제공했으므로 pic.webp를 요청, 전송, 렌더링하도록 내부 <img>에 지시합니다. WebP를 지원하지 않는 모든 브라우저는 source를 무시하며, 반대되는 명령이 없으면 <img>는 1992년부터 그랬던 것처럼 src의 콘텐츠를 렌더링합니다.
물론 여기서 type="image/jpeg"로 두 번째 <source> 요소를 지정할 필요는 없습니다. JPEG를 보편적으로 지원한다고 가정할 수 있습니다.
사용자의 탐색 컨텍스트와 관계없이 이 모든 작업은 단일 파일 전송으로 달성할 수 있으며 렌더링할 수 없는 이미지 소스에 대역폭을 낭비하지 않습니다. 이는 진보적인 생각이기도 합니다. 더 새롭고 효율적인 파일 형식에는 자체적인 미디어 유형이 제공되기 때문입니다. JavaScript나 서버 측 종속 항목이 없고 <img>의 모든 속도인 picture 덕분에 이러한 형식을 활용할 수 있게 될 것입니다.
반응형 이미지의 미래
여기서 논의한 모든 마크업 패턴은 표준화 측면에서 큰 도움이 되었습니다. <img>와 같이 확립된 핵심 기능의 기능을 웹에 변경하는 것은 결코 간단한 일이 아니었으며 이러한 변경 사항으로 해결하고자 하는 문제점은 간단명료하지 않았습니다. 이러한 마크업 패턴을 사용하면 개선의 여지가 많다고
생각한 경우, 맞습니다. 이러한 표준은 처음부터 향후 발전을 위한 기술을 위한 기준을 제공하기 위한 것이었습니다.
이러한 모든 솔루션은 서버의 초기 페이로드에 포함되고 브라우저가 이미지 소스를 요청할 시간에 제때 도착하기 위해 마크업에 의존해야 했습니다. 이는 일반적으로 다루기 힘든 sizes 속성으로 이어졌습니다.
하지만 이러한 기능이 웹 플랫폼에 도입되면서 이미지 요청을 지연시키는 네이티브 메서드가 도입되었습니다.
loading="lazy" 속성이 있는 <img> 요소는 페이지 레이아웃이 확인될 때까지 요청되지 않습니다. 이는 사용자의 초기 표시 영역 밖에 있는 이미지에 대한 요청을 이후 페이지를 렌더링하는 과정에서 나중으로 지연하여 잠재적으로 불필요한 요청을 피할 수 있기 때문입니다. 브라우저가 이러한 요청이 이루어지는 시점에 페이지 레이아웃을 완전히 이해하므로 이러한 경우에 수동으로 작성하는 sizes 속성을 번거롭게 사용하지 않도록 sizes="auto" 속성이 HTML 사양에 추가되는 것으로 제안되었습니다.
페이지 레이아웃의 스타일을 지정하는 방식에 획기적으로 흥미진진한 변경사항을 적용하기 위해 <picture> 요소에도 추가되었습니다. 표시 영역 정보는 대략적인 레이아웃을 결정하는 데 도움이 되지만, 개발 시 구성요소 수준에서 완전히 접근하지 못하도록 합니다. 다시 말해, 구성요소 자체가 차지하는 공간에 반응하는 스타일을 사용하여 페이지 레이아웃의 모든 부분에 배치할 수 있는 구성요소를 말합니다. 이러한 문제로 인해 표시 영역만 사용하는 것이 아니라 상위 컨테이너의 크기에 따라 요소의 스타일을 지정하는 방법인 컨테이너 쿼리가 생성되었습니다.
컨테이너 쿼리 구문은 이제 안정화되었으며 이 문서의 작성 시점에 브라우저 지원이 매우 제한적이지만 이 기능을 사용 설정하는 브라우저 기술을 추가하면 <picture> 요소에 동일한 작업을 실행할 수 있습니다. 즉, 표시 영역의 크기를 기반으로 하는 대신 <picture> 요소의 <img>가 차지하는 공간에 기반하여 <source> 선택 기준을 허용하는 잠재적 container 속성을 사용할 수 있습니다.
다소 모호하게 들릴 수도 있지만, 여기에는 타당한 이유가 있습니다. 이러한 웹 표준에 대한 논의가 진행 중이지만 아직 해결되지는 않았습니다. 아직은 이를 사용할 수 없기 때문입니다.
반응형 이미지 마크업은 다른 모든 웹 기술과 마찬가지로 시간이 지남에 따라 더 쉽게 작업할 수 있게 해주지만, 이 마크업을 필기로 작성해야 하는 부담을 줄여주는 다양한 서비스, 기술, 프레임워크가 있습니다. 다음 모듈에서는 이미지 형식, 압축 및 반응형 이미지에 관해 지금까지 배운 모든 내용을 최신 개발 워크플로에 통합하는 방법을 살펴보겠습니다.