Houdini: 들어본 적 없는 CSS의 가장 흥미로운 개발

특정 CSS 기능을 사용하고 싶었지만 모든 브라우저에서 완전히 지원 되지 않았기 때문에 사용하지 못한 적이 있습니까? 또는 더 나쁜 것은 모든 브라우저에서 지원되었지만 지원이 버그가 있거나 일관성이 없거나 완전히 호환되지 않는다는 것입니다. 이런 일이 당신에게 일어났다면 – 그리고 나는 그것이 있을 것이라고 장담합니다 – 당신은 Houdini에 대해 관심을 가져야 합니다.

Houdini는 이 문제를 영원히 없애는 것이 궁극적인 목표인 새로운 W3C 태스크 포스입니다. 처음으로 개발자에게 CSS 자체를 확장할 수 있는 기능 과 브라우저 렌더링 엔진의 스타일 및 레이아웃 프로세스에 연결할 수 있는 도구를 제공하는 새로운 API 세트를 도입하여 이를 수행할 계획입니다.

SmashingMag에 대한 추가 정보:

• 로컬에서 WebDev 환경 설치를 중단해야 하는 이유
• CSS의 미래: 실험적인 CSS 속성
• 없이는 살 수 없는 53가지 CSS 기술

그러나 구체적으로 무엇을 의미합니까? 심지어 좋은 생각인가요? 그리고 그것은 우리 개발자들이 현재와 미래에 웹사이트를 구축하는 데 어떻게 도움이 될까요?

이 기사에서는 이러한 질문에 답하려고 합니다. 그러나 그렇게 하기 전에 오늘날 문제가 무엇인지, 왜 그러한 변화가 필요한지 명확히 하는 것이 중요합니다. 그런 다음 Houdini가 이러한 문제를 해결하는 방법에 대해 더 구체적으로 이야기하고 현재 개발 중인 몇 가지 흥미로운 기능을 나열합니다. 마지막으로 Houdini를 현실로 만들기 위해 웹 개발자가 오늘 할 수 있는 몇 가지 구체적인 사항을 알려 드리겠습니다.

Houdini는 어떤 문제를 해결하려고 합니까?

내가 기사를 작성하거나 새로운 CSS 기능을 보여주는 데모를 만들 때마다 필연적으로 누군가 댓글이나 Twitter에서 "이것은 굉장합니다! 앞으로 10년 동안 사용할 수 없다는 것이 너무 아쉽습니다.”

이런 댓글이 짜증나고 비건설적이지만 그 심정을 이해합니다. 역사적으로 기능 제안이 널리 채택되는 데 몇 년이 걸렸습니다. 그 이유는 웹의 역사를 통틀어 CSS에 새로운 기능을 추가하는 유일한 방법은 표준 프로세스를 통과하는 것뿐이었습니다.

표준 프로세스에 반대하는 것은 전혀 없지만 시간이 오래 걸릴 수 있다는 점은 부인할 수 없습니다!

예를 들어, flexbox는 2009년에 처음 제안되었으며 개발자들은 여전히 ​​브라우저 지원 부족으로 인해 오늘날 사용할 수 없다고 불평합니다. 물론 거의 모든 최신 브라우저가 이제 자동으로 업데이트되기 때문에 이 문제는 서서히 사라지고 있습니다. 그러나 최신 브라우저를 사용하더라도 제안과 기능의 일반 가용성 사이에는 항상 지연이 있습니다.

흥미롭게도 이것은 웹의 모든 영역에서 해당되는 것은 아닙니다. 최근 JavaScript에서 작동하는 방식을 고려하십시오.

이 시나리오에서 아이디어를 얻은 후 프로덕션에서 사용하는 데 걸리는 시간은 며칠이 될 수 있습니다. 내 말은, 이미 프로덕션에서 async / await 기능을 사용하고 있으며 그 기능은 단일 브라우저에서도 구현되지 않았습니다!

또한 이 두 커뮤니티의 일반적인 감정에서 큰 차이를 볼 수 있습니다. JavaScript 커뮤니티에서 사람들이 상황이 너무 빠르게 진행되고 있다고 불평하는 기사를 읽습니다. 반면에 CSS에서는 사람들이 새로운 것을 실제로 사용할 수 있기까지 얼마나 오래 걸릴 것이기 때문에 새로운 것을 배우는 것이 무의미하다고 한탄하는 것을 듣습니다.

