path: root/files/ko/mdn/guidelines/code_guidelines/css/index.html

---
title: CSS 가이드라인
slug: MDN/Guidelines/Code_guidelines/CSS
translation_of: MDN/Guidelines/Code_guidelines/CSS
---
<div>{{MDNSidebar}}{{IncludeSubnav("/en-US/docs/MDN")}}</div>

<p class="summary">다음 가이드라인은 MDN code 예제를 위한 CSS 작성 방법을 설명합니다.</p>

<h2 id="이번_기사에서는">이번 기사에서는</h2>

<ul>
 <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#High-level_guidelines">고급 가이드라인</a>

  <ul>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Dont_use_preprocessors">전처리기를 사용하지 마십시오</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Dont_use_specific_CSS_methodologies">특정 CSS 방법론을 사용하지 마십시오</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Use_flexiblerelative_units">유연하고/상대적인 단위를 사용합니다</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Dont_use_resets">재설정을 사용하지 마십시오</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Plan_your_CSS_%E2%80%94_avoid_overriding">CSS 계획 — 재정의 (overriding) 를 방지합니다</a></li>
  </ul>
 </li>
 <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#General_CSS_coding_style">일반적인 CSS 코딩 스타일</a>
  <ul>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Use_expanded_syntax">확장 구문을 사용합니다</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Favor_longhand_rules_over_terse_shorthand">속기 (shorthand) 보다는 longhand 규칙을 좋아합니다</a> </li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Use_double_quotes_around_values">값을 큰 따옴표로 묶습니다</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Spacing_around_function_parameters">함수 매개변수 주위의 간격</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#CSS_comments">CSS 주석</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Dont_use_!important">!important 를 사용하지 마십시오</a></li>
  </ul>
 </li>
 <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Specific_CSS_syntax_points">특정 CSS 구문 포인트</a>
  <ul>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Turning_off_borders_and_other_properties">테두리 및 기타 속성 끄기</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Use_mobile_first_media_queries">"모바일 우선" 미디어 쿼리 사용</a></li>
  </ul>
 </li>
 <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Selectors">선택자</a>
  <ul>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Dont_use_ID_selectors">ID 선택자를 사용하지 마십시오</a></li>
   <li><a href="/en-US/docs/MDN/Contribute/Guidelines/Code_guidelines/CSS#Put_multiple_selectors_on_separate_lines">여러 라인을 별도의 라인에 배치</a></li>
  </ul>
 </li>
</ul>

<h2 id="High-level_guidelines">High-level guidelines</h2>

<h3 id="Dont_use_preprocessors">Don't use preprocessors</h3>

<p>Don't use preprocessor syntax, e.g. <a href="https://sass-lang.com/">Sass</a>, <a href="http://lesscss.org/">Less</a>, or <a href="http://stylus-lang.com/">Stylus,</a> in your MDN example code. MDN documents the vanilla CSS language, and using preprocessors only serves to raise the bar to understanding the examples, potentially confusing readers.</p>

<h3 id="Dont_use_specific_CSS_methodologies">Don't use specific CSS methodologies</h3>

<p>In the same spirit as the previous guideline, don't write MDN example code using a specific CSS methodology such as <a href="http://getbem.com/naming/">BEM</a> or <a href="https://smacss.com/">SMACSS</a>. Even though they are valid CSS syntax, the naming conventions can be confusing to people not familiar with those methodologies.</p>

<h3 id="Use_flexiblerelative_units">Use flexible/relative units</h3>

<p>For maximum flexibility over the widest possible range of devices, it is a good idea to size containers, padding, etc. using relative units like ems and rems, or percentages and viewport units if you want them to vary depending on viewport width. You can read some more about this in our <a href="/en-US/docs/Web/Apps/app_layout/responsive_design_building_blocks#Fluid_grids">Responsive design building blocks</a> article.</p>

<h3 id="Dont_use_resets">Don't use resets</h3>

<p>For maximum control over CSS across platforms, a lot of people used to use CSS resets to remove every style, before then building things back up themselves. This certainly has its merits, but especially in the modern world CSS resets can be overkill, resulting in lots of extra time spent reimplementing things that weren't completely broken in the first place, like default margins, list styles, etc.</p>

<p>If you really feel like you need to use a reset, consider using <a href="http://necolas.github.io/normalize.css/">normalize.css by Nicolas Gallagher</a>, which aims to just make things more consistent across browsers, get rid of some default annoyances that we always remove (the margins on <code>&lt;body&gt;</code>, for example) and fix a few bugs.</p>

