※ 해당 글은 http://100dayscss.com/ 의 59번째 내용을 설명을 위해 재구성 및 풀이를 적어놓은 포스팅입니다.
※ 궁금한 점 있으시면 댓글 남겨주세요.




이번에는 CSS를 이용한 슬라이딩 효과를 넣어보도록 하겠습니다. 슬라이딩 효과는 다양한 곳에서 다채롭게 사용이 가능한 유용한 기능이므로 잘 참고하시면 좋을 것 같네요.


설명을 읽기 전에,

jQuery에 선택자에 대해 모르시면 잠시 들렀다 오세요.

- jQuery selector

CSS 트랜지션, 트랜스폼에 대해 모르시면 잠시 들렀다 오세요.

- CSS3 Transform

- CSS3 Transition


우선 기본적인 밑바탕 작업을 하도록 합니다.


See the Pen bWJZXL by Munkyu Yang (@moonformeli) on CodePen.


가장 상단의 #wrapper에 대한 기본적인 레이아웃을 만들어주었습니다. 작업은 400px · 400px에서 진행하려고 합니다. 그리고 #wrapper의 자식으로 #cover-img가 있는데, 이 것은 최초에 보여줄 화면을 나타내는 div입니다. position 속성을 주어서 부모인 #wrapper의 위치와 겹쳐지게끔 만들어 주시면 됩니다.


See the Pen gWyqmy by Munkyu Yang (@moonformeli) on CodePen.


#slide-img div는 뒤에 가려져 있다가 마우스가 hover되는 순간에 나타나도록 설정할 영역입니다. 우선은 위치와 크기를 똑같이 설정해줘야 하겠죠.


여기서부터 이해가 중요합니다. 그 다음에는, #slide-img 안에 8개의 div를 그려넣도록 하겠습니다. 그리고 각각의 div는 폭이 50px, 높이가 400px이 되도록 설정을하고, 각각의 영역에 맞게 이미지를 나누어서 갖는 형태가 되도록 해보겠습니다. 즉, 이러한 형태가 되도록 만들어보는 겁니다.


원래의 이미지가 있다면, 우리가 원하는 형태는 위의 그림과 같습니다. 8개로 나누어진 div는 각 영역에 맞게끔 이미지를 잘라서 가지고 있고, 순번에 따라 번갈아가면서 위, 아래로 배치되어 대기 상태로 있게끔 하고 싶습니다. 


See the Pen LyvvEG by Munkyu Yang (@moonformeli) on CodePen.


그런데 뭔가가 좀 이상하죠? 발견하셨나요? 맞습니다. 우리의 머릿속에서는 이미지가 8개의 div에 의해 영역별로 찢어지듯이 영역이 분리되는 것을 원했는데, 막상 실천해보고 결과를 보니 모두 같은 부분만 표시가 되고 있습니다. 이럴 때 어떻게 해야할까요?


만약 우리가 background-image의 시작 위치점을 마음대로 변경할 수 있다면 이야기가 달라질까요? 이렇게 말입니다.




이런식으로 배경의 시작위치를 지정하는 방법은, 다음과 같습니다.


background-position은 첫 번째 인수로 x좌표, 두 번째 인수로 y좌표를 넘겨받습니다. 이렇게하면, 고정된 위치에 있는 div에 어떤식으로 이미지를 보여줄지를 결정할 수 있습니다. 해당 내용을 바탕으로 코드를 업데이트 해보겠습니다.


See the Pen XRwWRP by Munkyu Yang (@moonformeli) on CodePen.


설정된 background-position의 x좌표가 음수(-) 값임에 주의하세요. 우리가 이해하는 프로세스의 진행은 마치 하나의 이미지를 8개의 div가 영역별로 나눠갖는 것처럼 생각되지만, 실제로는 8개의 div가 모두 배경 이미지를 각각 가지고 있습니다. 기억이 나지 않으신다면 .slide에 설정된 내용을 확인하세요. 그렇기때문에, .slide-2부터 .slide-8은 시작위치가 점점 옆으로 옮겨지고 있습니다. 그 말은 다시 말해서 각 div에 설정된 배경이미지 또한 시작점이 옆으로 계속 밀린다는거죠. 결국에는 이미지가 계속해서 옆으로 8개만큼 겹치는 형태입니다. 그러나 겹치지 않는 이유는, 우리가 div의 넓이와 높이를 직접 설정해주어 겹치지 않게 해주었기 때문이겠죠. 이해하시나요?