그렇다면 CSS Polyfill을 더 많이 작성하지 않는 이유는 무엇입니까?

처음에는 더 많은 CSS 폴리필을 작성하는 것이 답처럼 보일 수 있습니다. 좋은 폴리필을 사용하면 CSS가 JavaScript만큼 빠르게 이동할 수 있습니다.

슬프게도, 그것은 그렇게 간단하지 않습니다. CSS 폴리필은 엄청나게 어렵고 대부분의 경우 성능을 완전히 파괴하지 않는 방식으로 수행하는 것이 불가능합니다.

JavaScript는 동적 언어이므로 JavaScript를 사용하여 JavaScript를 폴리필할 수 있습니다. 매우 동적이기 때문에 확장성이 매우 뛰어납니다. 반면 CSS는 CSS를 폴리필하는 데 거의 사용할 수 없습니다. 어떤 경우에는 빌드 단계에서 CSS를 CSS로 변환할 수 있습니다(PostCSS가 이 작업을 수행함). 그러나 DOM의 구조나 요소의 레이아웃 또는 위치에 따라 달라지는 모든 것을 폴리필하려면 폴리필의 논리 클라이언트 측을 실행해야 합니다.

불행히도 브라우저는 이것을 쉽게 만들지 않습니다.

아래 차트는 브라우저가 HTML 문서를 수신한 후 화면에 픽셀을 표시하는 방법에 대한 기본 개요를 제공합니다. 파란색으로 표시된 단계는 JavaScript가 결과를 제어할 수 있는 위치를 보여줍니다.

사진이 상당히 암울합니다. 개발자는 브라우저가 HTML 및 CSS를 구문 분석하여 DOM 및 CSS 개체 모델(CSSOM)로 변환하는 방법을 제어할 수 없습니다. 캐스케이드를 제어할 수 없습니다. 브라우저가 DOM의 요소 배치를 선택하는 방법이나 이러한 요소를 화면에 시각적으로 그리는 방법을 제어할 수 없습니다. 그리고 당신은 합성기가 하는 일을 통제할 수 없습니다.

전체 액세스 권한이 있는 프로세스의 유일한 부분은 DOM입니다. CSSOM은 다소 개방적입니다. 그러나 Houdini 웹사이트를 인용하자면 "과소 지정되고 브라우저 간에 일관성이 없으며 중요한 기능이 누락되었습니다."

예를 들어, 오늘날 브라우저의 CSSOM은 교차 출처 스타일 시트에 대한 규칙을 표시하지 않으며 이해하지 못하는 CSS 규칙이나 선언을 무시합니다. 즉, 브라우저의 기능을 폴리필하려는 경우 지원하지 않으면 CSSOM을 사용할 수 없습니다. 대신 DOM을 살펴보고 <style> 및/또는 <link rel=“stylesheet”> 태그를 찾아 CSS를 직접 가져와 구문 분석하고 다시 작성한 다음 DOM에 다시 추가해야 합니다.

물론 DOM 업데이트는 일반적으로 브라우저가 전체 캐스케이드, 레이아웃, 페인트 및 합성 단계를 다시 거쳐야 함을 의미합니다.

페이지를 완전히 다시 렌더링해야 하는 경우(특히 일부 웹 사이트의 경우) 성능 저하가 그렇게 크지 않을 수 있지만 잠재적으로 이러한 일이 얼마나 자주 발생해야 하는지 고려하십시오. 폴리필의 로직이 스크롤 이벤트, 창 크기 조정, 마우스 이동, 키보드 이벤트와 같은 것에 대한 응답으로 실행되어야 하는 경우 - 실제로 모든 변경 사항이 있을 때마다 - 상황이 눈에 띄게, 때로는 심지어 심하게 느려질 것입니다.

오늘날 대부분의 CSS 폴리필에 자체 CSS 파서와 자체 캐스케이드 로직이 포함되어 있다는 사실을 알게 되면 상황은 더욱 악화됩니다. 그리고 파싱과 캐스케이드는 실제로 매우 복잡한 일이기 때문에 이러한 폴리필은 일반적으로 너무 크거나 버그가 너무 많습니다.

