> 웹 프론트엔드 > CSS 튜토리얼 > 원자 CSS 제작 : Thierry Koblentz와의 인터뷰

원자 CSS 제작 : Thierry Koblentz와의 인터뷰

Lisa Kudrow
풀어 주다: 2025-03-14 09:44:17
원래의
911명이 탐색했습니다.

원자 CSS 제작 : Thierry Kobleentz와의 인터뷰

이 기사는 원자 CSS의 제작자 인 Thierry Kobleentz를 인터뷰 하여이 인기있는 CSS 프레임 워크의 역사와 맥락을 심도있게 살펴 봅니다. Thierry는 현재 은퇴했으며 대형 CSS를 작성하는 데 광범위한 경험을 가지고 있으며 Yahoo의 프론트 엔드 엔지니어로 일했습니다.

Thierry는 Smashing Magazine의 고전적인 2013 기사“도전적인 CSS 모범 사례”에 대한 원자 CSS 개념을 주류로 가져 오는 것으로 널리 알려져 있습니다. 이 기사는 수년 동안 많은 인기있는 CSS 라이브러리의 길을 열어줍니다. 이 인터뷰에서 Thierry는 원자 CSS의 역사를 검토하고 지속적인 영향을 반영합니다.

21 세기 초반, 웹 개발 분야에 어떻게 들어갔습니까? 특히 CSS를 작성하여 어떻게 생계를 유지 했습니까?

Thierry Kobletz : 1997 년 미국으로 이사 한 후, 나는 HTML, CSS 및 JavaScript를 취미로 가르쳤다.

당시 나는 프론트 페이지를 사용하고 있었고 안내를 위해 뉴스 그룹에 크게 의존했습니다. 나는 Macromedia Newsgroups와 CSS-Discument의 정기적 인 고객이되었습니다. 초기에 저는 웹 표준 프로젝트 철학을 지원하고 접근성에 대한 강력한 관심을 개발했습니다. 몇 년 동안, 프론트 엔드는 저에게 취미였습니다 (나의 진짜 직업은 골동품 딜러입니다). 나는 때때로 웹 사이트를 만들 것이지만, 주로 배운 기사를 공유하거나“발견 한”기사를 공유하고 게시하고 있습니다.

이것은 2007 년 Yahoo의 전화로 Yahoo! 직업 설명 : HTML 없음, JavaScript, CSS 만! 그리고 많은!

Yahoo에서 매일 직업은 무엇입니까?

TK : Yahoo에서의 나의 역할은 수년에 걸쳐 많이 바뀌 었습니다.

저의 첫 번째 직업은 YSS 템플릿 (CSS Zen Garden과 유사)에 대한 스타일 시트를 만드는 것이 었습니다. 그런 다음 YSS가 Bangalore (인도)에“배달”하기 전에 YSS 웹 사이트의 표시와 스타일을 다시 작성했습니다. 동료와 저는“지식 전달”으로 보내졌습니다.

그건 그렇고, 그것은 스타일 시트를 교체하여 YSS에 대한 다양한 디자인을 만드는 데 어려움을 겪고 있습니다 .

YSS 이후, 나는 처음부터 시작하여 프로젝트에만 참여할 수있는 기회를 가졌으며 (다시 쓰기 또는 기타) Yahoo 프론트 엔드 작업에 점점 더 관여하고 있습니다. 나는 내부 문서를 편집하고있다 제안 및 및.

Yahoo에서 8 년 동안 100 줄의 JavaScript 코드가 없을 것입니다. 내가 그만두거나 해고되지 않았다면 Lingyan Zhu와 Renato Iwashima 덕분에 그들은 내 환경을 설정하거나 명령 줄을 처리하는 데 지칠 줄 모르고 도와주었습니다.

당시 인기있는 CSS 작문 연습은 무엇입니까?

TK : 초기에는 도서관이나 출판 된 방법이 없었습니다. 그것은 "비 미용"클래스, ID, CSS 해킹, 조건부 주석, 프레임 워크, "JS Probing", 주로 인터넷 익스플로러를 위해 설계되었습니다. 내 오래된 사이트에서는 다음과 같은 의견을 가지고있었습니다.

<code></code>
로그인 후 복사

모든 것이 공정한 경쟁이며, 우리는 매우 제한된 도구 세트 만 가지고 있고 많은 일을해야하기 때문에 모든 것이 남용됩니다.

그러나 야후에 합류했을 때 상황이 크게 바뀌 었습니다. 영국의 개발자들은 웹 표준의 확고한 지지자이며 Yahoo의 HTML 및 CSS가 어떻게 작성되는지에 큰 영향을 주셔서 감사합니다. 시맨틱 태깅은 현실이며, CSS는 우려 분리 원칙 (SOC)에 따라 작성된 "T"입니다 (때로는 너무 열심인데도).