그래서 예로 들어 .slide-2를 보자면, div의 시작위치는 top:40px 만큼, left:50px만큼입니다. 여기서 background-position을 50px만큼 양의 값으로 설정해버리면 이미지가 오른쪽으로 이동할까요, 아니면 왼쪽으로 이동할까요? 바로 오른쪽으로 이동합니다. 그러면 이미지의 시작지점이 오른쪽으로 밀리게되면 그 밀리는 만큼의 공간에는 어떤 것으로 채워지게 될까요? 직접 실행해보시는 것을 추천드립니다.


우리는 여기서 이미지가 분할되는 현상을 구현하고 싶은 것이기 때문에 background-position:-50px로 음의 값을 설정해주어 배경이미지를 왼쪽으로 이동시킬 필요가 있습니다. 그렇게하면 이미지가 어디서부터 보여질 것인지(-50px 지점부터) 제대로 설정할 수 있는거죠. 


이제부터는 애니메이션을 설정해보겠습니다. 애니메이션은 jQuery를 사용하면 아주 간단하게 해결되는 문제이므로 한 번에 구현해보도록 하겠습니다.


See the Pen wdbvPJ by Munkyu Yang (@moonformeli) on CodePen.


먼저, 주석으로 감춰놓았던 #cover-img를 다시 불러와봅시다. 그러면 어떻게 되나요, 이미지가 두개가 겹쳐버리게 되죠? 이럴 때 사용하는 것이 z-index 기능입니다. z-index는 마치 x,y에 이은 3차 z축이 있다고 가정할 때,  z축의 어디에 이미지를 위치시킬 것인지를 결정짓는 것과 같습니다.


그림과 같이 default의 값은 0입니다. 건물의 층의 높이와도 비유될 수 있겠습니다. #cover-img#slide-img보다 먼저 보여야하니까(위에 놓여야하니까) z-index의 값이 높게 설정이 되어야합니다. z-index의 값을 어떻게, 얼마나 크게 줘야하는지는 개발자의 마음입니다. 그러나, 향후의 어플리케이션의 규모가 확대될 수 있음을 감안해 충분히 쓰지 않는 건물의 층들을 만들어놓으면(z-index) 세입자가 들어왔을 때(클래스 혹은 아이디를 갖는 Html 태그) 들어갈 층이 없어서(z-index) 다시 재 작업을 할 수고를 덜 수는 있습니다.


그리고 추가된 부분을 보자면, jQuery를 이용해 #cover-img에 마우스가 올라갔을 때 각각의 클래스를 부여합니다. 그리고 #cover-img.slide에서는 transition 속성을 부여했습니다. 여기서(부모단에서) 속성을 부여하지 않고 직접 변화를 일으키는 곳에서(자식단에서) transition을 사용하게되면 어떤일이 발생하냐면, 예를 들어 hover의 경우라고 가정한다면, 마우스가 올라갈 때는 애니메이션이 잘 작동할지 몰라도 마우스가 영역 밖으로 나가는 순간 애니메이션이 종료되어 처음 상태 그대로 바로 돌아갑니다. 즉, reverse-animation 효과가 발생하지 않게 되는것입니다. 이 것은 애니메이션을 부여하실 때 꼭 고려해야 할 부분이므로 기억해두시면 좋습니다.


마지막으로 이것은 별 것은 아니지만, jQuery 부분에서 ES6에 새롭게 추가된 arrow function 기능을 사용했습니다. arrow function: () => {} 의 기능을 사용하려면 아직까지는 babel이라는 라이브러리가 필요한데, babel은 ES6를 ES5로 변환해주는 라이브러리입니다.