내가 방금 말한 모든 것을 더 간결하게 요약하자면: 브라우저가 해야 할 일과 다른 일을 하도록 하려면(CSS가 제공한 경우) 업데이트 및 수정하여 이를 가짜로 만드는 방법을 찾아야 합니다. DOM 자신. 렌더링 파이프라인의 다른 단계에 액세스할 수 없습니다.

하지만 브라우저의 내부 렌더링 엔진을 수정하고 싶은 이유는 무엇입니까?

나에게 이것은 이 전체 기사에서 대답해야 할 절대적으로 가장 중요한 질문입니다. 그러니 지금까지 대충 훑어보셨다면 이 부분을 천천히 주의 깊게 읽으세요!

마지막 섹션을 보고 나면 "이건 필요 없어! 저는 그냥 일반 웹 페이지를 만들고 있습니다. 나는 브라우저의 내부를 해킹하거나 아주 멋지고 실험적이거나 최첨단을 구축하려는 것이 아닙니다.”

그렇게 생각하신다면 잠시 뒤로 물러나 지난 몇 년 동안 웹사이트를 구축하는 데 사용해온 기술을 실제로 살펴보시기 바랍니다. 브라우저의 스타일 지정 프로세스에 대한 액세스 및 연결을 원하는 것은 멋진 데모를 구축하는 것뿐만 아니라 개발자와 프레임워크 작성자에게 두 가지 기본 작업을 수행할 수 있는 권한을 제공하는 것입니다.

• 브라우저 간 차이를 정규화하기 위해
• 사람들이 오늘날 사용할 수 있도록 새로운 기능을 발명하거나 폴리필합니다.

jQuery와 같은 JavaScript 라이브러리를 사용한 적이 있다면 이미 이 기능의 이점을 누리고 있을 것입니다! 사실 이것은 오늘날 거의 모든 프론트엔드 라이브러리와 프레임워크의 주요 판매 포인트 중 하나입니다. GitHub에서 가장 인기 있는 5개의 JavaScript 및 DOM 리포지토리(AngularJS, D3, jQuery, React 및 Ember)는 모두 브라우저 간 차이를 정규화하여 생각할 필요가 없도록 많은 작업을 수행합니다. 각각은 단일 API를 노출하며 작동합니다.

이제 CSS와 모든 브라우저 간 문제에 대해 생각해 보십시오. 브라우저 간 호환성을 주장하는 Bootstrap 및 Foundation과 같은 인기 있는 CSS 프레임워크조차도 실제로는 브라우저 간 버그를 정규화하지 않고 그냥 피합니다. 그리고 CSS의 브라우저 간 버그는 과거의 일이 아닙니다. 오늘날에도 flexbox와 같은 새로운 레이아웃 모듈로 인해 브라우저 간 비호환성이 많이 발생합니다.

결론은 CSS 속성을 사용할 수 있고 모든 브라우저에서 정확히 동일하게 작동할 것이라는 것을 알 수 있다면 개발 생활이 얼마나 더 좋을지 상상해 보십시오. CSS 그리드, CSS 스냅 포인트 및 고정 위치와 같은 블로그 게시물에서 읽거나 회의 및 모임에서 듣게 되는 모든 새로운 기능에 대해 생각해 보십시오. 현재 모든 기능을 기본 CSS 기능 만큼 성능 이 좋은 방식으로 사용할 수 있다고 상상해 보십시오. 그리고 GitHub에서 코드를 가져오기만 하면 됩니다.

이것이 후디니의 꿈입니다. 이것이 바로 태스크포스가 실현하고자 하는 미래입니다.

따라서 CSS 폴리필을 작성하거나 실험적인 기능을 개발할 계획이 없더라도 다른 사람들이 그렇게 할 수 있기를 원할 것입니다. 왜냐하면 이러한 폴리필이 존재하면 모든 사람이 혜택을 받기 때문입니다.

현재 개발 중인 Houdini 기능은 무엇입니까?