Yui에는 CSS 구성 요소가 있지만 아직 CSS 프레임 워크가 없습니다. 내부 CSS 라이브러리 (레고라고 함)가 있지만 사용한 적이 없습니다. OOCSS, SMACSSS, ECSS (Ben에게 경례), BEM, 부트 스트랩, Pure 및 기타 방법 및 라이브러리가 곧 나타납니다.

원자 CSS에 대한 아이디어는 어떻게 생겼습니까?

TK : YSS가 인도로 이사하기 전에, Michael Montesano 감독은 편집 스타일 시트를 피하기 위해 방갈로르의 팀을 얻을 수있는 방법이 있는지 물었습니다. YSS 템플릿 (유료 고객이 페이지가 손상된 것에 대해 불평)의 경험은 스타일 시트를 변경할 때 매우 편집증이 생깁니다.

따라서 EZ -CSS 라이브러리의 정신으로, 나는 개발자가 스타일 시트에 규칙을 편집하거나 추가하지 않고 스타일을 구현할 수 있도록 설계된 "Utilitary Table"을 만들었습니다.

몇 년 후, 엔지니어링 담당 이사 인 Michael은 유틸리티 클래스를 사용하여 Yahoo의 홈페이지를 재 설계 할 수 있는지 물어 보았습니다. 우리는 시맨틱 클래스보다 유틸리티 클래스의 우선 순위를 정하는 것에 대해 논의했으며, 그 수준에서 당시에는 존재하지 않았다고 생각 하지 않습니다 . 이것은 매우 대담한 움직임입니다.

이 거대한 운동은 빠르게 개념 증명이되어 태그 로 스타일링의 많은 이점을 보여줍니다. 그것은 너무 많은 상자를 점검하여 "정적"스타일 시트 (Stencil)를 사용하여 내 홈 제품을 재 설계하기로 결정했습니다.

원자 CSS (ACSS)를 설계 할 때 따라야 할 지침은 무엇입니까? 누가 참여합니까?

TK : 스텐실 라이브러리는 정적이며 디자인 스타일을 시행하는 훌륭한 도구입니다. 우리는 야후가 모든 속성 에서이 스타일을 채택하려고한다고 생각합니다. 우리는 이것이 일어나지 않을 것이라는 것을 빨리 깨달았습니다. 각 야후 디자인 팀은 완벽한 글꼴 크기, 완벽한 여백 등에 대한 고유 한 의견을 가지고 있습니다. 우리는 도서관에 매우 구체적인 스타일을 추가하라는 요청을 계속받습니다.

이 상황은 유지할 수 없으므로 개발자가 창의적인 방법의 원자 특성을 존중하면서 자신의 스타일을 즉시 만들 수있는 도구를 개발하기로 결정했습니다. 이것이 원자력이 태어난 방식입니다. 우리는 스타일 (CSS 선언) 추가를 중단하고 대신 미디어 쿼리, 후손 선택기, 의사 클래스 등과 같은 광범위한 스타일을 개발자에게 제공하는 풍부한 어휘를 만드는 데 중점을 두었습니다.

ACSS를 통해 개발자는 원하는 것을 자유롭게 사용할 수 있습니다. 그리고 개발자가 사용했던 스타일에 대한 새로운 직접적인 이점이 있습니다. 그들은 더 이상 자신의 스타일이 페이지를 끊는 것에 대해 걱정할 필요가 없으며, 선택기를 작성하여 구성 요소를 스타일링하는 것에 대해 걱정할 필요가 없습니다.

ACSS는 원래 Yahoo의 문제를 해결하고 Yahoo의 환경에서 일하기 위해 만들어졌습니다.

원자 CSS에 관련된 사람들은 Renato Iwashima, Steve Carlson 및 나 자신을 포함합니다. Renato와 Steve는 분무기를 만들었습니다.

사람들이 대기업에 CSS를 쓰지 않을 때 CSS에 대한 오해는 무엇입니까?

TK : 2007 년 Yahoo에 합류했을 때 코드 기반이 얼마나 큰지 빨리 배웠습니다. There are teams across many locations/time zones; countless products; hundreds of shared components; third-party code; A/B testing strategies; as a requirement extension; different scripting directions; localization and internationalization; various release cycles; complex deployment mechanisms; a large number of metrics; various legacies; strict coding standards; construction processes; politics; and more politics; and so on.