도움이 되셨다면 공감 한 번씩 눌러주시면 감사하겠습니다.

질문 및 기타 격려의 댓글은 언제든지 환영입니다.^^

※ 해당 포스트는 http://100dayscss.com/의 2번 글의 설명을 위해 작성자가 다시 재구성한 포스팅입니다.

※ 무단 스크랩은 허용하지 않습니다.





햄버거 버튼이라고 불리는 메뉴 버튼을 만들어보겠습니다.

우선 눈에 잘 띄도록 배경부터 지정을 해보겠습니다.


먼저 width, height이 150px인 정사각형을 만들었고, 밋밋하지 않게하기 위해 정사각형에 약간의 box-shadow를 입힌 상태입니다. box-shadow를 모르시겠다면 여기를 클릭하세요.

다음에는 우리가 만든 녹색 상자 안에 버튼처럼 생긴 컴포넌트들을 안에다가 넣어줘 보겠습니다.


See the Pen ybQXLd by Munkyu Yang (@moonformeli) on CodePen.



/* 추가된 부분 */ 을 주목해서 봐주세요. .line 클래스를 가지는 3개의 div를 추가해 width, height, margin를 갖고 있죠? 그리고 딱딱해보이지 않도록 역시 box-shadow와 border-radius를 설정해주었습니다. 


여기서 주목할만한 부분은, #wrapper div의 상태 값이 position:absolute로 변경되었습니다. 이 이유는, CSS에서는 부모의 position 속성이 absolute 혹은 relative면 그 자식의 position이 absolute, relative일 경우 기준점이 부모의 좌측 최 상단에서부터(0,0 지점) 시작됩니다. 지금 보고 계시는 예제는 #wrapper의 시작 위치가 윈도우의 좌측상단으로 정해져있고 따로 움직이지 않았기때문에 여기서는 #wrapper의 position을 설정하지 않아도 괜찮습니다. 그런데 이 것을 움직이게 될 경우에는 자식 태그들을 position으로 움직이려면(특히 absolute의 경우) 정말 먼 길을 달려가야만 하겠죠? 그리고, 부모-자식 관계를 position으로 묶으면 추후에 코드 유지보수에도 많은 도움이 됩니다.


그리고 .line을 감싸는 #line-wrapper를 추가해 cursor에 대한 상태 값을 지정해 주었습니다. 이렇게 하지 않고 .line의 cursor를 변경하면, .line은 3개의 div이기 때문에 그 사이에 존재하는 공백(background)에서는 cursor가 적용되지 않습니다.


See the Pen XRygRK by Munkyu Yang (@moonformeli) on CodePen.


자, 여기서부터 조금씩 복잡해지기 시작합니다.


우선,

jQuery의 선택자에 대해 모르시는 분은 잠깐 보고 오세요.

- 선택자

- toggleClass

CSS의 animation에 대해 모르시는 분은 잠깐 보고 오세요.

- animation - w3schools

- animation - Youtube tutorial video by NetNinja (추천)


제 아무리 CSS가 날고 기어도 CSS는 CSS일 뿐, 액션에 대한 영역은 JS에게 맡겨야 하는 상황이 오게 마련이죠..

추가된 jQuery를 봐주시기 바랍니다. JavaScript를 쓰지 않고 jQuery를 사용한 이유는 jQuery가 DOM제어에 더 특화되어 있고 JavaScript를 사용하는 것보다 쉽게 구현할 수 있습니다. (편하신 분들은 JavaScript를 사용하셔도 괜찮습니다.)


.line들의 부모 div인 #line-wrapper를 클릭하게되면 각각의 아이디에 맞는 div를 찾아 각각 개별적인 클래스 네임을 부여해줍니다. toggleClass를 이용하면 경우의 수에 따라 addClass, removeClass를 매번 해줘야하는 상황을 피할 수 있죠. 저는 toggleClass를 더 선호하는 편입니다. 물론 내부적인 동작은 같을 겁니다.


