기본 CSS의 원리를 배울 때 유지 관리 가능성을 보장하기 위해 모듈식, 재사용 가능 및 설명 스타일을 작성하는 방법을 배웁니다. 그러나 개발자가 실제 애플리케이션에 참여하게 되면 스타일이 의도하지 않은 영역으로 누출되지 않고 UI 기능을 추가하는 것이 불가능하다고 느끼는 경우가 많습니다. 이 문제는 종종 자체 충족 루프로 눈덩이처럼 불어납니다. 이론적으로 하나의 요소나 클래스로 범위가 지정된 스타일은 자신이 속하지 않는 곳에 나타나기 시작합니다. 이로 인해 개발자는 유출된 스타일을 재정의하기 위해 훨씬 더 구체적인 선택기를 만들어야 하며, 이로 인해 실수로 전역 스타일이 재정의되는 등의 일이 발생합니다. BEM과 같은 엄격한 클래스 이름 규칙은 이 문제에 대한 이론적 해결책 중 하나입니다. BEM(Block, Element, Modifier) ​​방법론은 CSS 파일 내에서 재사용성과 구조를 보장하기 위해 CSS 클래스 이름을 체계적으로 지정하는 방법입니다. 이와 같은 명명 규칙은 도메인 언어를 활용하여 요소와 해당 상태를 설명함으로써 인지 부하를 줄일 수 있으며, 올바르게 구현되면 대규모 애플리케이션의 스타일을 더 쉽게 유지 관리할 수 있습니다. 그러나 현실 세계에서는 항상 그렇게 되는 것은 아닙니다. 우선순위는 바뀔 수 있으며, 변경으로 인해 구현이 일관되지 않게 됩니다. HTML 구조를 조금만 변경하면 CSS 클래스 이름을 많이 수정해야 할 수 있습니다. 대화형 프런트 엔드 애플리케이션의 경우 BEM 패턴을 따르는 클래스 이름은 길고 다루기 힘들 수 있으며(예: app-user-overview__status--is-authenticating) 명명 규칙을 완전히 준수하지 않으면 시스템 구조가 손상되어 이점이 무효화됩니다. 이러한 문제를 고려할 때 개발자가 프레임워크로 눈을 돌리는 것은 당연합니다. Tailwind는 가장 인기 있는 CSS 프레임워크입니다. 스타일 사이에서 이길 수 없는 특수성 전쟁처럼 보이는 것에 맞서 싸우기보다는 CSS 캐스케이드를 포기하고 완전한 격리를 보장하는 도구를 사용하는 것이 더 쉽습니다. 개발자는 유틸리티에 더 많은 기대를 걸고 있습니다. 일부 개발자가 계단식 스타일을 피하고 싶어한다는 것을 어떻게 알 수 있습니까? 이러한 목적을 위해 특별히 설계된 CSS-in-JS 프레임워크와 같은 "현대적인" 프런트엔드 도구의 등장입니다. 특정 구성 요소에 엄격하게 적용되는 격리된 스타일을 사용하여 작업하는 것은 신선한 공기를 마시는 것처럼 보일 수 있습니다. 여전히 가장 싫어하고 시간이 많이 걸리는 프런트 엔드 작업 중 하나인 이름을 지정할 필요가 없으며 개발자가 CSS 상속의 이점을 완전히 이해하거나 활용하지 않고도 생산성을 발휘할 수 있습니다. 그러나 CSS 캐스케이드를 버리는 것에는 그 자체의 문제가 따릅니다. 예를 들어, JavaScript로 스타일을 구성하려면 무거운 빌드 구성이 필요하며 종종 스타일이 구성 요소 마크업이나 HTML과 어색하게 섞이게 됩니다. 신중하게 고려된 명명 규칙 대신, 우리는 빌드 도구가 선택기와 식별자(예: .jsx-3130221066)를 자동 생성하도록 허용하므로 개발자는 또 다른 의사 언어 자체를 따라잡아야 합니다. (마치 모든 구성 요소의 useEffects가 수행하는 작업을 이해하는 인지 부하가 아직 충분하지 않은 것처럼 보입니다!) 클래스 이름 지정 작업을 도구화로 더욱 추상화한다는 것은 기본 디버깅이 개발자 도구와 같은 라이브 디버깅을 지원하는 기본 브라우저 기능을 활용하는 대신 개발용으로 컴파일된 특정 애플리케이션 버전으로 제한되는 경우가 많다는 것을 의미합니다. 이는 표준 CSS 작성의 "고통"에서 벗어나기 위해 웹이 이미 제공하는 것을 추상화하기 위해 사용하는 도구를 디버깅하는 도구를 개발해야 하는 것과 거의 같습니다. 다행스럽게도 최신 CSS 기능은 표준 CSS 작성을 더욱 유연하게 만들어줄 뿐만 아니라 우리와 같은 개발자에게 계단식 배열을 관리하고 우리에게 적합하게 만들 수 있는 훨씬 더 많은 권한을 제공합니다. CSS 캐스케이드 레이어(Cascade Layers)가 좋은 예이지만 놀랄 만큼 주목을 받지 못하는 또 다른 기능이 있습니다. 하지만 최근 Baseline과 호환되므로 이러한 기능이 바뀌고 있습니다. CSS @scope At-Rule 나는 CSS @scope at-rule이 우리가 다룬 스타일 누출로 인한 불안에 대한 잠재적인 치료법이라고 생각합니다. 이는 추상화 및 추가 빌드 도구에 대한 기본 웹 이점을 타협하도록 강요하지 않습니다. "@scope CSS at-rule을 사용하면 특정 DOM 하위 트리의 요소를 선택할 수 있으며, 재정의하기 어려운 지나치게 구체적인 선택기를 작성하지 않고 선택기를 DOM 구조에 너무 긴밀하게 연결하지 않고도 요소를 정확하게 타겟팅할 수 있습니다."— MDN

즉, 상속, 계단식 배열 또는 기본적인 관심사 분리를 희생하지 않고도 특정 인스턴스에서 격리된 스타일로 작업할 수 있습니다.이는 오랫동안 프론트엔드 개발의 지침 원칙이었습니다. 게다가 브라우저 범위도 뛰어납니다. 실제로 Firefox 146은 12월에 @scope에 대한 지원을 추가하여 처음으로 Baseline과 호환되도록 만들었습니다. 다음은 BEM 패턴과 @scope 규칙을 사용하는 버튼 간의 간단한 비교입니다.

You May Also Like

Enjoyed This Article?

Get weekly tips on growing your audience and monetizing your content — straight to your inbox.

No spam. Join 138,000+ creators. Unsubscribe anytime.

Create Your Free Bio Page

Join 138,000+ creators on Seemless.

Get Started Free