위에서 개발자는 브라우저의 렌더링 파이프라인에 대한 액세스 포인트가 거의 없다고 언급했습니다. 실제로 유일한 장소는 DOM과 어느 정도 CSSOM입니다.

이 문제를 해결하기 위해 Houdini 태스크 포스는 처음으로 개발자가 렌더링 파이프라인의 다른 부분에 액세스할 수 있도록 하는 몇 가지 새로운 사양을 도입했습니다. 아래 차트는 파이프라인과 어떤 단계를 수정하는 데 사용할 수 있는 새로운 사양을 보여줍니다. (회색으로 표시된 사양은 계획 중이지만 아직 작성되지 않았습니다.)

다음 몇 섹션에서는 각각의 새로운 사양과 해당 사양이 제공하는 기능의 종류에 대한 간략한 개요를 제공합니다. 다른 사양은 이 기사에서 언급되지 않았습니다. 전체 목록은 Houdini 초안의 GitHub 리포지토리를 참조하세요.

CSS 파서 API

CSS Parser API는 현재 작성되지 않았습니다. 그래서 내가 말하는 것 중 많은 부분이 쉽게 바뀔 수 있지만 기본 아이디어는 개발자가 CSS 파서를 확장하고 새로운 구성에 대해 알릴 수 있다는 것입니다. 예를 들어 새로운 미디어 규칙, 새로운 의사 클래스, 중첩, @extends , @apply 등

파서는 이러한 새로운 구성에 대해 알게 되면 그냥 버리는 대신 CSSOM의 올바른 위치에 배치할 수 있습니다.

CSS 속성 및 값 API

CSS에는 이미 사용자 정의 속성이 있으며, 이전에 표현한 것처럼 이러한 속성이 잠금 해제될 가능성에 대해 매우 흥분됩니다. CSS 속성 및 값 API는 사용자 정의 속성을 한 단계 더 발전시키고 유형을 추가하여 더욱 유용하게 만듭니다.

사용자 정의 속성에 유형을 추가하는 것에는 많은 좋은 점이 있지만 가장 큰 장점은 개발자가 유형을 통해 사용자 정의 속성을 전환하고 애니메이션할 수 있다는 점일 것입니다. 이는 오늘날 우리가 할 수 없는 일입니다.

다음 예를 고려하십시오.

 body { --primary-theme-color: tomato; transition: --primary-theme-color 1s ease-in-out; } body.night-theme { --primary-theme-color: darkred; }

위의 코드에서 night-theme 클래스가 <body> 요소에 추가되면 –primary-theme-color 속성 값을 참조하는 페이지의 모든 단일 요소가 천천히 tomato 에서 darkred 로 전환됩니다. 오늘 이 작업을 수행하려면 속성 자체를 전환할 수 없기 때문에 이러한 각 요소에 대한 전환을 수동으로 작성해야 합니다.

이 API의 또 다른 유망한 기능은 "후크 적용"을 등록하는 기능입니다. 이 기능은 개발자가 계단식 단계가 완료된 후 요소에 대한 사용자 정의 속성의 최종 값을 수정할 수 있는 방법을 제공하며, 이는 폴리필에 매우 유용한 기능이 될 수 있습니다.

CSS 유형 OM

CSS Typed OM은 현재 CSSOM의 버전 2로 생각할 수 있습니다. 그 목표는 현재 모델의 많은 문제를 해결하고 새로운 CSS Parsing API와 CSS Properties and Values ​​API에 의해 추가된 기능을 포함하는 것입니다.

Typed OM의 또 다른 주요 목표는 성능을 향상시키는 것입니다. 현재 CSSOM의 문자열 값을 의미 있는 형식의 JavaScript 표현으로 변환하면 상당한 성능 향상을 얻을 수 있습니다.

CSS 레이아웃 API

CSS 레이아웃 API를 사용하면 개발자가 자신의 레이아웃 모듈을 작성할 수 있습니다. 그리고 "레이아웃 모듈"이란 CSS display 속성에 전달할 수 있는 모든 것을 의미합니다. 이것은 개발자에게 처음으로 display: flex 및 display: table 과 같은 기본 레이아웃 모듈만큼 성능이 뛰어난 레이아웃 방법을 제공합니다.

