비즈니스 웹 사이트를위한 CSS 구조에 대한 팁 (또는 해당 사항에 대한 모든 것)

CSS와 HTML은 이해하기 쉽습니다. 그러나 웹 사이트 (및 앱)를 재사용하고 유지 관리 할 수 ​​있으며 개발자를 행복하게 만드는 방식으로 웹 사이트 (및 앱)를 구축 할 때 최상의 아키텍처 접근 방식에 대해 배우려면 수년 간의 연습이 필요합니다.

여기서 건축이란 무엇을 의미합니까? CSS 코드의 구조입니다. 파일로 분리하는 방법, 클래스 이름 뒤에있는 규칙, 선택기의 깊이, 계단식, 상속되는 방법, 구성 요소, 페이지, 요소 및 수정자를 설정하는 방법.

수백 개의 페이지, 다양한 유형의 콘텐츠, 화면보기, 엣지 케이스가있는 이러한 모든 웹 사이트 구성 요소에 모범 사례를 적용하고 상단에 더 많은 항목을 추가하고 기존 항목을 수정하는 것을 고려하는 것은 어려운 부분입니다.

페이지가 아닌 구성 요소로 빌드

이것은 고려해야 할 주요 부분 중 하나입니다. 현재 페이지를 기반으로 스타일을 지정해서는 안됩니다. .homepage… {} 스타일을 사용하지 마십시오. 페이지에 섹션이있는 경우 섹션 스타일을 지정하십시오. 이를 통해 다른 페이지에서도 재사용 할 수 있습니다. 버튼이있는 경우 .button {}과 같은 스타일을 지정하고 다른 곳에서 다시 사용하세요. 모든보기에 유효합니다.

이것은 당신이 활용할 수있는 가장 일반적인 조언이자 (지금까지) 가장 실적이 좋은 접근법입니다.

이제 페이지 별 차이점을 어떻게 관리합니까? 이것이 페이지 당 스타일을 지정하는 가장 일반적인 이유이기 때문입니까? 음, 몇 가지 접근 방식이 있습니다.

수정자를 사용하십시오.

"BEM"에서 "M"은 수정자를 나타냅니다. 이것은 .block__child–modifier 모양입니다. BEM을 사용하지 않더라도 수정자는 어쨌든 존재합니다. 구성 요소 또는 섹션에 변형이있는 경우 수정자를 추가하십시오.

이상적으로는 디자이너는 코드를 깔끔하게 유지하기 위해 신중하고 변형을 최소화해야하지만 더 많은 것을 추가하는 것을 두려워해서는 안됩니다. 변형은 이상적으로는 몇 가지 속성 만 덮어 쓰고 동일한 마크 업으로 작동해야합니다. HTML 단계에서 구성 요소에 접근하는 좋은 방법입니다. 필요한 태그를 추가하고 사이트 전체에서 일관성을 유지합니다. 수정 자 클래스 때문에 새로운 것을 추가하지 마십시오.

어린이 구성 요소의 스타일을 지정합니다.

다른 접근 방식은 컨텍스트에 따라 스타일을 지정하는 것입니다. 버튼은 항상 버튼이며 .button 클래스와 모든 것이 있지만 다른 구성 요소의 일부인 경우 여전히 조정할 수 있습니다. 이것은 일반적으로 불일치를 생성하기 때문에 좋은 생각은 아니지만 매우 현실적인 사용 사례이기도합니다. 그렇지 않으면 이상한 이름의 수정자가 20 개로 끝납니다.

상황 별 스타일은 한 구성 요소가 다른 구성 요소의 자식 인 경우에만 스타일을 지정하는 것입니다. 예를 들어 기사 카드를 보겠습니다. 기본적으로 스타일이 있습니다. 그러나 측면에 텍스트가있는 다채로운 섹션의 일부인 경우 카드 주변에 애니메이션 모양 등의 몇 가지 다른 요소가 있어야합니다.

