교육
채용
코딩테스트
인증시험로그인기업서비스

크로스 브라우징 / CSS모듈화 / 반응형 관련 질문드립니다.

조회수 3647회
좋아요

0

싫어요

안녕하세요 야무님?

프론트엔드 개발 강의를 듣고 있는 박상준입니다.

우선 강의 덕분에 많이 배우고 있어서 감사하다는 말씀드리고 싶습니다.

감사합니다!

다름이 아니라 강의를 들으면서 실무에서 다음과 같은 사항을

어떻게 처리하는게 좋을지 궁금해서 질문남깁니다.

가. 크로스 브라우징

브라우저마다 엔진이 달라서 같은 html, css를 다르게 보여주는 경우가 많아서 이 때 브라우저 별 핵을 이용해서 동일하게 맞춰 주려고 하는데 이런식으로 처리하는게 맞는지 궁금합니다. 예를 들면 flex를 사용할 때 IE 11, 10에서 부분지원으로 깨지는 경우가 종종 발생해서 _:-ms-lang(x), 과 같은 핵을 이용해 조정하거나 margin, padding값이 상이해서 조정하는 경우입니다.

나. CSS모듈화

bootstrap과 같이 많이 사용할 CSS를 모듈로 만들어서 사용하면 효율적인 측면에서 더 좋을 것 같다는 생각이 있는데 네이밍, 어떤 경우 모듈로 사용해야 좋을지 아직 정확히 모르겠어서 야무님은 어떤생각이시고 어떻게 사용하시는지 알고 싶습니다. 또 모듈로 적용하고 싶으나 디자인 가이드라인이 늦게 나오고 개별 페이지 디자인만 먼저 나오는 상황에서는 어떻게 하는게 좋을 지 조언 부탁드립니다.

다. 반응형

 1-1 . 폰트
          폰트 같은 경우 고정된 px을 이용하기 보다 rem / em 과 같은 것을 이용하는 것이 좋다고 
          들었는데 rem을 이용한다면 중단점별 :root의 폰트 크기는 어떻게 조절하는 것이 좋을까
          요?

1-2 . 이미지
         디바이스 별로 밀도가 다르다는 말씀을 해주셨는데 그럼 만약 2,3,4배 밀도의 휴대폰을 각
         각 대응하려면 img src는 하나의 이미지만 연결되어있기때문에 대응을 못할 것 같은 생각
         이 드는데 그럼 @media 를 이용해서 resolution 별 background-img를 정해주는 방식으로 
         하면 될까요? 아니면 더 좋은 방법이 있을까요?

1-3. svg 사용시 
        디바이스 별 대응이 어려워짐에 따라서 실제 사진을 제외하고 svg로 만드는 것이 좋다고 말
        씀하셨는데 그럼 png처럼 네트워크 통신을 최소화하기 위한 방법인 이미지 스프라이트 기 
        법을 적용 할 수 있을까요? 어떻게 생각하시나요?

1-4. css 단위 사용 / Fluid 디자인
        주로 px을 사용하다보니 비율을 이용한 디자인에 대한 이해가 아직 부족한 것 같습니다.
        만약 다음과 같은 박스 모델이 있다면,

이미지

        :root {
            font-size:62.5%;
        }

        .containter {
            width : 100%; // 100vw 도 가능 할까요?
            max-width : 120rem;
            margin: 0 atuo;
            height : 500px; // px 대신 vh를 쓴다면 500/1200 이런식으로 계산해야할까요?
        }

       .item {
            width: 33.33%; // 33.33vw 일까요?
            height: 100%;
        }

       .desc {
            width: 100%;
            height: 50%;
            box-sizing : border-box;
            padding: 20px; // px로 주로 사용했는데 rem으로 고친다면 2rem 으로 하면 될까요?
        }

        강의 예제에서 vw, vh를 종종 사용하셨는데 관련한 css 단위 강의가 추가되었으면 좋겠습니
        다.(ex, ch 등등...)

아직 모르는게 많다고 느껴서 그런지 궁금한 점이 많았네요

질문이 길어져서 죄송합니다!

  • (•́ ✖ •̀)
    알 수 없는 사용자