추가된 CSS 코드에서는, 예를 들어, .line-top 클래스가 적용이 될 경우에 어떤 속성 값을 받을 건지를 설정을 해주었는데요. @keyframes를 사용하면 좀 더 복잡한 애니메이션 효과를 쉽게 구현할 수 있습니다. 직접 transform으로 구현해도 상관없지만 그럴 경우엔 transition까지 같이 사용해줘야하고, 애니메이션이 끝난 후에 상태를 어떻게 놔둘 것인지도 직접 정해줘야해서 까다로워지죠. forwards 속성을 지정하지 않으면 애니메이션이 끝남과 동시에 다시 처음의 상태로 돌아가게 됩니다. 저희는 이 다음의 애니메이션도 부여할 것이기 때문에 이대로 놔두겠습니다.



See the Pen ZKmymp by Munkyu Yang (@moonformeli) on CodePen.


추가된 CSS에서는 위, 아래의 .line이 겹쳐지고 난 후에 rotate 속성을 주어 회전하는 듯한 느낌을 주었습니다. 애니메이션을 저렇게 두 줄 이상으로 작성하게되면 첫 번째로 지정된 애니메이션부터 실행이되고 그 다음 순서로 넘어가게 됩니다. 여기서 두 번째 애니메이션을 순서에 맞게 진행시키고 싶다면, animation-delay 효과를 이용해야합니다. 그렇지 않으면 지정한 애니메이션이 모두 다 동시에 발생하게 되죠.  rotate을 할 때, translateY로 설정해주지 않으면 어떤 일이 일어날까요? .line-* 가 있었던 위치에서 rotate가 실행되게 됩니다. 왜냐하면, 지정한 애니메이션의 0% 지점에서 translateY를 따로 설정하지 않으면 자동적으로 초기 위치로 시작한다고 인식하기 때문입니다.

이제 다시 클릭을 했을 때 돌아가는 코드를 한 번에 보겠습니다.



See the Pen LyXjOM by Munkyu Yang (@moonformeli) on CodePen.


코드를 보시면 추가된 부분이 제법 많습니다. 우선 HTML을 보시면 .init 이라는 클래스를 지정해줬고 CSS에서는 이 클래스에서 animation을 none을 주고 우선순위를 부여합니다. 이렇게하는 이유는, 버튼을 다시 눌렀을 때 애니메이션을 반대로 지정해줘야 하는데 이런 기능을 가진 클래스를 처음부터 갖고 있으면 버튼을 누르기도 전에 reverse 애니메이션이 실행이 되어버립니다. 그런데 여기서 생각해야 할 것은, 애니메이션 실행 ↔ 애니메이션 반대로 실행 이 버튼의 클릭에 따라 한 가지만 실행이 되야하죠. 그리고 이러한 작업이 버튼 클릭에 따라 번갈아가면서 발생해야 합니다. 그 말은, .line-top에 있는 애니메이션은 그 반대의 애니메이션을 갖고 있는 .line-top-reverse와는 동시에 클래스로 존재해서는 안된다는 뜻이 됩니다.


그렇다면 버튼을 눌렀을 때 애니메이션이 실행되게 하기 위해선 버튼을 누른 후에 .line-top을 부여해줘야하고, 그 말은 다시, .line-top-reverse는 코드 실행 시작시에 처음으로 갖고 있는 클래스라는 뜻입니다. 그런데 윗 단락에서 설명한 것을 다시 말하자면, .line-top-reverse는 나름의 애니메이션을 갖고 있기 때문에, 코드 실행이 될 때 자동으로 실행이 되겠죠. 이 것을 어떻게 막냐,이 문제에 직면하게 됩니다. CSS에서는 조건문이라는 것이 없기 때문에 제어를 할 수가 없죠. 그래서 .init을 만들어 강제적으로 모든 애니메이션을 없애버린 것입니다. 그리고 jQuery 부분에서는 .line 클래스를 찾아 .init 클래스를 지워버리죠. 제가 만든 샘플 코드에서는 클릭 이벤트가 실행될 때마다 .init을 찾아 삭제하겠지만, 다른 방법들도 많으니 고민해보시기 바랍니다.