이 경우 .parent .card {} 선택기로 스타일을 지정합니다. 수정 자에서하는 것처럼 몇 가지 속성 만 덮어 쓰면됩니다. 그렇게 할 때 카드 자체는 스타일에 복잡성을 더하지 않지만 특정 가장자리 케이스에서 여전히 올바르게 작동합니다.

이것에 대해 생각하면 "페이지 당"기준으로 적용 할 수있는 방법도 알 수 있습니다. 디자인에 이상한 경우가 있고 표준 구성 요소보기 (및 모두 함께 상호 작용하는 방식)와 약간의 차이가있는 경우 .homepage {} 선택기를 사용하여 스타일을 지정할 수 있습니다. 아껴서 사용하는 것을 명심하십시오. 경험상 이러한 스타일은 코드 몇 줄을 거의 넘지 않습니다.

추가해야 할 중요 사항 : 상황 별 스타일은 일반적으로 좋은 습관이 아닙니다. 이상적으로는 필요하지도 않습니다. 대부분의 경우 작업을 충분히 수행해야하는 수정자가 있습니다. 일부 빌드에서는 현실적이긴하지만 엄격한 규칙을 사용하여 추상화 된 좋은 코드에 너무 깊이 들어가면 비용이 너무 많이들 수 있습니다.

섹션에서 작업

대부분의 비즈니스 웹 사이트 (및 해당 문제에 대한 다른 많은 웹 사이트)는 콘텐츠를 섹션으로 분리합니다. 각 섹션은 다양한 속성을 정의하는 수정 자 클래스가있는 자체 구성 요소입니다. 클래스 구조에 대한 한 가지 제안은 다음과 같습니다.

• section.section-container – 원하는 경우 "구성 요소 이름"이 될 수 있으며, 이는 일관된 패딩 / 여백 또는 필요한 모든 것을 보유합니다.
• section.section-border-top – 수정 자입니다. BEM을 사용하지 않지만 필요한 경우 섹션 컨테이너 테두리로 "변환"할 수 있습니다.
• section.section-welcome – 섹션의 이름 입니다.

명명 규칙은 여기서도 관련이 없습니다. 이러한 섹션을 사용하면 디자인에 의해 생성 된 가장자리 케이스의 재사용 가능한 구성 요소에 대한 스타일을 자유롭게 조정할 수 있습니다 (따라야하는 불일치 또는 더 복잡한보기로 인해).

파일 분리

아마도 Sass 또는 다른 유사한 전처리기를 사용할 것입니다. 파일 분리와 관련하여 많은 접근 방식이 있지만 우리가 취하는 접근 방식은 다음과 같은 일반적인 구조를 따릅니다.

• 일반 – 일반은 일반적으로 그리드 작업 만들기, HTML 태그에 대한 스타일, 재설정 / 정규화, 일부 CMS 특정 스타일 등의 설정 코드로 구성됩니다.
• 페이지 – 위에서 설명한 페이지 스타일입니다. 이상적으로는 여기에 코드를 거의 유지하지 않아야합니다.
• 구성 요소 – 빌드의 핵심 – 다양한 구성 요소가 여기에 있습니다. 한 가지 팁은 80 개의 파일 대신 더 작은 구성 요소 청크를 하나의 파일에 맞출 수있는 "요소"또는 "기타"를 가질 수 있다는 것입니다. 물론 더 큰 파일은 별도의 파일에 저장하는 것이 좋습니다.
• 레이아웃 – 예를 들어 머리글, 바닥 글 및 페이지 레이아웃, 그리드에 대한 수정 자 등의 전역 스타일.
• 플러그인 – 플러그인, 확장 또는 기타에서 생성 된 외부의 모든 것. 다른 프로젝트에서 재사용 할 수 있으므로 분리하는 것이 좋습니다.

선택기를 깨끗하게 유지

깨끗한 코드의 좋은 징조는 그것이 얼마나 단순 해 보이는가입니다. 이상한 속성이 없으며 모든 것이 목적이 있으며 들여 쓰기가 적습니다. 불필요 할 때 "스마트하게 보이는"선택기는 코드를 "멋지게"만들지 않습니다. #container> .row div [rel =”something”]과 같은 것을 .rel-something (의미있는 클래스 이름이라고 상상해보십시오)으로 대체 할 수 있다면 마크 업을 약간 업데이트해야합니다. 이것의 목표는 모든 것을 더 단순하게 유지하는 것입니다.