예제 사용 사례로 Masonry 레이아웃 라이브러리는 개발자가 CSS만으로는 불가능한 복잡한 레이아웃을 달성하기 위해 오늘날 어느 정도까지 기꺼이 갈 수 있는지 보여줍니다. 이러한 레이아웃은 인상적이지만 불행히도 성능 문제, 특히 덜 강력한 장치에서 발생합니다.

CSS 레이아웃 API는 개발자에게 레이아웃 이름(나중에 CSS에서 사용됨)을 허용하는 registerLayout 메서드와 모든 레이아웃 논리를 포함하는 JavaScript 클래스를 제공하여 작동합니다. 다음은 registerLayout 을 통해 masonry 을 정의하는 방법에 대한 기본 예입니다.

 registerLayout('masonry', class { static get inputProperties() { return ['width', 'height'] } static get childrenInputProperties() { return ['x', 'y', 'position'] } layout(children, constraintSpace, styleMap, breakToken) { // Layout logic goes here. } }

위의 예에서 아무 것도 이해가 되지 않더라도 걱정하지 마십시오. 주의해야 할 주요 사항은 다음 예제의 코드입니다. masonry.js 파일을 다운로드하여 웹사이트에 추가했으면 다음과 같이 CSS를 작성할 수 있으며 모든 것이 제대로 작동합니다.

 body { display: layout('masonry'); }

CSS 페인트 API

CSS Paint API는 위의 Layout API와 매우 유사합니다. registerLayout 메서드처럼 작동하는 registerPaint 메서드를 제공합니다. 그런 다음 개발자는 CSS 이미지가 예상되는 모든 위치에서 CSS의 paint() 함수를 사용하고 등록된 이름을 전달할 수 있습니다.

다음은 색상이 지정된 원을 그리는 간단한 예입니다.

 registerPaint('circle', class { static get inputProperties() { return ['--circle-color']; } paint(ctx, geom, properties) { // Change the fill color. const color = properties.get('--circle-color'); ctx.fillStyle = color; // Determine the center point and radius. const x = geom.width / 2; const y = geom.height / 2; const radius = Math.min(x, y); // Draw the circle \o/ ctx.beginPath(); ctx.arc(x, y, radius, 0, 2 * Math.PI, false); ctx.fill(); } });

그리고 다음과 같이 CSS에서 사용할 수 있습니다.

 .bubble { --circle-color: blue; background-image: paint('circle'); }

이제 .bubble 요소가 배경으로 파란색 원이 표시됩니다. 원은 중앙에 위치하며 어떤 일이 일어나든 요소 자체와 크기가 같습니다.

워크렛

위에 나열된 많은 사양은 코드 샘플을 보여줍니다(예: registerLayout 및 registerPaint ). 해당 코드를 어디에 넣을지 궁금하다면 worklet 스크립트에 답이 있습니다.

Worklet은 웹 작업자와 유사하며 스크립트 파일을 가져오고 (1) 렌더링 파이프라인의 다양한 지점에서 호출할 수 있고 (2) 기본 스레드와 독립적인 JavaScript 코드를 실행할 수 있습니다.

Worklet 스크립트는 수행할 수 있는 작업 유형을 크게 제한하며 이는 고성능을 보장하는 데 중요합니다.

합성 스크롤 및 애니메이션

합성 스크롤링 및 애니메이션에 대한 공식 사양은 아직 없지만 실제로 Houdini에서 가장 잘 알려지고 기대되는 기능 중 하나입니다. 최종 API를 사용하면 개발자가 DOM 요소 속성의 제한된 하위 집합 수정을 지원하여 기본 스레드에서 벗어나 합성기 워크렛에서 논리를 실행할 수 있습니다. 이 하위 집합에는 렌더링 엔진이 레이아웃이나 스타일(예: 변형, 불투명도, 스크롤 오프셋)을 강제로 다시 계산하지 않고 읽거나 설정할 수 있는 속성만 포함됩니다.

이를 통해 개발자는 고정 스크롤 헤더 및 시차 효과와 같은 고성능 스크롤 및 입력 기반 애니메이션을 만들 수 있습니다. GitHub에서 이러한 API가 해결하려고 시도하는 사용 사례에 대해 자세히 읽을 수 있습니다.

아직 공식 사양은 없지만 Chrome에서 실험적인 개발이 이미 시작되었습니다. 실제로 Chrome 팀은 현재 이러한 API가 궁극적으로 노출할 프리미티브를 사용하여 CSS 스냅 포인트 및 고정 위치를 구현하고 있습니다. 이것은 Houdini API가 그 위에 새로운 Chrome 기능이 구축될 만큼 충분히 성능이 있다는 것을 의미하기 때문에 놀랍습니다. Houdini가 네이티브만큼 빠르지 않을 것이라는 두려움이 여전히 있었다면 이 사실만으로도 그렇지 않다고 확신할 수 있습니다.

실제 예를 보기 위해 Surma는 Chrome의 내부 빌드에서 실행되는 비디오 데모를 녹화했습니다. 데모는 Twitter의 기본 모바일 앱에서 볼 수 있는 스크롤 헤더의 동작을 모방합니다. 작동 방식을 보려면 소스 코드를 확인하십시오.

지금 무엇을 할 수 있습니까?

언급했듯이 웹사이트를 구축하는 모든 사람은 Houdini에 관심을 가져야 한다고 생각합니다. 그것은 미래에 우리의 모든 삶을 훨씬 더 쉽게 만들 것입니다. Houdini 사양을 직접 사용하지 않더라도 거의 확실히 Houdini 사양 위에 구축된 것을 사용할 것입니다.

그리고 이 미래는 즉각적이지 않을 수도 있지만 아마도 우리가 생각하는 것보다 훨씬 더 가까울 것입니다. 모든 주요 브라우저 공급업체의 대표자들은 올해 초 시드니에서 열린 마지막 Houdini 대면 회의에 참석했으며 무엇을 구축할지 또는 어떻게 진행할지에 대한 이견이 거의 없었습니다.

내가 말할 수 있는 바에 따르면, Houdini가 될 것인지의 문제가 아니라, 언제 그리고 그것이 여러분 모두가 들어오는 곳입니다.

소프트웨어를 구축하는 다른 모든 사람들과 마찬가지로 브라우저 공급업체는 새로운 기능의 우선 순위를 지정해야 합니다. 그리고 그 우선 순위는 종종 사용자가 해당 기능을 얼마나 원하느냐에 따라 결정됩니다.

따라서 웹에서 스타일 및 레이아웃의 확장성에 관심이 있고 표준 프로세스를 거치지 않고 새로운 CSS 기능을 사용할 수 있는 세상에서 살고 싶다면 사용하는 브라우저의 개발자 관계 팀에 요청하고 이를 원한다고 알립니다.

도움을 줄 수 있는 다른 방법은 실제 사용 사례를 제공하는 것입니다. 오늘날에는 어렵거나 불가능한 스타일 및 레이아웃으로 수행할 수 있기를 원하는 것입니다. GitHub의 여러 초안에는 사용 사례 문서가 있으며 끌어오기 요청을 제출하여 아이디어를 제공할 수 있습니다. 문서가 없으면 문서를 시작할 수 있습니다.

Houdini 태스크 포스(및 일반적으로 W3C)의 구성원은 웹 개발자의 사려 깊은 의견을 원합니다. 사양 작성 프로세스에 참여하는 대부분의 사람들은 브라우저에서 작업하는 엔지니어입니다. 그들은 종종 전문 웹 개발자가 아니므로 항상 문제점이 어디에 있는지 알지 못합니다.

그들은 우리가 그들에게 말해주기를 원합니다.

리소스 및 링크

• CSS-TAG Houdini Editor Drafts, W3C 모든 Houdini 초안의 최신 공개 버전
• CSS-TAG Houdini Task Force 사양, GitHub 사양 업데이트 및 개발이 이루어지는 공식 Github 저장소
• Houdini 샘플, 가능한 API를 보여주고 실험하는 GitHub 코드 예제
• Houdini 메일링 리스트, W3C 일반적인 질문을 하는 곳

이 기사를 검토해 주신 Houdini 회원 Ian Kilpatrick과 Shane Stephens에게 특별한 감사를 전합니다.