1 답변

  • 좋아요

    3

    싫어요

    안녕하세요 상준님 :-)

    문의주신 질문아 하나 하나 답변 드려 봅니다.

    가. 크로스 브라우징

    저는 브라우저 핵이 아닌, 필터링 방식을 사용하여 크로스 브라우징 문제를 해결하는 방법을 선호합니다. 이를 처리하는 대표적인 필터링 라이브러리로 Modernizr가 있습니다. 사용법은 다음과 같습니다.

    Modernizr Download에서 필터링 할 기능을 검색한 후 선택합니다.

    이미지

    원하는 기능을 모두 선택한 후, BUILD 버튼을 눌러 Modernizr 커스텀 코드를 생성한 후, 다운로드 받습니다.

    이미지

    다운로드 받은 Modernizr 커스텀 라이브러리를 </head> 앞에 <script> 요소를 사용해 로드 하는 코드를 추가합니다.

      ...
  <script src="modernizr-custom.js"></script>
</head>

    이어서 <html> 요소에 class="no-js"를 추가합니다. (JavaScript 미지원 환경 임을 필터링 하기 위한 목적)

    <!DOCTYPE html>
<html lang="ko-KR" class="no-js">

    브라우저 개발도구에서 요소 탭을 확인해보면 <html> 요소 class 속성에 동적으로 필터링 추가 선택한 기능이 사용자 브라우저에서 지원하는지 유무를 값으로 설정해줍니다. 만약 지원하지 않는 기능이 있다면 no- 접두사가 붙은 값이 설정됩니다.

    CSS Flex를 지원하는 브라우저는 flexbox, 미지원 브라우저는 no-flexbox 이렇게 말이죠. 아래 이미지는 Chrome 브라우저에서 테스트한 결과라서 모두 지원한다고 알려줍니다.

    이미지

    이제 Modernizr를 사용할 준비가 마무리 되었습니다. 남은 일은 아래 코드와 같이 <html> 요소에 설정된 클래스를 통해 코드를 분기하여 디자인 하면 크로스 브라우징이 가능합니다. :-)

    .box {
   /* flexbox, rem 단위를 지원하는 브라우저에 반영할 디자인 */
}

.no-flexbox .box {
   /* flexbox를 지원하지 않는 브라우저에 반영할 디자인 */
}

.no-cssremunit .box {
   /* rem 단위를 지원하지 않는 브라우저에 반영할 디자인 */
}

    나. CSS모듈화

    네이밍과 모듈 디자인이 필요한 상황에 대해 질문 주셨는데요. 이야기를 풀어보겠습니다.

    네이밍

    먼저 네이밍은 전술(strategy)입니다. 작전에 사용 되는 기술 또는 방법인 것이죠.

    예를 들어 축구 경기를 들어보면 감독마다 사용하는 전술이 다릅니다. 공격을 선호하는 전술이 있는가 하면, 수비에 치중 하면서 역습을 노리는 전술, 공격과 수비 균형을 맞춘 전술 등등 다양한 전술이 있겠죠.

    마찬가지로 CSS를 사용해 성공적인 프로젝트를 수행하려면 다양한 경험과 효과적인 전술이 필요합니다. 새로운 전술을 구상하는 것도 방법 이겠지만 많은 경험치와 연구를 요구 하므로, 이미 검증된 전술을 도입하여 활용하는 것이 보다 효과적일 수 있습니다.

    이미 연구 및 검증된 CSS 전술(방법론)은 잘 알려진 것이 SMACSS , BEM, OOCSS 입니다. 어떤 방법론을 사용 하든지 목적은 같습니다. 효율적인 (재)사용, 불 필요함을 최소화, 효과적이고 능률적인 관리 등등.

    거론된 CSS 네이밍(전술)은 객체 지향 프로그래밍(OOP) 방법론과 유사합니다. 객체를 중심에 두고 어떻게 풀어갈 것인가 사고하는 것입니다. 객체는 기능이 작은 덩어리입니다. 버튼, 내비게이션, 탭 등 인터페이스를 구성하는 요소라고 생각할 수도 있습니다. 즉, 컴포넌트 또는 위젯 이라고 볼 수 있죠.

    추후 영상 강의에서 다루는 JavaScript OOP(OOJS 라고도 불림)를 학습하고 나서 다시 CSS 방법론에 대해 생각해보면 보이지 않던 것이 보이게 될 것입니다. :-)

    아무튼 검증된 방법론을 토대로 학습을 한 후, 각 방법론의 장점을 섞거나, 자신의 경험을 반영하여 새로운 규칙을 만들어 내는 것 또한 좋습니다. 제 경우는 BEM + SMACSS를 병합하고, 자신의 경험을 반영하여 사용하고 있습니다.

    /* Object */