이 대부분은 나에게 새롭고 CSS를 쓰는 방식에 어떤 영향을 미치는지 여부와 방법을 배워야합니다. 나에게 공통적 인 관행 인 많은 기술이나 방법이 복잡한 응용에 적합하지 않거나 적어도 복잡한 응용 프로그램에 비생산적이지 않기 때문에 나는 모든 믿음을 다시 방문하고 도전하기 시작했습니다.

"현실 점검"은 스타일 추상화와 관련이 있습니다. 우리는 모두 M-10 클래스를 마진에 매핑하는 것이 마진에 매핑하는 것이 좋은 생각이 아니라고 말하는 기사를 읽었습니다. HTML과 CSS가 스타일을 변경하기 위해 편집하는 것을 의미하기 때문입니다. 불행히도, 이것은 대규모/복잡한 프로젝트에서 일어나는 일입니다.

  • 디자이너 : 15 픽셀 간격을 원합니다
  • 개발자 : 좋아, 그것은 M-3X (5 픽셀 단위)입니다.
  • 디자이너 : 물론, 무엇이든!
  • 개발자 : 완료되었습니다!
  • 디자이너 : 실제로 15 픽셀이 너무 큽니다. 12 픽셀로 변경할 수 있습니까?
  • 개발자 : 아니요, 10 픽셀 또는 15 픽셀이 없습니다.
  • 디자이너 : 죄송합니다. 저에게는 효과가 없습니다. M-3X를 12 픽셀로 변경할 수 있습니까?
  • 개발자 : 아니요! 다른 팀은 M-3X가 15 픽셀이 될 것으로 기대하기 때문에 그렇게 할 수 없습니다.
  • 디자이너 : 좋아, 우리는 마진이 12 픽셀이되기를 원하기 때문에 방법을 알아 내려고 노력하십시오. 15 픽셀은 너무 많고 10 픽셀은 너무 적습니다.
  • 개발자 : (죽음으로 가십시오!)

그러한 문제를 예측하기 위해서는 요청 뒤에 디자이너의 의도를 이해해야합니다. 색상 기본과 같은 추상화 또는 M-3X 케이스의 15 픽셀 마진과 같은 특정 값으로 인해 선택된 스타일은? 디자인 원칙을 시행하기위한 스타일 가이드가 있다면 M-3X와 같은 클래스는 괜찮을 수 있지만 디자인 팀이 원하는 스타일을 요청할 수있는 스타일로 이어질 수있는 규칙을 피하는 것이 좋습니다. 내 경험상, 모든 모호성은 손상을 초래할 수 있습니다.

스타일 설정을위한 문서 또는 구성 요소의 구조에 의존합니다.> 또는 같은 조합은 스타일 시트를 작성하는 깔끔한 방법과 같은 콤비너를 통해 복잡한 환경에서는 특정 태그 나 구조가 불변이라고 가정 할 수 없다는 사실을 무시합니다.

Z-Index가 복잡하다고 생각하십니까? 구성 요소가있는 스택 범위가 없을 때 다시 생각하십시오. 이것은 팀이 페이지의 다른 부분을 담당하는 대규모 프로젝트에서 해결해야 할 가장 복잡한 문제 중 하나입니다. 나는 한 번 이것에 대한 제안을 썼다.

input.required and .input.required와 같은 자격을 갖춘 선택기는 멋지고 시맨틱하지만 0.1.1과 0.2.0과 같은 불필요한 수준의 특이성을 생성하고 태그 변경을 쉽게 방지합니다.

글로벌 범위 스타일을 설정하기 위해 와일드 카드 선택기*에 의존합니까? 매우 큰 프로젝트에서 이것은 당신이 다른 사람들의 구성 요소를 스타일링하고 있음을 의미 할 수 있습니다. 자신의 요구를 이해하지 않는 한 다른 사람을 위해 스타일 결정을 내리지 마십시오.

나는 당신이 신분증이 나쁘다는 것을 믿습니다. 특이성은 나쁘지만. 사실은. 높은 특이성은 규칙에 의해 생성 된 특이성 수준만큼 문제가되지 않습니다. 예를 들어, 1.1.0, 0.1.0, 0.2.0의 존재가 1.1.0, 0.1.1, 0.2.1, 0.2.2 등과 같은 경우에 "무료 경쟁"접근 방식을 따르는 환경보다 2 ~ 3 단계 만 존재하는 환경에서 스타일이 훨씬 쉽습니다.