반대로 정의하고 싶은 애니메이션은 기존에 지정한 애니메이션을 반대로 작성해주기만 하면 금방이죠. 그런데 여기서 @keyframes line-mid-invisible에 주목해보세요. 의미없이 보이는 애니메이션이 들어가 있습니다. 시작과 끝에서 모두 scale로 같은 값을 지정한다는 것은 무슨 의미일까요? 저 부분은 그 자체로의 의미보다는 .mid-reverse 설정과 연결지어서 봐야합니다. 아무렇게나 만든 것 같은 line-mid-invisible 애니메이션이 먼저 지정이 되어 있고 그 다음에 본 애니메이션이 연결이 되어있죠.  이 것은 'animation delay'와 어느정도 연관이 있습니다.




최초의 클릭 후 애니메이션이 실행이 되면 클래스명의 네이밍은 어떻게 될까요. .line-mid이 생기고 .mid-reverse.init은 없어지겠죠.  그리고 다시 클릭하면 .mid-reverse 클래스명이 생기면서 reverse 애니메이션을 실행하게 될텐데, 우리가 원하는 #line-mid의 경우 rotate된 나머지 두 라인이 다시 원래대로 돌아올 때까지 기다렸다가 다음 애니메이션부터 같이 실행되길 원합니다. 그런 마음에서 animation-delay를 설정해 줬는데, 예상과는 다르게 애니메이션이 실행되기 전까지의 시간은 우리가 초기 속성값을 정해놓은 그 상태 그대로 기다리게 됩니다. 즉, 애니메이션 대기 큐에는 올라갔지만 기다리는 동안 이렇다할 상태변화가 없기 때문에 원래 갖고 있던 값 그대로 갖고 있는채로 기다리게 되는 것입니다. 


우리는 mid가 보이지 않았다가 서서히 나타나는 효과를 원했으므로, 애니메이션을 기다리는 동안(animation-delay)에도 계속 보이지 않는 상태로 유지시켜주면 더 좋겠죠. 그래서 scale을 0으로 만들고 기다리는 작업을 하고 있는 것입니다. 직접 한 번 실행해보면서 이해를 해보도록 하세요.


이로써 햄버거 메뉴 버튼 만들기는 끝났습니다. 기초적인 기능이지만 세련된 느낌을 줄 수 있는 좋은 효과이기때문에, 한 번 익혀놓으시면 다른 스타일로도 얼마든지 응용이 가능한 매우 유용한 기술입니다.


설명을 위해 글이 다소 길어졌지만 끝까지 읽어주셔서 감사합니다. 다음에는 다른 효과에 대해 알아보도록 하겠습니다.


React.js를 사용해 개발을 하다보면 사실상 눈에 띌 정도로 '좋다'고 느끼는 것은 그다지 많지 않습니다. React에익숙하지 않은 개발자라면 이러한 현상이 더욱 드러날 것이겠지요. 그런데도 우리가 React를 사용하는 이유는 바로 이런것이 아닐까 싶네요.


React의 공식 홈페이지의 내용을 조금만 인용해 등장배경부터 알아 보자면 다음과 같습니다.

  • By unifying your markup with its corresponding view logic, React can actually make views easier to extend and maintain.
  • 여러분이 만들어놓은 마크업(markup)과 그에 상응하는 뷰 로직을 하나로 만들 때, React는 실제로 뷰를 더욱 확장성 있고 관리하기 쉽도록 만들어줍니다.

출처 - https://facebook.github.io/react/blog/2013/06/05/why-react.html


실제로 JavaScript나 jQuery만을 이용해 어플리케이션을 개발했을 때를 생각을 해보자면, 하나의 HTML파일에 여러가지 모듈화된 js파일들을 불러왔었을 겁니다. 어플리케이션의 크기가 증가하면서 코드의 양도 자연스레 비례적으로 증가하였고 단편적으로 HTML의 양이 대폭적으로 늘어났다고 가정을 해보면, 우선 분리되어있지 않은 코드들이 가독성을 제일 먼저 떨어트릴 것입니다. 그리고 이러한 DOM들을 제어 · 관리하는데에 사용하는 jQuery의 양도 매우 많아지겠죠. 즉, 한마디로 말해 '관리의 효율' 문제라는 겁니다. 아무리 버그가 없고 이상이 없는 사이트인데 오늘만 산다는 마음가짐으로 코드 관리를 매우 비효율적으로 해놓는다면, 추후의 관리의 차원에서 너무 힘들어지겠죠. 나 혼자만 개발하는 것이 아니라 협업의 관계에 속해있다면 관리는 반드시 고려해야할 숙제 중 하나입니다.