.icon { ... }

/* IS */
.icon.is-small { ... }
.icon.is-disabled { ... }
.icon.is-animate { ... }

/* HAS */
.icon.has-text { ... }


/* Block */
.app-nav { ... }

/* Element */
.app-nav__link { ... }

/* Modifier (like SMACSS) */
.app-nav__link.has-children { ... }

    모듈화

    모듈화는 레고 블록을 결합해 다양한 객체를 만드는 것과 같습니다. 각 블록은 여러 객체에서 가져다 조립 가능하도록 독립적이고 재사용 하기 좋게 구성하는 것이 관건입니다.

    그런데 안타깝게도 CSS는 스타일 언어이지, 프로그래밍 언어라고 볼 수는 없습니다. 그래서 프로그래밍 방식의 접근이 100% 허용되지 않습니다. 제약이 따르는 것이지요. 프로그래머가 CSS를 싫어하는 이유도 여기에 있습니다.

    객체를 중심으로 사고하여 프로그래밍 하려면 클래스, 상속, 서브 클래싱, 오버라이딩, 캡슐화 등이 필요한데 CSS는 그러한 것들이 있을리 만무해서 .... T _T

    그래서 CSS가 아닌 Sass, LESS, Stylus와 같은 프리 프로세서(Pre Processor)가 등장했고 활용되기 시작했습니다. 프리 프로세서는 CSS를 확장하는 스크립트 언어라고 볼 수 있습니다. 즉, CSS에 없는 능력을 확장해 프로그래밍 방식으로 스타일을 할 수 있게 만들어 줍니다.

    이러한 이야기를 꺼낸 것은... 제대로 모듈화를 하려면 CSS 만으로는 턱없이 부족하다는 점을 이야기 하기 위해서 입니다. 제대로 모듈화하려면 프로그래밍 언어와 같은 능력이 필요하기 때문입니다.

    제 경우는 모듈화를 위해 Sass 프리 프로세서를 사용합니다. 제가 사용하는 모듈은 대부분 재사용을 목적으로 하는 함수, 믹스인, 플레이스홀더 모음이에요. (Sass에서 지원하는 기능들 입니다)

    이미지

    Sass로 코드를 작성해 모듈 단위로 개발된 코드를 사용하여 CSS로 변환해 배포하는 프로세스입니다. 아래 그림은 왼쪽의 Sass 코드가 오른쪽의 CSS로 변환 되었을 때 어떻게 변경 되는지 실시간으로 보여줍니다. sass2css.herokuapp.com 사이트에서 테스트 해보실 수 있습니다.

    이미지

    작성한 코드에 주석을 붙여보면 다음과 같습니다. 앞서 설명 했던 BEM + SMACSS 조합 방식으로 모듈 이름을 네이밍 하고 설계(Design) 하는 것이죠. Sass 문법은 Ruby의 영향을 받아 {}, ; 등을 생략해 사용합니다.

    // 블록(Block)
.app-nav
  // 지역 변수
  $gap: 1rem !default

  display: grid
  grid-column-gap: $gap

  // 엘리먼트(Element)
  &__link
    text-decoration: none
    justify-self: center

    // 모디파이어(Modifier, like SMACSS)
    &.has-children
      display: grid

    이러한 점 때문에 CSS에 익숙한 사용자는 Sass를 기피 하기도 합니다. 그래서 Sass에는 SCSS라는 문법 모드도 지원합니다. 문법이 CSS 처럼 {}, ;를 모두 사용하기에 거부감을 적게 느끼는 것 같습니다. 아래 코드는 SCSS 문법을 사용해 믹스인을 정의한 것입니다.

    // --------------------------------