<h3 id="Plan_your_CSS_—_avoid_overriding">Plan your CSS — avoid overriding</h3>

<p>Before diving in and writing huge chunks of CSS, plan your styles carefully. What general styles are going to be needed, what different layouts do you need to create, what specific overrides need to be created, and are they reusable? Above all, you need to try to avoid too much overriding. If you keep finding yourself writing styles and then cancelling them again a few rulesets down, you probably need to rethink your strategy.</p>

<h2 id="General_CSS_coding_style">General CSS coding style</h2>

<h3 id="Use_expanded_syntax">Use expanded syntax</h3>

<p>There are a variety of CSS writing styles you can use, but we prefer the expanded style, with the selector/opening brace, close brace, and each declaration on a separate line. This maximizes readability, and again, promotes consistency on MDN.</p>

<p>Use this:</p>

<pre class="brush: css example-good notranslate">p {
  color: white;
  background-color: black;
  padding: 1rem;
}</pre>

<p>Not this:</p>

<pre class="brush: css example-bad notranslate">p { color: white; background-color: black; padding: 1rem; }</pre>

<p>In addition, keep these specifics in mind:</p>

<ul>
 <li>Include a space between the selector(s) and the opening curly brace.</li>
 <li>Always include a semi-colon at the end of the last declaration, even though it isn't strictly necessary.</li>
 <li>Put the closing curly brace on a new line.</li>
 <li>In each declaration, put a space after the separating colon, but not before.</li>
 <li>Use 2 spaces for code indentation.</li>
</ul>

<h3 id="Favor_longhand_rules_over_terse_shorthand">Favor longhand rules over terse shorthand</h3>

<p>Usually when teaching the specifics of CSS syntax, it is clearer and more obvious to use longhand properties, rather than terse shorthand (unless of course teaching the shorthand is the point of the example). Remember that the point of MDN examples is to teach people, not to be clever or efficient.</p>

<p>To start with, it is often harder to understand what the shorthand is doing. It takes a while to pick apart exactly what {{cssxref("font")}} syntax is doing, for example:</p>

<pre class="brush: css notranslate">font: small-caps bold 2rem/1.5 sans-serif;</pre>

<p>Whereas this is more immediate in terms of understanding:</p>

<pre class="brush: css notranslate">font-variant: small-caps;
font-weight: bold;
font-size: 2rem;
line-height: 1.5;
font-family: sans-serif;</pre>

<p>Second, CSS shorthand comes with potential added pitfalls — default values are set for parts of the syntax that you don't explicitly set, which can produce unexpected resets of values you've set earlier in the cascade, or other expected effects. The {{cssxref("grid")}} property for example sets all of the following default values for items that are not specified:</p>

<ul>
 <li>{{cssxref("grid-template-rows")}}: <code>none</code></li>
 <li>{{cssxref("grid-template-columns")}}: <code>none</code></li>
 <li>{{cssxref("grid-template-areas")}}: <code>none</code></li>
 <li>{{cssxref("grid-auto-rows")}}: <code>auto</code></li>
 <li>{{cssxref("grid-auto-columns")}}: <code>auto</code></li>
 <li>{{cssxref("grid-auto-flow")}}: <code>row</code></li>
 <li>{{cssxref("grid-column-gap")}}: <code>0</code></li>
 <li>{{cssxref("grid-row-gap")}}: <code>0</code></li>
 <li>{{cssxref("column-gap")}}: <code>normal</code></li>
 <li>{{cssxref("row-gap")}}: <code>normal</code></li>
</ul>

<p>In addition, some shorthands only work as expected if you include the different value components in a certain order. In CSS animations for example:</p>

<pre class="brush: css notranslate">/* duration | timing-function | delay | iteration-count
   direction | fill-mode | play-state | name */
animation: 3s ease-in 1s 2 reverse both paused slidein;</pre>

<p>As an example, the first value that can be parsed as a <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/time" title="The &lt;time> CSS data type represents a time value expressed in seconds or milliseconds. It is used in animation, transition, and related properties."><code>&lt;time&gt;</code></a> is assigned to the <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/animation-duration" title="The animation-duration CSS property sets the length of time that an animation takes to complete one cycle."><code>animation-duration</code></a>, and the second one is assigned to <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/animation-delay" title="The animation-delay CSS property sets when an animation starts. The animation can start later, immediately from its beginning, or immediately and partway through the animation."><code>animation-delay</code></a>. For more details, read the full <a href="/en-US/docs/Web/CSS/animation#Syntax">animation syntax</a> details.</p>