들여 쓰기를 낮게 유지하십시오. 세 단계 이상으로 갈 필요는 거의 없습니다. 예를 들어 .entry 클래스를 보겠습니다.

.entry {...}
.entry-title {...}

.entry 안에 .entry-title을 들여 쓰기 할 필요가 없습니다. 나중에 파일에 수정자를 추가하면 .entry-modifier {} 및 .entry-modifier .entry-title {}을 사용할 수 있습니다.

이 접근 방식을 사용하면 향후 스타일 덮어 쓰기가 훨씬 쉬워집니다. 또 다른 일반적인 예를 살펴 보겠습니다. nav.site-nav> ul.list-menu> li.list-items * 5> a (emmet) 마크 업이 있습니다.

이제 스타일에 필요한 것은 다음과 같습니다.

.site-nav {}-구성 요소 1

.list-menu {}-구성 요소 2
.list-menu .list-item {}
.list-menu a {}

추가 드롭 다운과 같이 내부에 더 많은 구성 요소가있는 경우 .list-menu 안에 직접 중첩 할 수 있습니다. .list-menu .dropdown {}의 두 수준을 가질 수있는 경우 .site-nav .list-menu .list-item .dropdown {} (4 수준 깊이)을 작성할 필요가 없습니다.

수정 자에 대한 더 많은 추상 클래스 이름 작성

이것은 유지 보수성을위한 것입니다. 유사한 게시물에서 찾을 수있는 일반적인 예는 색상 변수를 $ red로 설정하지 않고 대신 $ primary 또는 $ secondary로 설정하는 것입니다.

그 이유는 변경이 필요한 경우 $ red 변수가 파란색을 출력하기 때문입니다. 붉은 색이 아닌 원색 을 바꾸고 싶다는 것이 더 의미가 있습니다.

다른 유형의 색상과 속성도 마찬가지입니다. 일부 콘텐츠를 구분하는 줄이 있다고 가정 해 보겠습니다 (예 : <hr> 태그). .line-dash는 파선이므로 이름을 지정합니다. 완벽합니다. 하지만 변화가 일어나고 점선으로 표시되어야합니다. 가서 .line-dotted로 이름을 바꾸시겠습니까? 이것은 수정자가 아니라 구성 요소입니다. 대신 .line-separator로 이름을 지정할 수 있습니다. 그런 다음 구체적으로 지정하려면 .dotted 또는 .dashed에 대한 수정자를 추가 할 수 있습니다. 이러한 유형의 이름 지정은 사이트를 구축 할 때 가장 많은 시간이 걸리는 경우가 많습니다.

요약하자면

수많은 좋은 습관과 나쁜 습관이 있습니다. 더 나은 결과를 얻는 한 가지 방법은 규칙을 정의하고 따르는 것입니다. 그러한 규칙을 마련하기가 어렵 기 때문에 웹을 탐색하고 명명 규칙, 모범 사례, 유지 관리 가능한 코드 작성 방법 등과 같은 아키텍처에서 가능한 모든 정보를 수집하는 것이 좋습니다.

좋은 코드를 생성하려면 많은 시간과 수십만 줄의 코드가 필요합니다. 이 모든 작업을 수행하는 동안 항상 "그 크기를 조정할 수 있습니까?", "다시 사용할 수 있습니까?", "너무 많이 덮어 썼습니까?", "이렇게 이름을 지정하는 것이 합리적입니까?"라고 자문 해보십시오. 그렇게할수록 결정이 더 최적화되고 작업 속도가 향상됩니다.

좋은 펀더멘털에 대한 투자는 프로젝트에서 앞뒤로 덜 진행될 것이며 향후 발생해야 할 변경 사항은 구현하기가 훨씬 더 쉬울 것입니다.