// position 믹스인
// --------------------------------
@mixin position($position, $args) {
  position: $position;
  @if $args != null {
    @each $dir in top, left, bottom, right, z-index {
      $i: index($args, $dir);
      @if $i {
        #{$dir}: nth($args, $i + 1);
      }
    }
  }
}

// --------------------------------
// 단축 믹스인
// --------------------------------
@mixin static {
  @include position(static, null);
}

@mixin absolute($args: null) {
  @include position(absolute, $args);
}

@mixin relative($args: null) {
  @include position(relative, $args);
}

@mixin fixed($args: null) {
  @include position(fixed, $args);
}

    이와 같이 정의된 믹스인을 사용하면 자주 사용 되는 코드양을 대폭 줄일 수 있습니다. 아래 코드는 fixed() 믹스인과 rem() 함수를 사용한 코드입니다.

    .app-sticky-widget
  +fixed(top 0 left 0 right 0 z-index 100)
  height: rem(114px)

    위 코드는 아래와 같이 CSS 코드로 변경됩니다.

    .app-sticky-widget {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  z-index: 100;
  height: 7.125rem;
}

    만약 CSS Grid 믹스인을 만들어 사용하면 아래와 같이 활용도 가능할 겁니다.

    .gallery
  +grid(gap rem(10px) h center v top)
  &.is-4x3 
    +grid-template(r repeat(4, 1fr) c minmax(rem(100px), rem(200px)))

    위 코드는 아래와 같이 변환됩니다. 보다시피 Sass 문법을 공부해 활용한다면 효율성과 생산성은 극대화 될 수 있습니다.

    .gallary {
  display: grid;
  grid-gap: 0.625rem;
  justify-items: center;
  align-items: start;
}