CSS 커뮤니티의 조언을 맹목적으로 따르는 것은 불쾌한 놀라움으로 이어질 수 있습니다. 실제로 테스트되지 않은 새로운 기술을 채택하지 마십시오. 윌을 기억하십니까? 그리고 항상 당신이 사용하는 각 스타일이나 그것을 유발할 수 있는지 항상 알고 있습니다. 예를 들어, 위치는 스태킹 컨텍스트와 포함 블록을 생성 할 수 있으며 오버 플로우는 블록 형식 컨텍스트를 생성 할 수 있습니다.

내 경험상, CSS에 대한 깊은 이해는 대규모 조직이 CSS를 효율적으로 작성하기에 충분하지 않습니다. 야후에서의 시간 동안, 나는 종종 몇 년 전에 나와 함께 있었던 사람들과 충돌하는 것을 발견했습니다. 환경은 매우 잔인하며 많은 함정을 피하기 위해 매우 실용적이 필요합니다. 다음에 큰 프로젝트의 소스 코드를보고 당신에게 의미가없는 것을 볼 때, Nicholas Zakas 의이 트윗을 기억하십시오.

사람들이 어리 석고 무지하고 실수를 저지르고, 똑똑하다고 가정하고, 최선을 다하며, 배경이 부족하다고 가정하지 마십시오.

- Nicholas C. Zakas (@slicknet) 2013 년 2 월 10 일

Yahoo의 원자 CSS 로의 전환은 어떻게 내부적으로 받아 들여지 는가?

TK : 우리의 홈페이지 팀은 ACS를 잘 받아 들였지만 외부에는 잘되지 않았습니다. 우리의 첫 번째 상호 작용은 산타 모니카에 위치한 스포츠 팀과였습니다. Steve와 저는 컨퍼런스 콜에서 개발자들에게 우려 분리 원칙을 따르지 않는 것이 옳은 일이며 혼란을 유발하지 않는다고 설득하려고했습니다.

우리는 그들에게 Nicolas Gallagher의 최근 기사를 지적했다. 일이 잘 진행되지 않고 마찰이 많이 있습니다. 주요 문제는 라이브러리가 유틸리티 클래스로 구성되어 있지만 구문은 대화를 완화하는 데 도움이되지 않는다는 것입니다.

원자 CSS의 아이디어에 반대하지 않았지만 ACSS 구문을 견딜 수 없었기 때문에 "정상적인"CSS 선언을 사용하기 위해 자체 JavaScript 방법을 생각해 내고 싶었던 이메일 팀과 만나는 것을 기억합니다. 그럼에도 불구하고 라이브러리를 지원하는 데이터 (CSS 및 HTML의 약 36% 감소)는 자체적으로 자체적으로 말하면 ACSS가 끝입니다. 7 년이 지난 지금, Yahoo Homepage, Yahoo Sports, Yahoo News, Yahoo Finance 및 기타 Yahoo 제품은 여전히 ​​ACSS를 사용하고 있습니다.

ACSS와 같은 접근 방식이 구성 요소 재사용 성이 중요한 프로젝트에 어떻게 도움이되는지 더 잘 이해하려면 Yahoo Finance의 구성 요소의 마크 업을 복사하여 Yahoo News에 붙여 넣습니다. 구성 요소는 페이지의 일부에 속하는 것처럼 보일 것입니다. ACSS는 이러한 구성 요소를 페이지와 독립적으로 만들기 때문입니다.

클래스 이름으로서의 괄호 방법은 어떻게 생겨나나요? 구문은 기능이 어떻게 작성되는지에 영감을 받습니까?

TK : 여러 반복을 통해 속성 값 분리기로 사용되는 두 세트의 "후보자"세트를 식별했습니다.

Renato는 추가 시프트 키 스트로크를 희생하더라도 JavaScript의 기능에 익숙했기 때문에 사각형 괄호 위로 괄호를 선택했다고 회상합니다. ACSS 구문은 다음과 같습니다.

  • 분무기를 통한 자동 생성 규칙을 홍보하십시오
  • 개발자가 원하는 임의 또는 복잡한 스타일을 만들 수 있습니다.
  • 학습 곡선을 최소화합니다

다음과 같이 보입니다.

 <code>[<context> [:<pseudo-class> ]<combinator> ][(<value> ,<value> ?,...)][][:<pseudo-class> ][::<pseudo-element> ][--<breakpoint_identifier> ]</breakpoint_identifier></pseudo-element></pseudo-class></value></value></combinator></pseudo-class></context></code>
로그인 후 복사

개발자는 위 구조에 따라 수업을 구축합니다. Core Syntax는 인기있는 툴킷 Emmet을 기반으로합니다. 핵심 클래스는 임의의 문자열이 아닌 명백한 속성/값 쌍이기 때문에 EMMET 방법을 사용합니다.