<h3 id="Use_double_quotes_around_values">Use double quotes around values</h3>

<p>Where quotes can or should be included, use them, and use double quotes. For example:</p>

<pre class="brush: css example-good notranslate">[data-vegetable="liquid"] {
  background-color: goldenrod;
  background-image: url("../../media/examples/lizard.png");
}</pre>

<h3 id="Spacing_around_function_parameters">Spacing around function parameters</h3>

<p>Function parameters should have spaces after their separating commas, but not before:</p>

<pre class="brush: css example-good notranslate">color: rgb(255, 0, 0);
background-image: linear-gradient(to bottom, red, black);</pre>

<h3 id="CSS_comments">CSS comments</h3>

<p>Use CSS-style comments to comment code that isn't self-documenting:</p>

<pre class="brush: css example-good notranslate">/* This is a CSS-style comment */</pre>

<p>Put your comments on separate lines preceeding the code they are referring to:</p>

<pre class="brush: css example-good notranslate">h3 {
  /* Creates a red drop shadow, offset 1px right and down, w/2px blur radius */
  text-shadow: 1px 1px 2px red;
  /* Sets the font-size to double the default document font size */
  font-size: 2rem;
}</pre>

<p>Also note that you should leave a space between the asterisks and the comment, in each case.</p>

<h3 id="Dont_use_!important">Don't use !important</h3>

<p>!important is a last resort generally only used when you need to override something and there is no other way. It is a bad practice and you should avoid it wherever possible.</p>

<p>Bad:</p>

<pre class="brush: css example-bad notranslate">.bad-code {
  font-size: 4rem !important;
}</pre>

<h2 id="Specific_CSS_syntax_points">Specific CSS syntax points</h2>

<h3 id="Turning_off_borders_and_other_properties">Turning off borders and other properties</h3>

<p>When turning off borders (and any other properties that can take <code>0</code> or <code>none</code> as values), use <code>0</code> rather than <code>none</code>:</p>

<pre class="brush: css example-good notranslate">border: 0;</pre>

<h3 id="Use_mobile_first_media_queries">Use "mobile first" media queries</h3>

<p>When including different sets of styles for different target viewport sizes using media queries inside the same stylesheet, it is a good idea to make the default styling before any media queries have been applied to the document the narrow screen/mobile styling, and then override this for wider viewports inside successive media queries.</p>

<pre class="brush: css example-good notranslate">/*Default CSS layout for narrow screens*/

@media (min-width: 480px) {
  /*CSS for medium width screens*/
}

@media (min-width: 800px) {
  /*CSS for wide screens*/
}

@media (min-width: 1100px) {
  /*CSS for really wide screens*/
}</pre>

<p>This has many advantages, outlined in our <a href="/en-US/docs/Web/Apps/Progressive/Responsive/Mobile_first">Mobile First</a> article.</p>

<h2 id="Selectors">Selectors</h2>

<h3 id="Dont_use_ID_selectors">Don't use ID selectors</h3>

<p>There is really no need to use ID selectors — they are less flexible (you can't add more if you discover you need more than one), and are harder to override if needed, being of a higher specificity than classes.</p>

<p>Good:</p>

<pre class="brush: css example-good notranslate">.editorial-summary {
  ...
}</pre>

<p>Bad:</p>

<pre class="brush: css example-bad notranslate">#editorial-summary {
  ...
}</pre>

<h3 id="Put_multiple_selectors_on_separate_lines">Put multiple selectors on separate lines</h3>

<p>When a rule has multiple selectors, put each selector on a new line. This makes the selector list easier to read, and can help to make code lines shorter.</p>

<p>Do this:</p>

<pre class="brush: css example-good notranslate">h1,
h2,
h3 {
  font-family: sans-serif;
  text-align: center;
}</pre>

<p>Not this:</p>

<pre class="brush: css example-bad notranslate">h1, h2, h3 {
  font-family: sans-serif;
  text-align: center;
}</pre>

<h2 id="Good_CSS_examples_on_MDN">Good CSS examples on MDN</h2>

<p>You can find good, concise, meaningful CSS snippets at the top of our CSS property reference pages — browse through our <a href="/en-US/docs/Web/CSS/Reference#Keyword_index">CSS keyword index</a> to find some. Our interactive examples are generally written to follow the above guidelines, although be aware that they may differ in some places as they were mostly written before the guidelines were newly written.</p>