프런트엔드 개발에 가장 많은 영향을 주는 크롬 브라우저의 버전별 변경 예정 항목을 정리 및 공유한다.
💡 각 항목은 Chrome Platform Status의 Roadmap과 한 달간의 blink-dev 활동 요약을 바탕으로 정리했다.
💡 각 항목의 🚫는 지원 중단 및 제거(Removed), ⚠️는 지원 중단(Deprecated), ✅는 새로운 기능(Enabled by default)를 의미한다.
💡 각 항목 중 기존 서비스에 미치는 영향이 크다고 판단한 항목은 소제목 뒤에 📌 표시를 했다.
💡 지원 중단 및 제거(🚫), 지원 중단(⚠️) 외의 항목은 공유 가치가 있다고 판단한 경우에만 포함했다.
💡 각 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 Chrome Platform Status를 그대로 인용했다.
connect-src
지시자 우회 기능 제거:nth-child(an + b of S)
추가@container
쿼리에 style()
함수 추가document.domain
설정자(Setter) 지원 중단 📌shadowroot
속성 지원 중단v
플래그 추가CollectedClientAdditionalPaymentData
의 rp
속성 지원 중단Headers.getSetCookie()
메서드 추가RTCPeerConnection.getStats()
의 지원 중단 맛보기 📌connect-src
지시자 우회 기능 제거connect-src
지시자는 HTTP CSP(Content-Security-Policy) 헤더의 지시자이다. 이 지시자를 사용하면 스크립트에서 발생하는 특정 URL에 대한 연결을 허용 또는 제한할 수 있다.
하지만 기존 Payment Request API는 결제 서비스 제공자(PaymentHandler)의 manifest 파일을 가져올 때 이 속성을 무시했다. 잠재적인 XSS(Cross-Site Scripting) 위험이 있어 이 기능을 제거한다.
기존에 Web Payment API와 connect-src
속성을 함께 사용했다면 connect-src
지시자가 PaymentHandler의 URL을 허용하는지 확인 및 변경해야 한다.
Content-Security-Policy: connect-src <source-of-payment-handler>
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
PaymentInstruments API는 크롬에서 독자적으로 설계한 API로, 브라우저에 결제 앱의 서비스 워커를 JIT(Just-In-Time)가 아닌 방식으로 설치할 수 있도록 돕는다. 하지만 이 API의 PaymentInstruments.set()
과 PaymentInstruments.get()
메서드로 공격자가 사용자의 데이터를 저장 및 유출할 수 있어 이 API를 완전히 제거한다.
PaymentInstruments API를 사용한다면 일반적인 JIT 방식으로 서비스 워커를 등록하도록 변경해야 한다.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
"canmakepayment"는 서비스 워커의 전역 객체 이벤트로, 웹 사이트가 결제를 처리할 준비가 되었는지 확인할 때 해당 결제 앱의 서비스 워커에서 발생한다. 이 이벤트는 교차 통신임에도 그동안 사용자의 액션이나 동의를 받지 않고 판매자 또는 임의의 데이터를 은밀히 전달했다. 개인정보 보호를 위해 "canmakepayment" 이벤트 객체에서 판매자의 출처(origin), 그리고 임의의 데이터를 삭제한다.
"canmakepayment" 이벤트 객체에서 삭제되는 속성은 아래와 같다.
topOrigin
paymentRequestOrigin
methodData
modifiers
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
다중 화면 창 제어(Multi-Screen Window Placement) API는 브라우저의 창을 직접 제어할 수 있는 API이다. 이 API를 사용하려면 사용자에게 "window-placement" 권한을 요청해야 한다. 하지만 이 API는 브라우저 창의 위치뿐만 아니라 창의 정보를 가져오거나, 화면 설정의 변경을 감지하는 등의 기능도 수행하기에 "window-placement"라는 권한 이름으로 표현하기에 적절하지 않다. 장기적으로 "window-placement" 권한을 지원 중지하기 위해 "window-management" 권한을 별칭으로 추가한다.
"window-placement"의 지원 중단 일정은 불투명하나, 좀 더 안전한 "window-management"의 사용을 고려할 필요가 있다.
- navigator.permissions.query({name:'window-placement'});
+ navigator.permissions.query({name:'window-management'});
- <iframe allow="window-placement"> ... </iframe>
+ <iframe allow="window-management"> ... </iframe>
- Permission-Policy: window-placement 'self'
+ Permission-Policy: window-management 'self'
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
:nth-child(an + b of S)
추가선택자 Level 4의 기능 중 :nth-child(an + b of S)
를 추가한다. 기존에는 :nth-child(an + b)
의 형태로만 사용이 가능했다.
.parent li:nth-child(even) {
/* 부모의 자식 중 짝수 번째이며, li인 요소 */
}
.parent :not([hidden]):nth-child(2n + 1) {
/* 부모의 자식 중 3, 5, 7, 9... 번째이며, "hidden" 속성이 없는 요소 */
}
얼핏 보면 :not([hidden]):nth-child(2)
은 hidden
속성이 없는 요소 중 2번째 자식을 가리킬 것 같지만 그렇지 않다. :nth-child(an + b)
는 현재 부모를 기준으로 순서를 정한다.
<div>
<div hidden>
<!-- :nth-child(1) -->
</div>
<div>
<!-- :not([hidden]):nth-child(2) -->
</div>
<div>
<!-- :not([hidden]):nth-child(3) -->
</div>
</div>
:not([hidden]):nth-child(2)
는 부모의 2번째 자식이며, hidden
속성이 없는 요소를 가리킨다. 새로운 :nth-child(an + b of S)
선택자를 사용하면 의도한 대로 특정 요소 중의 순서를 선택할 수 있다.
.parent :nth-child(even of li) {
/* 부모의 자식 중 li 요소만 모았을 때 짝수 번째인 요소 */
}
.parent :nth-child(2n + 1 of :not([hidden])) {
/* 부모의 자식 중 "hidden" 속성이 없는 요소만 모았을 때 3, 5, 7, 9... 번째인 요소 */
}
:nth-child(2 of :not([hidden]))
를 사용하면 hidden
속성이 없는 요소 중 2번째 요소를 선택할 수 있다.
<div>
<div hidden>
<!-- :nth-child(1) -->
</div>
<div>
<!-- :nth-child(1 of :not([hidden])) -->
</div>
<div>
<!-- :nth-child(2 of :not([hidden])) -->
</div>
</div>
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
@container
쿼리에 style()
함수 추가@container
쿼리는 컨테이너 요소의 크기를 바탕으로 스타일을 제어할 수 있는 CSS 초안의 기능이다. @container
쿼리와 함께 사용할 수 있는 style()
함수를 추가한다. style()
함수를 사용하면 조상 요소의 스타일 규칙을 바탕으로 스타일을 정의할 수 있다.
@container style(background-color: black) {
h2 {
color: white;
}
}
style()
함수의 인자로는 CSS 변수도 사용할 수 있으며, @media
쿼리처럼 기존 다른 규칙과도 함께 사용할 수 있다.
@container style(--theme: dark) and (width > 300px) {
h2 {
color: white;
}
}
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
Chrome 111은 2023년 3월 1일에 정식 배포 예정이다. 2월 9일부터 16일 사이에 크롬 베타 버전에서 해당 기능을 미리 확인해 볼 수 있다.
document.domain
설정자(Setter) 지원 중단 📌SOP(Same-Origin Policy)는 브라우저 보안 정책으로, 두 페이지가 서로 다른 출처(origin)일 때 이 두 페이지 사이의 통신을 막는다. 예를 들어 parent.example.com
페이지에 <iframe>
으로 child.example.com
페이지를 불러오면 기본적으로 child.example.com
은 window.parent
로 부모창에 접근할 수 없고, 이 반대도 마찬가지다. 기존에는 상위 도메인이 같은 경우, document.domain
설정자를 사용하여 상위 도메인(example.com
)으로 출처를 변경해 SOP를 완화할 수 있었다. 보다 강력한 보안을 위해 이 설정자를 지원 중단한다. 지원 중단 기간 동안 document.domain
설정자를 호출할 수는 있지만 출처는 변하지 않는다.
사용자가 직접 크롬 플래그에서 Origin-keyed agent clusters
기능을 설정해 기존처럼 document.domain
로 출처를 변경할 수 있다. 하지만 기본 옵션이 아니기 때문에 대안을 찾는 것이 좋다. 가장 간단하게 서로 다른 출처 간 통신은 window.postMessage
로 구현할 수 있다.
// parent.example.com
window.addEventListener('message', (event) => {
if (event.origin !== 'http://child.example.com') {
return;
}
console.log(event.data); // 안녕하세요?
});
// child.example.com
window.postMessage('안녕하세요?', 'http://parent.example.com');
window.postMessage
의 자세한 사용법 및 다른 대안은 여기를 참고해도 좋다.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
shadowroot
속성 지원 중단선언적 Shadow DOM은 <template>
요소에 shadowroot
속성을 지정해 템플릿에서 직접 Shadow DOM을 활성화할 수 있는 기능이다. 표준에서 이 속성에 대한 이름을 shadowrootmode
로 변경함에 따라 기존 shadowroot
속성의 지원을 중단한다. shadowroot
는 크롬에서 그대로 동작하나, 새로 추가될 스트리밍 기능을 사용할 수 없다. shadowrootmode
는 다른 브라우저에서도 지원 예정이므로 shadowrootmode
속성을 사용하는 것이 좋다.
<host-element>
- <template shadowroot="open">
+ <template shadowrootmode="open">
<slot></slot>
</template>
<h2>Light content</h2>
</host-element>
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
shadowroot
attribute for declarative shadow DOM (Deprecated)CSS 규칙을 중첩 정의할 수 있는 기능을 추가한다. 큰 모습은 Sass와 비슷해 보이나 기본 동작에서는 차이가 있다. 하나 예를 들어 Sass는 상위 선택자, &
를 문자열로 본다.
.foo {
&Bar {
color: red;
}
}
위 파일을 Sass
엔진으로 변환하면 다음과 같은 결과가 나온다.
.fooBar {
color: red;
}
하지만 CSS의 중첩 모듈은 &
를 별도의 컴포넌트로 본다. 따라서 첫 번째 예시를 아래처럼 해석한다.
Bar.foo {
color: red;
}
CSS 중첩 모듈은 앞선 예시를 .foo
라는 문자열과 Bar
라는 문자열이 합쳐진 게 아닌 .foo
라는 선택자와 Bar
라는 타입 선택자를 합친 것으로 본다.
또한 중첩 구문은 타입 선택자나 함수 구문으로 시작할 수 없다.
/* 올바르지 않은 CSS 구문! */
li {
color: lime;
input {
margin-top: 1em;
}
}
이 기능은 아직 초안이기 때문에 실제 구현 과정에서 규칙이 변경될 수 있다. 자세한 규칙은 공식 문서를 참고하자.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
"beaconing"은 서버의 응답 없이 서버에 단방향으로 데이터를 전송하는 동작을 말한다. 개발자는 beaconing을 이용해 사용자의 활동, 그리고 페이지에서 언제 오류가 발생했는지 등을 추적할 수 있다. 현재 beaconing을 구현할 수 있는 방법은 아래와 같다.
<img />
태그를 추가한다.XMLHttpRequest
를 동기로 요청한다.Navigator.sendBeacon
API를 사용한다.fetch
를 keepalive
옵션과 함께 사용한다.하지만 이들 중 어느 것도 항상 데이터를 보낼 것이라 확신하기 어렵다. 페이지(브라우저 탭)가 멈춘다던가, 모바일 환경에서 브라우저 앱 자체를 종료하는 경우 자바스크립트의 생애주기(lifecycle) 중 어느 것도 데이터를 전송하기에 적절하지 않은 탓이다. unload
나 beforeunload
는 주요 브라우저조차 특정 상황에서 이벤트를 발생시키지 않는 경우가 있으며, pagehide
와 visibilitychange
는 모바일 환경에서 제대로 동작하지 않는 문제가 있다.
PendingBeacon API는 WICG(Web Incubator Communitry Group)에 제안된 새로운 API로, 페이지가 종료될 때 반드시 데이터를 보낼 것임을 보장해주는 API다.
PendingBeacon
해당 기능의 기본 동작을 담은 인터페이스이며, 실제로 사용할 수 있는 것은 PendingGetBeacon
과 PendingPostBeacon
이다.
const beacon = new PendingGetBeacon('/log', {
// 페이지가 숨겨진 후 얼마 이후에 요청을 보낼지 설정한다.
// 기본값은 -1이며, 값이 0보다 작으면 페이지가 브라우저에서 제거되었을 때, 또는 BFCache에서 제거되었을 때만 요청을 전송한다.
backgroundTimeout: 1000,
});
// "/log"에 보낼 데이터
// 사용자가 페이지를 떠날 때 데이터를 전송한다.
beacon.setData(data);
PendingBeacon API는 페이지와 다른 스레드에서 동작하기에 페이지가 멈추어 동작하지 않을 때도 안정적으로 요청을 전송할 수 있다.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
v
플래그 추가정규식에 유니코드 집합 모드(/v
)를 추가한다. v
플래그는 ES2015 유니코드 모드(/u
)의 확장판으로, u
플래그보다 더 많은 기능을 지원한다.
먼저 u
플래그가 하나의 코드 포인트(code point)만 지원하는 것과 달리 v
플래그는 다수의 코드 포인트를 지원한다.
{
// u 플래그
const regex = /^\p{RGI_Emoji}$/u;
regex.test('⚽'); // '\u26BD', 한 개의 코드 포인트
// -> true
regex.test('👨🏾⚕️'); // '\u{1F468}\u{1F3FE}\u200D\u2695\uFE0F', 5개의 코드 포인트로 이루어져 u 플래그로는 검사할 수 없다.
//-> false
}
{
// v 플래그
const regex = /^\p{RGI_Emoji}$/v;
regex.test('⚽'); // '\u26BD'
// -> true
regex.test('👨🏾⚕️'); // '\u{1F468}\u{1F3FE}\u200D\u2695\uFE0F'
// -> true
}
또한 유니코드 속성 예외 표현(\p
)과 유니코드 집합 표현식을 함께 사용할 수 있다.
// 한글이며, "ㄴ"이 아닌 유니코드 문자
/[\p{Script_Extensions=Hangul}--ㄴ]/v.test('ㄴ'); // -> false
// 한글이며, "ㄱ", "ㄴ", "ㄷ"이 아닌 유니코드 문자
/[\p{Script_Extensions=Hangul}--[ㄱ-ㄷ]]/v.test('ㄴ'); // -> false
--
를 사용하면 특정 유니코드 속성을 가진 문자 중에서 지정한 문자 또는 문자 집합을 제외할 수 있다. &&
는 교차 구문으로 두 유니코드 속성을 모두 가진 유니코드 문자를 가리킨다.
// 그리스 문자이며, 문자인 유니코드 문자
const regex = /[\p{Script_Extensions=Greek}&&\p{Letter}]/v;
// U+03C0 그리스 PI 소문자
regex.test('π'); // true
// U+1018A 그리스 0에 해당하는 숫자
regex.test('𐆊'); // false
u
플래그는 유니코드 속성끼리만 집합을 생성할 수 있지만, v
플래그는 문자열과도 함께 집합을 생성할 수 있다.
// 한글 또는 0-9 사이의 아라비아 숫자
const regex = /^[\p{Script_Extensions=Hangul}0-9]$/v;
regex.test('스물두살'); // true
regex.test('22살'); // true
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
Chrome 112는 2023년 3월 29일에 정식 배포 예정이다. 3월 9일부터 16일 사이에 크롬 베타 버전에서 해당 기능을 미리 확인해 볼 수 있다.
공개 웹 사이트(공개 IP로 접근 가능한 사이트)에서 내부망에 하위 리소스(.js
, .css
등) 요청 시 반드시 보안 컨텍스트(HTTPS)를 사용하도록 제한한다. 이는 내부망 접근 규칙 적용의 초석으로, 다른 규칙과 따로 적용할 수 있어 이 규칙을 먼저 적용한다.
내부망의 하위 리소스에 접근하려면 미리 보안 컨텍스트를 사용하도록 변경해야 한다.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
CollectedClientAdditionalPaymentData
의 rp
속성 지원 중단SPC(Secure Payment Confirmation)는 결제 거래 중 간소화된 인증 절차를 제공하는 웹 API이다. WebAuthn을 기반으로 만들었으며, WebAuthn에서 CollectedClientAdditionalPaymentData
의 rp
속성의 이름을 rpId
로 변경함에 따라 표준에서도 rp
(Relying Party, 신뢰 당자사)를 rpId
로 변경하였다. 변경된 표준 문서의 반영을 위해 rp
속성을 제거한다.
Chrome 107에서 먼저 CollectedClientAdditionalPaymentData
에 rpId
속성을 추가했으므로 rp
대신 rpId
를 사용하도록 변경해야 한다.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
Headers.getSetCookie()
메서드 추가HTTP 요청을 보낼 때 Set-Cookie
헤더는 여러 번 중복으로 선언할 수 있으며, 자동으로 합쳐지지 않는다. 하지만 현재 Headers
는 등록한 Set-Cookie
헤더를 따로 가져올 수 있는 기능을 제공하지 않는다. 예시로 현재 Headers.get('Set-Cookie')
는 모든 Set-Cookie
헤더의 값을 합친 결과를 반환한다.
const a = new Headers();
a.append('Set-Cookie', 'a=1');
a.append('Set-Cookie', 'b=2');
console.log(a.get('Set-Cookie')); // a=1, b=2
HTTP의 규칙과 동일하게 Headers
의 Set-Cookie
를 배열로 반환하는 Headers.getSetCookie()
메서드를 추가한다. 일부 브라우저는 Headers
객체를 순회할 때 Set-Cookie
를 합치지 않는 기능도 먼저 적용했다.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
RTCPeerConnection.getStats()
콜백 방식 지원 중단 맛보기 📌RTCPeerConnection.getStats()
는 해당 오디오나 비디오 연결에 대한 통계 자료를 반환하는 API다. 현재 크롬에서 이 API는 프로미스를 반환하는 최신 버전과, 콜백을 사용하는 구버전 두 가지로 나뉜다.
myPeerConnection.getStats(); // 최신 버전
myPeerConnection.getStats(null, onSuccess, onFailure); // 구버전, Promise 반환 X
콜백 방식은 모던 자바스크립트와 어울리지 않고, 표준 스펙 문서도 없어 장기적으로 지원을 중단할 예정이다. Chrome 113에서는 콜백 방식 사용 시 콘솔에 경고를 노출하며, 크롬 플래그에서 지원 중단을 체험할 수 있는 기능을 추가할 예정이다.
콜백 방식은 오는 6월 말에 정식 배포 예정인 Chrome 115에서 지원 중단을 논의 중이다.
이 항목에 대한 주요 브라우저 및 웹 개발자의 의견은 다음과 같다.
Chrome 113은 2023년 4월 26일에 정식 배포 예정이다. 4월 6일부터 13일 사이에 크롬 베타 버전에서 해당 기능을 미리 확인해 볼 수 있다.