접근 방식
접근 방식 (Approach)
Bootstrap을 빌드하고 유지보수하는 데 사용되는 지침 원칙, 전략, 기법을 배워서 스스로 더 쉽게 커스터마이즈하고 확장해 보아요.
출처: 문서
본문
시작하기 페이지가 프로젝트와 그 기능에 대한 입문 투어를 제공한다면, 이 문서는 우리가 Bootstrap에서 하는 일의 이유에 초점을 맞춰요. 웹에서 구축하는 우리의 철학을 설명해서 다른 사람들이 우리에게서 배우고, 함께 기여하며, 개선을 도울 수 있게 하려는 거예요.
뭔가 맞지 않는 것 같거나 더 잘할 수 있을 것 같은 게 보이나요? 이슈를 열어 주세요. 여러분과 논의하고 싶어요.
요약 (Summary)
이 각각에 대해 자세히 다루겠지만, 높은 수준에서 우리의 접근 방식을 이끄는 것은 다음과 같아요.
- 컴포넌트는 반응형이고 모바일 우선(mobile-first)이어야 해요.
- 컴포넌트는 기본 클래스로 빌드되고 수정자 클래스로 확장되어야 해요.
- 컴포넌트 상태는 공통의 z-index 스케일을 따라야 해요.
- 가능하면 JavaScript보다 HTML과 CSS 구현을 선호해요.
- 가능하면 커스텀 스타일보다 유틸리티를 사용해요.
- 가능하면 엄격한 HTML 요구 사항(자식 셀렉터)을 강제하는 것을 피해요.
반응형 (Responsive)
Bootstrap의 반응형 스타일은 반응형으로 빌드되어 있어요. 이를 흔히 모바일 우선(mobile-first) 접근 방식이라고 불러요. 우리는 문서에서 이 용어를 사용하고 대체로 동의하지만, 때로는 너무 광범위할 수 있어요. Bootstrap에서 모든 컴포넌트가 완전히 반응형일 필요는 없지만, 이 반응형 접근 방식은 뷰포트가 커질수록 스타일을 추가하도록 유도해서 CSS 재정의를 줄이는 데 관한 것이에요.
Bootstrap 전반에서 이 점이 미디어 쿼리에서 가장 명확하게 드러나요. 대부분의 경우 특정 브레이크포인트에서 적용되기 시작해 더 높은 브레이크포인트까지 이어지는 min-width 쿼리를 사용해요. 예를 들어 .d-none은 min-width: 0부터 무한대까지 적용돼요. 반면 .d-md-none은 중간(medium) 브레이크포인트 이상부터 적용돼요.
때로는 컴포넌트의 고유한 복잡성 때문에 max-width를 사용할 때도 있어요. 때때로 이러한 재정의가 핵심 기능을 다시 작성하는 것보다 기능적·개념적으로 더 명확하게 구현하고 지원할 수 있어요. 우리는 이 접근 방식을 제한하려고 노력하지만 가끔 사용하기도 해요.
클래스 (Classes)
크로스 브라우저 정규화 스타일시트인 Reboot를 제외하면, 모든 스타일이 클래스를 셀렉터로 사용하는 것을 지향해요. 즉 타입 셀렉터(예: input[type="text"])와 스타일을 너무 구체적으로 만들어 재정의하기 어렵게 하는 불필요한 부모 클래스(예: .parent .child)를 피한다는 뜻이에요.
따라서 컴포넌트는 공통적이고 재정의되지 않아야 할 프로퍼티-값 쌍을 담는 기본 클래스로 빌드되어야 해요. 예를 들어 .btn과 .btn-primary처럼요. display, padding, border-width 같은 모든 공통 스타일에 .btn을 사용해요. 그런 다음 색상, background-color, border-color 등을 추가하기 위해 .btn-primary 같은 수정자를 사용해요.
수정자 클래스는 여러 변형에 걸쳐 변경할 프로퍼티나 값이 여러 개 있을 때만 사용해야 해요. 수정자가 항상 필요한 것은 아니므로, 수정자를 만들 때 실제로 코드 줄을 절약하고 불필요한 재정의를 막고 있는지 확인해야 해요. 테마 색상 클래스와 크기 변형이 수정자의 좋은 예시예요.
z-index 스케일 (z-index scales)
Bootstrap에는 두 가지 z-index 스케일이 있어요—컴포넌트 내부의 요소와 오버레이 컴포넌트요.
컴포넌트 요소 (Component elements)
- Bootstrap의 일부 컴포넌트는 border 프로퍼티를 수정하지 않고 이중 테두리를 막기 위해 겹치는 요소로 빌드돼요. 예를 들어 button groups, input groups, pagination이 있어요.
- 이 컴포넌트들은 0부터 3까지의 표준 z-index 스케일을 공유해요.
- 0은 기본값(initial), 1은
:hover, 2는:active/.active, 3은:focus예요. - 이 접근 방식은 사용자 우선순위가 가장 높은 것에 대한 우리의 기대와 일치해요. 요소가 포커스되면 화면에 보이고 사용자의 주의를 받고 있는 것이므로요. 활성 요소는 상태를 나타내므로 두 번째로 높아요. 호버는 사용자의 의도를 나타내므로 세 번째로 높지만, 거의 무엇이든 호버될 수 있어요.
오버레이 컴포넌트 (Overlay components)
Bootstrap에는 어떤 종류의 오버레이로 기능하는 여러 컴포넌트가 포함돼 있어요. z-index가 가장 높은 순서대로 드롭다운, 고정 및 스티키 내비바, modal, tooltip, popover가 여기에 해당해요. 이 컴포넌트들은 1000부터 시작하는 자체 z-index 스케일을 가져요. 이 시작 숫자는 임의로 선택된 것으로, 우리 스타일과 여러분 프로젝트의 커스텀 스타일 사이에 작은 완충 역할을 해요.
각 오버레이 컴포넌트는 z-index 값을 약간씩 높여서, 사용자가 포커스하거나 호버한 요소가 항상 화면에 보이도록 유지하는 공통 UI 원칙을 따르게 해요. 예를 들어 modal은 문서를 차단하므로(즉 modal의 동작 외에는 다른 조치를 취할 수 없음), 우리는 modal을 내비바 위에 둬요.
이에 대해 더 알아보려면 z-index 레이아웃 페이지를 확인해 보세요.
JS보다 HTML과 CSS (HTML and CSS over JS)
가능하면 HTML과 CSS를 JavaScript보다 먼저 작성하는 것을 선호해요. 일반적으로 HTML과 CSS는 더 널리 쓰이고 다양한 경험 수준의 더 많은 사람들이 접근할 수 있어요. HTML과 CSS는 브라우저에서 JavaScript보다 빠르고, 브라우저는 일반적으로 많은 기능을 제공해 주거든요.
이 원칙이 data attributes를 사용하는 우리의 일급(first-class) JavaScript API예요. JavaScript 플러그인을 사용하기 위해 거의 JavaScript를 작성할 필요 없이 HTML만 작성하면 돼요. 이에 대한 자세한 내용은 JavaScript 개요 페이지에서 읽어 보세요.
마지막으로 우리 스타일은 공통 웹 요소의 기본 동작 위에 구축돼요. 가능하면 브라우저가 제공하는 것을 사용하는 것을 선호해요. 예를 들어 거의 모든 요소에 .btn 클래스를 넣을 수 있지만, 대부분의 요소는 의미론적 가치나 브라우저 기능을 제공하지 않아요. 그래서 대신 <button>과 <a>를 사용해요.
더 복잡한 컴포넌트도 마찬가지예요. 입력 상태에 따라 부모 요소에 클래스를 추가해서 텍스트를 빨간색으로 스타일링하는 자체 폼 검증 플러그인을 작성할 수도 있지만, 우리는 모든 브라우저가 제공하는 :valid/:invalid 의사 요소를 사용하는 것을 선호해요.
유틸리티 (Utilities)
유틸리티 클래스—이전 Bootstrap 3의 helper—는 CSS 비대화와 페이지 성능 저하에 맞서는 강력한 동맹이에요. 유틸리티 클래스는 일반적으로 클래스로 표현되는 단일하고 불변하는 프로퍼티-값 쌍이에요(예: .d-block은 display: block;을 나타냄). 주요 매력은 HTML을 작성하는 동안 빠르게 사용할 수 있고 작성해야 할 커스텀 CSS 양을 제한하는 것이에요.
특히 커스텀 CSS와 관련해, 유틸리티는 가장 자주 반복되는 프로퍼티-값 쌍을 단일 클래스로 줄여 파일 크기 증가에 대응하는 데 도움을 줄 수 있어요. 이는 프로젝트 규모에서 극적인 효과를 낼 수 있어요.
유연한 HTML (Flexible HTML)
항상 가능한 것은 아니지만, 컴포넌트의 HTML 요구 사항에 대해 지나치게 독단적이 되는 것을 피하려고 노력해요. 그래서 CSS 셀렉터에서 단일 클래스에 집중하고 즉시 자식 셀렉터(>)를 피하려고 해요. 이렇게 하면 구현에서 더 많은 유연성을 얻고 CSS를 더 단순하고 덜 구체적으로 유지하는 데 도움이 돼요.
코드 규칙 (Code conventions)
Code Guide(Bootstrap 공동 창립자 @mdo의 것)는 우리가 Bootstrap 전반에서 HTML과 CSS를 작성하는 방법을 문서화해요. 일반적인 포맷, 상식적인 기본값, 프로퍼티와 속성 순서 등에 대한 지침을 지정해요.
Sass/CSS에서 이 표준과 그 이상을 강제하기 위해 Stylelint를 사용해요. 우리의 커스텀 Stylelint 구성은 오픈 소스이며 다른 사람들이 사용하고 확장할 수 있도록 제공돼요.
표준적이고 의미론적인 HTML을 강제하고 일반적인 오류를 감지하기 위해 vnu-jar를 사용해요.