.gallary.is-4x3 {
  grid-template-rows: repeat(4, 1fr);
  grid-template-columns: minmax(6.25rem, 12.5rem);
}

    그리고 디자인 가이드라인이 늦게 나온다거나, 개별 페이지 디자인만 먼저 나오는 상황은 디자이너(Designer)가 설계(Design) 할 줄 모르기 때문입니다. 아이러니 하죠. 디자이너라고 말하지만, 디자인을 할 줄 모른다는게...

    이유는 국내 디자인 교육 현실이 비주얼(Visual)을 디자인으로 보기 때문입니다. 체계(System), 협업(Collaboration), 효율(efficiency), 생산성(productivity), 재사용성(reusable) 등은 배운 적도 생각해 본 적도 없고, 오직 눈에 보이는 비주얼에만 매달립니다.

    저 또한 디자인 학도로 디자인을 전공하고 디자이너를 업으로 삼았었습니다만... 현업에서 느낀 경험은 깜깜했습니다. 막연한 감(feeling)에 의존하거나, 어디서 본 좋아 보이는 것을 아무런 죄의식 없이 표절(plagiarism) 하거나... (유명 광고대행사에서 버젓이 행한 신입 공채 홍보물 표절 기사 글 참고)

    그래서 코딩을 해 본 디자이너와 그렇지 않은 디자이너와 일했을 때 느껴지는 체감이 다른 것입니다. 코딩을 해봤다는 것은 설계(Design)하는 것에 대해 경험하고 고민해봤다는 것을 의미합니다. 그 경험이 비주얼 디자인에도 투영되게 되고 체계적인 결과를 도출할 수 있는 원동력이 됩니다.

    물론 오해의 소지가 없어야 합니다. 비주얼 디자이너 모두가 체계, 협업, 효율, 생산성, 재사용성 등을 고민하지 않는 것은 아닙니다. 다만, 대부분 국내 디자이너가 그렇지 않다는 것입니다. 소수는 매우 뛰어난 디자이너(설계자)입니다!

    디자인은 학문(學問)으로 체계적으로 배워서 익힐 수 있는 이론과 방법론이 정리되어 있습니다. 디자인을 제.대.로 공부 했다면 절대 감에 의존하거나, 표절하지 않을 겁니다. 그럼 왜? 감에 의존하거나 표절할까요? 정답은 체계가 없기 때문입니다. 즉, 이론과 방법론에 대한 훈련이 부족하다는 것입니다.

    그럼 다시 본론으로 돌아와서 "왜... 디자인 가이드라인이 늦게 나오고, 개별 페이지 디자인만 먼저 나오는 것인가?" 이유는 이제 입 아프게 이야기 하지 않아도 아실 겁니다....

    예를 하나 들어봅시다.

    드로잉을 제대로 배운 사람이라면 구도와 비례, 양감, 질감 등 지식이 정리되어 있고 체계적인 방법론을 활용해 실행에 옮깁니다. 아래 그림을 보면 왼쪽의 스케치(Sketch) 과정을 통해 사물(Object)을 관찰(분석, analysis)하고, 화폭(Canvas 또는 Document)에 사물을 담기 위해 구도(Layout)를 짜고 구도에 맞게 비례를 계산(calculation)하며, 양감(volume)을 표현하기 위해 덩어리를 구분(division) 짓고, 질감(texture)을 표현합니다. 결과는 오른쪽과 같죠.

    이미지

    하지만.... 제대로 배우지 못하거나 않은 사람이라면 숲이 아닌, 나무를... 전체가 아닌 부분을 먼저 봅니다. 아니 정확히 말하면! 큰 그림을 그리지 못하는 겁니다. 아래 그림을 봅시다. 눈만 정밀묘사(detail description) 했는데 이것만 주어저서는 모호합니다. 여성인지? 남성인지? 청년 일까? 장년일지도?

    이미지

    마찬가지 입니다. 부분만 주어주고... 전체가 그려지지 않았는데 모듈화가 될리 만무합니다. 한마디로 체계가 없고, 효율이 부재하고, 생산성이 극악 하니 협업은 당연 어려운 것이죠. 게다가 수시로 기획과 디자인이 변경되니 기껏 모듈화를 해도 다시 수정이 필요해지죠. 악순환의 연속이라는 것은 이러한 것을 두고 말하는 것일 겁니다.

    그래서 체계(시스템)에 대해 논의하고 협의해서 보다 나은 체계를 갖춰보자 말하면 "문제 없었는데 뭘 바꿔?" 혹은 "좋은 건 알겠는데 그건 당장 적용할 수 없으니 나중에" 또는 "원래 그래왔는데?" 등등의 부정적인 반응이 돌아오곤 합니다.

    즉! 답습(과거의 방식이나 행위 등에 변화를 주지않고 그대로 해오는것)에 갖혀있는 겁니다. 대부분의 사람은 변화를 달가워 하지 않습니다. 위험에서 벗어나 안정을 추구하는 본능 때문일지도 모릅니다. 변화를 위기로 보는 거죠. 두려운 겁니다. 경험해보지 못한 영역에 대해 자신이 없는 겁니다.

    인간 사회를 가만 살펴보면 성향이 진보와 보수로 갈립니다. 물론 중도 성향도 있을 겁니다. 그래서 의견이 불일치하고 다툼이 발생하고 나아가 전쟁이 발발하는 것이겠죠.

    어떻게 하면 좋을지 물어보셨죠?

    저는 상준님 스스로 어떤 성향인지 파악하는 것이 우선해야 한다고 생각합니다. 자신의 성향을 파악해야 진영을 선택할 수 있는 것이니까요. 최대한 자신을 살릴 수 있는 곳을 찾고 선택하기 위한 기준인 것입니다. 변화를 통한 발전을 도모한다면 진보적인 회사에서 꿈을 펼쳐야 할 것이고, 변화보다 안정을 추구한다면 보수적인 회사에서 자신의 자리를 보존해야 할 것입니다.

    정리하면 현재 머무는 자리에서 체계를 갖춰 효율성을 높이고, 생산성을 극대화하는 협업을 기대한다면 먼저 함께 프로젝트를 하는 파트너에게 대화를 해봐야 할 것입니다. 대화가 가능한 상대이고 협의가 가능하다면 행운입니다. :-) 그렇지 않은 상대라면 불행이겠죠. :-(

    아! 한가지 더 이야기 드리면 강압적 이거나, 리소스 없이 툭 던지기만 해서는 서로 불편하고 불만만 쌓일 겁니다. 예를 들어서 체계를 갖추는 것이 목표라면 서로의 영역에 대해 이해하는 시간(대화)을 충분히 가지고, 함께 할 수 있는 요소와 각자 상대를 위해 수행해야 할 요소를 분석한 다음 시행착오를 거쳐야 합니다.

    체계라는 것을 갖추거나 바꾸는 것은 쉽지 않습니다. 시간을 두고 점진적으로 진행해야 할 것입니다. 즉, 인내가 필요한 고된 작업이 될 겁니다. 이를 이겨낼 수 있다면 큰 정진이 있을 것이고, 훗날 팀을 이끄는 리더가 되었을 때 리더쉽은 더욱 빛나게 될 것입니다.

    하지만 현재 머무는 자리가 아닌, 다른 자리를 고려하고 있다면 이직 준비를 하면서, 면접 과정에서 면밀히 검토해야 합니다. 주의할 점은 대표가 아닌 함께 일할 사람들과 대화를 해봐야 합니다. 기회가 주어지지 않는다면 기회를 만들어서 라도 대화를 해봐야 합니다. 목표로 하는 체계가 갖춰지거나, 가능성이 있는 조직에 둥지를 틀고자 한다면 필히 확인과 검증이 필요하니까요. :-)

    다. 반응형

    이어서 반응형 웹 디자인 질문에 답변 드려 봅니다.

    1-1 . 폰트

    폰트 크기는 인간과 기기의 거리에 비례해서 커져야 합니다. 스마트폰과 같은 모바일 스크린 대비 데스크톱 스크린 폰트 크기는 더 커져야 합니다.

    이미지

    왜 멀리 있는 것이 글자 크기가 더 커야 할까요? 책과 모니터를 비교해보면 이해하기 쉽습니다. 일반적으로 책과의 거리보다 모니터의 거리가 더 멀죠. 만약 책과 모니터 글자 크기가 동일하다면? 거리가 더 먼 모니터 글자가 더 작게 보일 겁니다. (아래 그림 참고) 이러한 이유로 멀리 있는 것일 수록 커져야 동일한 크기로 인식할 수 있습니다.

    이미지 이미지

    언급한 이론에 따라 반응형 웹 디자인 시, :root 요소에 폰트 크기를 rem 단위로 설정한다면 아래와 같은 방법으로 설정 할 수 있을 것입니다. :-)

    /* 모바일 해상도 (작은 화면) */