우리는 또한 12 개 이상의 보조 클래스를 만들었습니다. 이들은 여러 스타일의 선언을 적용하며 시각 장애가있는 사용자를 숨기는 컨텐츠 또는 .CF를 사용하는 Clearfix와 같은 해킹과 같은 바로 가기입니다. 또한 구성 파일이 .primaryColor와 같은 변수를 생성 할 수있는 구성 파일을 사용하여 개발자에게 더 많은 자유를 제공합니다.

ACSS를 사용한 적이없는 사람들은 구문이 너무 이상하다고 말할 것이지만, 친숙한 사람들은 여러 가지면에서 영리 하다고 말할 것입니다.

Smashing Magazine의 "Challenge CSS 모범 사례"기사가 어떻게 구현되는지 이야기하십시오.

TK : 이전에 다양한 온라인 출판물에 많은 글을 썼 으므로이 "도전적인"접근 방식에 대한 기사를 작성하는 것은 당연합니다.

야후는 2013 년 10 월 프론트 엔드 컨퍼런스를 후원했으며, 그곳에서 Renato는 솔루션을 소개하기 위해 연설을 마련했으며 그 전에이 기사를 게시하려고했습니다. 사이트가 주석 섹션을 제공하지 않기 때문에 Yahoo! 목록은 제 시간에 출판 할 수 없었지만 Smashing Magazine은 10 월 말까지 기사를 게시 할 수 있도록 검토 프로세스를 가속화했습니다.

게시물이 200 개가 넘는 의견을 받았기 때문에 의견 섹션이있는 출판사를 선택하는 데 대한 나의 접근 방식은 매우 시간이 많이 걸리고 실망 스러웠습니다. 저는 그 의견에 응답해야했습니다.

이 게시물은 여전히 ​​문제의 기술에 대한 면책 ​​조항을 가지고 있으며, 현재 업계에서 이미 인기가 있더라도 이상하다고 느끼나요?

TK : 이 기사가 출판되었을 때, 나는 Vitaly [Smashing Magazine의 공동 창립자 인 Friedman]에게 사람들이 기사를 읽는 방식에 영향을 미쳤습니다. 그러나 나는 Vitaly의 아이디어를 이해했기 때문에 실제로 그것을 반박하지 않았습니다. 나는이 메모가 여전히 흥미 롭다는 것을 알았고,이 접근법은 이제 주류가되었습니다.

뒤늦은 시점을 감안할 때 원자 CS의 어떤 측면을 바꾸고 싶습니까?

TK : 특히이 솔루션을 개척 한 후에는 항상 개선의 여지가 있습니다. 당신은 다른 사람들이 그들의 실수 나 단점에 대해 배우기 위해 무엇을했는지 볼 수 없습니다. 당신은 개선 된 재료가 없습니다. 우리가 처음으로 성공했다고 생각한다면, 그것은 자만 할 것입니다.

우리는 1 년 넘게 대규모 프로젝트에서 "정적"스타일 시트를 사용했기 때문에 원자 CSS에 대한 광범위한 경험을 가지고 있습니다. 그러나 역학 - 도구 - 도구 - 우리는 많은 영감을 얻지 못하는 것 같습니다. 다른 도서관이 따라야하는 데 6 년이 걸렸습니다.

프랑스어로 우리는 다음과 같이 말합니다. Essuyer Les plâtres . (닦음 먼지)

우리가 저지른 한 가지 실수는 "원자 CSS"를 acss.io의 제목으로 사용하는 것이 었습니다. John Polacek가 지적했듯이 이것은 약간의 혼란을 야기했기 때문입니다. 그 이후로 우리는 제목을 변경했습니다.

내가 후회하는 유일한 것은 커뮤니티가 수년에 걸쳐 원자 CSS/ACS를 어떻게 대우했는지, 최근에 누군가 가“원자 CSS”가 의미하는 바를 설명하는 이상한 교환으로 이어졌습니다.

원자 CSS 라이브러리 [ACSS]는이 이름을 사용하지만, 말하는 기능이 역동적 인 스타일 생성이기 때문에 오해의 소지가 있다고 생각합니다. "원자 CSS"는 작은 선택기를 원자로 지정하는 일반적인 용어이지만 정적입니다.

지워진 것에 대해 이야기하십시오. ;)

이 인터뷰에 참여하여 커뮤니티에 게시 할 수 있도록 Thierry에게 대단히 감사합니다.

위 내용은 원자 CSS 제작 : Thierry Koblentz와의 인터뷰의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.
저자별 최신 기사
인기 튜토리얼
더>
최신 다운로드
더>
웹 효과
웹사이트 소스 코드
웹사이트 자료
프론트엔드 템플릿