다행스럽게도, React는 이러한 관리문제를 컴포넌트의 모듈화로 제법 해결해놓았습니다.  아래의 코드는 아주 간단한 jQuery 예제로 jQuery가 어떻게 DOM에게 간섭하는지를 보여줍니다. jQuery의 시작은 항상 $으로 시작하죠, 이 기호를 이용해 모든 DOM에 접근할 수 있습니다. (솔직히 제 개인적으로도 jQuery만큼 DOM관리하는데에 편한것도 없는 것 같습니다.)

See the Pen PmBLLZ by Munkyu Yang (@moonformeli) on CodePen.


아래에는 같은 내용의 코드를 React.js를 통해서 구현해본 것입니다.

See the Pen WjKmqj by Munkyu Yang (@moonformeli) on CodePen.

언뜻 보면 React.js의 코드가 더 길고 복잡해 보입니다. HTML 코드는 jQuery의 코드를 기준으로 8줄이네요. 그리고 React는 코드를 컴포넌트라는 하나의 클래스를 만들어 모듈화를 통해 관리합니다. 즉, '뚜렷한 의미를 가지는 클래스들의 모듈화' 를 이용하는 것이죠. 이는 상당히 중요한 개념입니다. 제 개인적으로는 React가 jQuery보다 앞서있다고 생각되는 점 중에 하나입니다.


만약에, 어플리케이션이 방대해져서 HTML만 1,000줄이 필요하다고 가정을 해보면, 무수히 많은 클래스들과 아이디가 부여가 될 것이고 그에 따른 CSS제어, 액션제어들이 필요하겠죠. 이 모든 것들을 $.ready()에서 처리한다고 생각해본다면 얼마나 읽기가 힘들지는 눈에 선하죠? jQuery에서도 js파일을 나눠서 관리할 수 있습니다만.. 특정한 의미가 없이 그저 코드의 양을 줄이고자 나누는 작업은 오히려 가독성을 낮출 수 있습니다. 하나의 파일에서 시간을 조금만 들여서 보면 될 것을 파일의 분기때문에 이 파일 저 파일 번갈아가면서 봐야할 수도 있는거죠.


React는 1,000줄의 HTML에서 이런식으로 흐름을 분기합니다. 


이런식의 의미있는 컴포넌트만 불러와 하나의 HTML을 만드는 것은 상당히 편리하고 강력합니다. 또 <로그인 />에서는 로그인에 필요한 액션 제어, <회원가입/> 에서는 그에 맞는 액션제어(Form 전송 등)를 알맞게 할 수 있고, 나중을 위한 유지보수의 첫 단추도 잘 넣게 되는 것이죠.



그러나, 한 가지 염두해두고 있어야 할 점은, React가 낫다, jQuery가 낫다 아니면 혹은 다른 프레임워크들이 낫다고 생각해 한 가지만을 고집하는 것은 어리석은 생각입니다. 공식 홈페이지에서도 나와있듯이, React는 MVC 패턴을 구현하기 위해 제작된 프레임워크가 아닙니다. 그저 확장성과 관리효율성 차원에서 고려되어져 만들어진 우수한 성능의 자바스크립트 라이브러리일 뿐입니다. 기본적인 베이스를 잡고 있는 프레임워크나 라이브러리는 존재하되, 필요한 기능을 더 편리하고 강력하게 구현하는 기능을 제공해주는 것이 있다면, 현재 사용중인 개발언어의 기능과 비교해보고 더 나은 것을 선택하는 것이 바람직하다고 할 수 있습니다.


+ Recent posts