html {
    font-size: 0.8rem;
}

/* 768px 이상 화면 크기에 적용될 미디어쿼리 */
@media only screen and (min-width: 48em) {
    html{
        font-size: 1rem;
    }
}

/* 1440px 이상 화면 크기에 적용될 미디어쿼리 */
@media only screen and (min-width: 90em) {
    html{
        font-size: 1.2rem;
    }
}

    1-2 . 이미지

    [1-19] HTML 임베디드(Embedded) 요소들 강의에서 살펴봤던 <picture> 요소를 사용하면 반응형 대응이 가능합니다. 물론 배경 이미지를 활용하는 방법도 가능합니다.

    <picture>
  <source srcset="media/image/kitten-large.png" type="image/png" media="(min-width: 56.25em)">
  <source srcset="media/image/kitten-medium.png" type="image/png" media="(min-width: 37.5em)">
  <img src="media/image/kitten-small.png" alt="웃는 고양이">
</picture>

    1-3. svg 사용시

    SVG도 Sprite 방법으로 처리할 수 있습니다. 간단하게 GUI 도구를 사용해 만들 수 있는데 Spritebot을 사용하여 개별 SVG 이미지를 드래그(Drag) & 드롭(Drop)하면 자동으로 스프라이트 이미지(SVG 코드)를 만들어 줍니다.

    이미지

    아래는 생성된 SVG 스프라이트 코드입니다.

    
<svg id="svg-sprites">
  <symbol id="icon-1" viewBox="0 0 193 147">
    <g fill="none" fill-rule="evenodd" transform="translate(0 1)">
      <rect width="55" height="53" x="135" y="12" stroke="#306FFD" stroke-width="4" rx="2"/>
      <g stroke="#306FFD" stroke-width="4" transform="translate(0 10)">
        <rect width="55" height="53" x="2" y="2" rx="2"/>
        <rect width="55" height="53" x="2" y="68" rx="2"/>
      </g>
      <g stroke="#306FFD" stroke-width="4" transform="translate(67 10)">
        <rect width="55" height="53" x="2" y="2" rx="2"/>
        <rect width="55" height="53" x="2" y="68" rx="2"/>
      </g>
      <g stroke="#306FFD" stroke-width="4" transform="translate(133 10)">
        <rect width="55" height="53" x="2" y="2" rx="2"/>
        <rect width="55" height="53" x="2" y="68" rx="2"/>
      </g>
      <path stroke="#FF9400" stroke-linecap="square" stroke-width="2" d="M63 0v145" opacity=".6"/>
    </g>
  </symbol>
  <symbol id="icon-2" viewBox="0 0 193 147">
    <g fill="none" fill-rule="evenodd" transform="translate(0 12)">
      ...
    </g>
  </symbol>
  <symbol id="icon-3" viewBox="0 0 193 147">
    <g fill="none" fill-rule="evenodd" transform="translate(0 12)">
      ...
    </g>
  </symbol>
  ...
</svg>

    1-4. CSS 단위 사용 / Fluid 디자인

    답변 1: 컨테이너 좌우 공간이 설정될 것으로 예측 되므로 100vw는 적절하지 않습니다. 유연한 가변 폭을 설정하고자 한다면 좌/우 10vw, 컨테이너 80vw 이렇게 설정하면 가능합니다.

    답변 2: 뷰포트 높이가 스크린 마다 달라질 수 있기 때문에 vh를 사용해야 한다면 미디어쿼리와 함께 사용해야 합니다. 최소 높이에 따른 높이 설정, 최대 높이에 따른 높이 설정 이렇게 필요하겠죠?

    답변 3: 컨테이너 내부 아이템의 경우 vw 사용은 부적절 합니다. 반드시 vw, vh를 사용할 필요는 없습니다. 이런 경우 부모 너비에 상대적인 값(%)을 사용하는 것이 적절합니다.

    답변 4: 패딩의 경우는 rem 보다 em이 적절합니다. 이유는 글자 크기가 커졌을 때 상대적으로 공간이 설정되어야 하기 때문이에요. 만약 rem을 사용한다면 :root 요소에 상대적 이기에 글자 크기에 상대적이지 않게 됩니다.

    .containter {
  width: 100%; /* 답변 1 */
  max-width: 120rem;
  margin: 0 atuo;
  height: 500px; /* 답변 2 */
}

.item {
  width: 33.33%; /* 답변 3 */
  height: 100%;
}

.desc {
  width: 100%;
  height: 50%;
  box-sizing : border-box;
  padding: 20px; /* 답변 4 */
}

    참고

    • (•́ ✖ •̀)
      알 수 없는 사용자
    • 감사합니다 야무님! 이런 방법도 있었다니 덕분에 오늘도 많이 배웁니다. 이제 깔끔하게 flex를 사용할 수 있을 것 같습니다. 알 수 없는 사용자 2018.5.15 09:05
    • 감사합니다! 이렇게 친절하게 알려주셔서 도움이 많이 됐습니다. 달아주신 참고 사이트를 보며 더 많이 공부해야겠네요. 야무님께서 강의시간에 강조하신 더 좋은 개발자가 될 수 있게 노력하겠습니다. 다시한번 감사드립니다! 알 수 없는 사용자 2018.5.18 10:16
    댓글 달기

답변을 하려면 로그인이 필요합니다.

프로그래머스 커뮤니티는 개발자들을 위한 Q&A 서비스입니다. 로그인해야 답변을 작성하실 수 있습니다.

로그인
가입하기
(ಠ_ಠ)
(ಠ‿ಠ)