CSS책 출판제의를 받고 작성했던 원고들 공유... (지금은 부러졌어요)
CSS로 출판제안을 받아서 한번 작성을 했었지만 여러사정으로 출판 프로젝트가 부러지면서 완성되지 못한 원고(가 아니라 메모)를 보면서 이 메모들은 개인 메모로만 남을 것 같아 아까운 마음에 완성되지 않은채로라도 일단 공개를 하려고 합니다.
조금씩 완성도를 올려서 블로그에 올릴까 했지만 이미 블로그에 올라간 내용과 중복된 내용들도 많고 출판 프로젝트가 부러지면서 살짝 동력을 잃은 관계로 손이 잘 안가더라구요.
그래도 CSS를 학습을 하고자 하는 사람들에게는 대략적인 학습 방향성이나 구조 그리고 인사이트 까지는 얻을 수 있지 않을까 하는 생각에 미완성된 메모이나 도움이 되지 않을까 싶어서 공유해봅니다.
주의: 이 글은 차마 완성이 되지 못한 비운의 원고입니다. 완성도가 박살나있는 글이니 정독보다는 유투브 2배속 마냥 휙휙 넘겨가며 읽어주세요. 😅😆😜🤫
머릿말
웹은 태초에 문서를 공유하기 위한 용도로 시작했습니다. 그러다 보니 문서를 조금 더 잘 보여주기 위해서 디자인적인 요소들이 가미되었고, 어느순간 HTML에는 디자인과 컨텐츠가 뒤섞여 아주 복합한 형태가 되어 버렸습니다. CSS는 문서에서 컨텐츠와 서식을 분리하고자 하는 시도에서 탄생한 언어입니다.
문서를 꾸미기 위한 목적에서 만들어진 CSS이지만 웹은 문서에만 그치지 않고 사용자와의 인터렉션을 통해 웹 서비스로 웹앱으로 발전을 하게 되었습니다. 그러다 보니 CSS의 역할이 필요 이상으로 커지게 되었고 문서를 만드는 방식을 온갖 방법으로 응용하여 화면을 만드는 자기들만의 방법들이 난무하기 시작했습니다.
당시 표준은 아니지만 표준이었던 인터넷 익스플로러의 6, 7, 8등 버전마다 다른 CSS 동작방식들로 하여금 웹 표준이라는 것들이 만들어지면서 CSS는 겨우 발전을 시작 할 수 있었습니다.
CSS와 웹이 과도하게 성장을 하면서 겪는 성장통을 겪으면서 필요한 스펙들을 만들어 보았지만, 웹은 이렇게 한번 만들어진 스펙을 버릴 수 없기 때문에 어떤 부분은 좋고 어떤 부분은 부족하고 어떤 부분은 해결된 채로 어떤 부분은 아직도 계속 방법을 찾아내는 중으로 계속 변하고 있습니다.
웹은 점점 거대 산업으로 발전을 하게 되면서 HTML, CSS 등을 배우려고 하는 사람들도 굉장히 많아졌습니다. 그러다 보니 학습컨텐츠가 시대를 따라잡지 못한 채 계속 확대 재생산되면서 이제는 잘 쓰이지 않는 예전 방식를 공부한다거나 예전에는 중요했지만 지금은 중요해지지 않은 부분들이 여전히 중요한 것 처럼 설명되고있어 현재와는 맞지 않는 괴리감이 느껴집니다.
CSS가 어려운 점 하나로 알려진 "같은 화면을 만들 수 있는 수많은 방법들이 존재한다"는 문제점은 입문자나 초보자들에게는 어떤 것이 더 나은 방법인지를 모르게 합니다. 그냥 화면이 나오는 것에 만족을 하고 예전의 방식을 그대로 학습하게 됩니다.
다행히(?) CSS의 스펙이 변화하는 속도는 점점 줄어 들고 있지만, 같은 스펙을 가지고도 사람들이 같은 화면을 어떻게 하면 더 효율적으로 만들 수 있는지 어떤 식으로 CSS를 관리를 하면 좋을지 방법론등에 대해서는 예전보다 더 많이 발전을 하고 있는 상태입니다.
그래서 저는 여러분이 기본적으로 학습한 CSS의 스펙을 실제로 사용하는 방법들 가운데 2022년 지금 시대에 맞는 연구가 된 트렌드한 방법을 알려드리고 싶었습니다. 어떤 것들은 제가 연구한 방법으로 다소 주관적일수도 있는 부분들은 근거를 들어 왜 좋은지도 설명을 함께 드릴 예정입니다.
아울러 왜 이렇게 하는게 더 좋은 방법이 되었는지 간단한 역사와 내용을 짚어 볼 생각입니다. 흐름을 이해하고자 알려드리는 이야기이기 때문에 지나간 방법에 대한 자세한 기술적인 이야기는 일부러 하지 않을 생각입니다.
15년 넘게 발전한 CSS의 내용 중에서 지금 당장 필요한 것들만 최대한 추려서 제가 생각하는 지금의 Best Practice를 공유하려 합니다.
이 책이 현대 CSS의 체계를 빨리 이해하는데 도움이 되기를 바랍니다.
목차
-
CSS가 어려워진 이유
- CSS가 어려워지는 이유
- 나만의 Best Practice가 필요하다!
-
CSS의 역사를 배워보자.
-
CSS Selector 이야기
- Specify War!
- Selector가 복잡해진 이유
- Selector가 단순해진 이유
- 이름짓기는 어려워! CSS 방법론
- 🔥 시멘틱한 단순한 이름: BEM
- 컨벤션이 필요한 이유?
- Block__Element--Modifiter
- 단순함의 미학
- 🔥 직관적인 비주얼한 이름: Atomic CSS
- mt10은 좋은 CSS일까?
- 시멘틱에 밀려나다...
- 왜 다시 Atomic인가?
-
CSS Reset
- 옛날 방식은 밀어버리자!
- * { margin:0; padding: 0;}
- 🔥 box-sizing: border-box
- img { display: block; max-width: 100%; }
- * { font: inherit; color: inherit }
- * { flex-shrink: 0}
- button { border: 0; }
- table { border-collapse:collapse; border-spacing:0;}
-
CSS Property
- CSS 스펙 학습이 어려운 이유1 - 사전식 나열과 중요도 없음
- CSS 스펙 학습이 어려운 이유2 - 레이아웃의 과도기적 발전
- 실제로 관련이 있는 것 끼리 묶어서 생각하자 https://9elements.com/css-rule-order/
- 일단은 레이아웃과 레이아웃이 아닌것으로 분리하는 것이 시작!
- CSS Property 순서 컨벤션
- 잘 안쓰이는 것은 나중에 공부하자.
-
레이아웃이 아닌것
-
글자
- 🔥 font: Font에서 쓰이는 용어와 시각화
- letter-spacing
- line-height
- text-align
-
색상
- color
- background-color
- border-color
- svg와 currentColor
-
테두리
- border
- border로 삼각형 그리기
- border-radious
- border-radious로 원 그리기
- CSS Battle
-
그림자
- box-shadow
- box-shadow로 만드는 디자인
- text-shadow
-
배경
- background
- cover vs contain
- object-fit 과
<img>
tag를 써야 할 때 - background: fixed
-
투명도
- opacity
-
Effect(투명도, 필터, ....)
- transform (translate는 뒤에 레이아웃에서 다시 한번 자세히 다룰예정)
- filter
- backdrop-filter
-
-
레이아웃 I
-
들어가기 전에...
- 🔥 레이아웃이 어려운 이유
- 🔥 margin을 쓰지 말자! [부록] margin을 써야 할때...
-
🔥 Flexbox
- 시각적으로 스펙을 이해하자. (with figma AutoLayout)
- row vs column / hbox vs vbox
- align-items / hbox(top) vs vbox(left) / align-items는 stretch를 가지고 있다!
- justify-content / hbox(right) vs vbox(bottom) / justify-content는 space-between을 가지고 있다!
- gap
- padding
-
🔥 Flexbox 실전!
- Flexbox로 생각하기. 레이아웃 분할 자르기!
- 연습 과제
-
Grid
- Grid와 Flex의 차이점
- Grid가 더 최신 스펙인데 Flex대신 Grid로만 레이아웃이 가능할까? (flex는 대체 불가!)
- 언제 Grid를 써야 하는가?
-
-
레이아웃 (Overlay)
-
Position
- absolute
- relative
- fixed
- sticky
-
Layer
-
Z-index
-
고급 Position, 퍼센트, vh...
- margin, top, left, transform 뭐가 다를까?
- %와 절대값을 잘 섞어 쓴다. calc까지!
-
-
Overflow (scroll, ellipsis, line-clamp, ...)
-
자르는 것 (clip)
-
text와 함께
- 1줄 말줄임 만들기...
- 여러줄 말줄임 만들기... (주의 새로운 스펙이 나올 예정입니다!)
-
이미지와 함께
- 여러줄 말줄임 만들기... (주의 새로운 스펙이 나올 예정입니다!)
-
flex와 함께
- overflow:auto인 경우에는 flex에서 무한정 늘어나게 된다. 주의!
-
-
스크롤
- 스크롤 만들기(x, y, auto, always)
- 스크롤 바의 문제 해결 방법 (스크립트)
- 스크롤 바 스타일링과 한계점
-
스크롤 스냅
- CSS로만 캐로셀 만들기
- 응용하기
-
Overflow와 Overlay를 함께 써야할때 (스크립트)
- Dropdown, Popover
-
-
Interaction (cursor, :hover, :active, ...)
-
Pseudo class (hover, active)
- Mobile 주의! 뒤에 설명
-
Pseudo class (hover, active)
-
-
Responsive (media query, max-width, ...)
- media query로 반응형 레이아웃 만들기
-
Animation (transform, animation, ...)
- absolute top, left,
-
CSS Selector Advanced
- +, ~, > 이 Selector들은 언제 써야 하나?
-
Mobile CSS
- hover를 주의해서 쓰자!
- font-adjust-size
- touch-call-action
- user-select:none
-
잘 안쓰이지만 알아두면 좋은 CSS
- 글자
- https://medium.com/@theAngularGuy/7-amazing-css-properties-you-may-not-know-yet-4f7b67f80644
- vertical-align
- aspect-ratio
1장. CSS가 어려워진 이유
CSS가 어려워지는 이유
웹은 문서를 공유하기 위해서 만들어졌습니다. 그리고 그 문서를 조금 더 잘 보여주기 위해서 서식이 만들어졌습니다. 이러한 서식과 데이터가 복잡하게 공존하게 되면서 서식과 컨텐츠를 분리해야겠다는 의도에서 CSS가 탄생하게 되었습니다.
초기에는 문서와 서식을 잘 분리해서 보다 적은양의 코드를 통해서 같은 컨텐츠를 다양한 서식을 적용할 수 있도록 발전을 하였습니다. 그러나 웹 산업이 급격히 발전을 하게 되면서 웹은 단순히 문서의 역할을 너머 서비스와 어플리케이션의 형태로 발전을 하게 되었습니다.
문서에서 어플리케이션까지 웹 서비스의 범위가 확장이 됨에 따라 CSS에도 여러가지 요구사항들이 생겨났고 그에 맞는 여러 가지 좋은 스펙들이 발명이 되었습니다. 또한 그 과정에서 여러가지 시행착오를 겪기도 했었습니다. 특히 문서을 만들기 위해서 시작된 설계를 바탕으로 이후 어플리케이션을 위한 추가 방안을 마련하는 과정이 더욱 그랬습니다. 이렇게 이미 한번 만들어진 스펙은 되돌릴수가 없기에 좋았던 부분과 그렇지 못한 부분들을 우리는 함께 사용하고 있습니다.
또한 당시에는 시대에 맞게 의도대로 설계를 했지만 웹 산업이 급격하게 발전을 하면서 생겨난 새로운 요구사항을 이미 만들어진 스펙이나 설계가 못 따라오는 시기가 존재했고, 그 안에서 어떻게든 방법을 찾다 보니 의도와는 다른 방식으로 CSS 스펙을 차용해서 화면을 만들게 되었습니다.
또한 이렇게 우회해서 해결하는 방식들이 Tip에서 출발해 하나의 정석(?) 이 되어 공부를 해야하는 것이 되고 이런것들이 웹 문서로도 커리큘럼으로도 재생산이 되게 됩니다.
그리고 안타깝게도 최초 문서를 위해 설계된 방법들은 여전히 어플리케이션을 제작하기 위한 개념과는 충돌하는 부분이 존재를 하고 있습니다. 이러한 부분들은 현대 산업에서 덩치가 큰 CSS를 이용한 프로젝트를 안정적으로 유지하게 어렵게 만드는 원인이 되고 있습니다. 그리고 이를 개선하기 위해서 CSS 스펙으로 해결하지 못하는 부분들은 여러가지 도구들을 발명해서 또 해결을 하고자 하게 됩니다. 그러면 또 우리는 이 새로운 도구를 배워야 하죠.
이후 이러한 문제를 해결할 수 있는 새로운 스펙 출시가 되거나 더 나은 방법이 발견이 되면 기존에 찾아냈던 방식들은 전부 좋지 못한 방법이 됩니다. 그렇지만 예전에 이미 생산된 커리큘럼이나 작성된 내용들은 남아있기에 뭐가 더 나은 방식인지 모른 채 학습을 하게 되죠.
그렇다고 무조건 최신을 따르자니 새로운 스펙이 모든 브라우저에 보편적으로 적용이 되기까지에는 또 시간이 필요합니다. 그러다 보니 특정 브라우저에는 제대로 보이지 않을수도 있기에 무조건 새로운 스펙을 바로 도입할수도 없죠. 그러니 기존의 방식 역시 알고는 있어야 하는 상황이 발생하게 됩니다.
당장의 최신 기술을 쓸 수 없으니 그렇다고 안정성만 추구해 계속 현재의 방법만 고수를 한다면 변화하는 웹 생태계에 따라가지 못한채 낡은 코드와 낡은 패러다임으로 인해 우리의 코드는 레거시가 되게 됩니다. 언제나 더 나은 방법을 찾아내고 개선을 하고자 하는 것이 개발자들이니까요.
그러기에 언제 새로운 스펙으로 갈아탈지 어떤 기능이 나왔는지 어떠한 관점과 기술들이 나왔는지 우리는 꾸준히 관찰을 하고 학습을 하여 적당한 시기에 더 나은 방법으로 꾸준히 업데이트를 해나가야만 합니다.
종합하자면, 문서에서 어플리케이션으로 넘어오는 과도기적 시행착오로 인해 CSS 자체가 규모가 큰 서비스를 만들기에 이미 태생적인 문제가 있다는 것이 첫번째 어려움이며, 이를 극복하기 위해 새롭게 만들어지는 스펙들과 도구들이 범람을 하는데 그 중에서 무엇이 좋은지 알기가 어렵고 무조건적으로 최신기술을 선택할 수는 없기에 적절한 기준점을 가지고 적당히 좋은 도구를 적당히 좋은 시기에 꾸준히 업데이트를 해야하는 것이 두번째 어려움입니다.
나만의 Best Practice를 꾸준히 만들어보자!
웹 산업의 분야는 다양하기에 하나의 기술과 패러다임이 정답이 아닙니다. CSS 기술은 항상 시대를 반영해서 발전을 해왔고 내가 홈페이지를 만들고 있는지 솔루션을 만들고 있는지 백엔드 입장인지 프론트엔드 입장인지에 따라서 좋은 방법과 나쁜 방법이 다 달라지게 됩니다.
CSS 역시 어디에서든 통하는 은빛총알 같은 것은 없습니다. CSS에는 상황에 맞는 여러가지 도구들이 존재하고 있으며 어떠한 도구가 어디에 잘 어울리지는 지 역시 스스로 알아야 하겠지요.
제가 항상 CSS를 알려드릴때 하는 말이 있습니다. CSS를 잘 하기 위해서는 본인만의 Best Practice를 가져야 된다고 말입니다. CSS는 JS와는 달리 깊은 이해도 어느 정도 필요하겠지만 그것보다는 숙달이 되어 있는 것이 훨씬 더 중요합니다.
왜냐하면 디자인을 내가 원하는 대로 만들 수 있고 요구하는 디자인을 정확하고 신속하게 만들어줘야 CSS를 잘 한다는 장점을 챙길 수 있기 때문에 CSS는 깊은 이해보다는 상대적으로 연습이 더 중요합니다. 그렇기에 내가 거대한 CSS와 디자인을 잘 다루기 위해서는 반복 숙달이 필요하고 그러다 보면 자기만의 루틴이 만들어지게 됩니다.
이 루틴이라는 것은 좋고 효율적인 걸 가지고 있어야겠죠. CSS와 브라우저는 계속 성장을 하고 있기에 처음에 배웠던 그 방식이 지금은 최선이 아닐수도 있습니다. 그렇기에 내 도구들을 항상 점검하고 새로운 스펙들을 주시하고 있어야 합니다. 아쉽게도 무조건 최신을 택할 수도 없는 것이, 브라우저는 여러 종류가 있고 데스크탑과 모바일 그리고 아직 업데이트를 하지 않은 유저들도 있기 때문에 적절한 밸런스를 잡아야 합니다.
또한 그간 CSS 신문물의 척화비 역할을 하던 IE11의 퇴출이 확정이 되었고, CSS에도 JS의 영역이 가세하면서 CSS의 도구나 패러다임이 업그레이드가 될 예정입니다. 최신 스펙뿐만이 아니라 CSS를 개발하기 위한 좋은 도구들을 꾸준히 바꿔가는 것 역시 우리가 낡은 개발자가 되지 않는 길이기도 합니다.
그러기 위해서 먼저 CSS 역사를 배워보자.
출처: https://github.com/ManzDev/frontend-evolution어느 분야든 역사를 공부한다는 것은 지금 이것이 왜 이렇게 만들어져있으며 앞으로는 어떻게 될지 방향성을 예측해 볼 수 있는 좋은 공부가 됩니다. 특히 CSS의 경우 웹 문서로 출발해 홈페이지, 게시판 그리고 현재 웹 어플리케이션으로 넘어가는 과정에서 당시에는 CSS 스펙이 지원하지 않아서 만들어졌던 방법들이나 패러다임의 전환등이 많았기에 CSS를 지금 처음 배우는 사람들 입장에서는 예전과는 다른 환경에 쓰여진 말들이 어느 것이 맞는건지 잘 모르게 되는 경우가 생기게 됩니다.
CSS뿐만 아니라 모든 개발의 내용은 필요에 의해 생기고 필요는 그때 당시의 상황을 반영하게 됩니다. CSS의 역사를 이해함으로써 앞으로 CSS 관련 글들을 읽었을때 어떠한 갈래와 패러다임에 해당하는 내용인지 알 수 있는 넓은 시야가 생기는데 도움이 되었으면 좋겠습니다. 또한 앞으로 새로운 스펙이나 도구 기술등이 나왔을 때에도 어떠한 맥락에서 이게 만들어졌는지 이해할 수 있는 단초가 되어 줄거라 생각합니다.
2장. CSS의 역사
CSS 역사로 알아보는 CSS가 어려워진 이유. 여기 내용을 쓰려고 합니다.
3장. CSS Selector와 방법론
CSS 역사로 알아보는 CSS가 어려워진 이유. 여기 내용을 쓰려고 합니다.
(역사에서 이미 언급 했으니 그중에서 Selector와 방법론을 중심으로 간단한 리캡과 함께 세부적인 내용을 설명하고 Selector의 종류나 내용에 대한 이론을 추가하는 방향으로 다시 작성해보겠습니다.)
https://wattenberger.com/blog/css-cascade
보통 CSS의 간단한 역사와 소개 그리고 문법을 배우고 나서 맨 처음에 배우는 것이 바로 이 Selector입니다.
CSS의 Selector에 대해서 개념적으로 한번 생각을 해보는 시간을 가져볼게요.
워드 프로세서를 상상해봅시다. 내가 원하는 어떤 영역을 드래그 해서 영역을 만들고 그 곳의 색상을 바꾼다거나 크기를 키우는 작업을 할 수 있습니다. 이때 이때 마우스를 누르고 드래그해서 선택 영역을 만드는 이 행위를 컴퓨터에게 시키려면 어떻게 해야 될까요.
컴퓨터에게 저 위치가 어딘지를 정확하게 알 수 있도록 지정을 해줘야 되는 작업이 필요합니다.
그래야만 컴퓨터한테 명령으로 해당 요구 사항을 실행시킬 수 있을 테니까요.
HTML에서 태그를 다는 행위가 곧 <div>드래그해서 영역을 만들어내는 행위</div>
이고 여기에 이름을 붙여둬서 컴퓨터가 찾아 갈 수 있게 해줄 수 있습니다.
어디를 찾아가야 할지 알려주는 주소같은 역할을 바로 Selector라고 합니다.
h1 { color: red}
.class { color: red}
a[href] { color: red}
div > div { color: red}
div + div { color: red}
Selector가 복잡해진 이유
초창기에는 4가지의 단순한 Selector만이 존재했습니다. 하지만 점점 Selector는 복잡해졌죠. 왜 그럴까요?
웹 문서가 근본이었던 시절 문서와 디자인이 한데 섞이는게 싫어서 분리를 했다고 앞서 설명을 드렸습니다.
문서란 세부 내용이 잘 변하지 않습니다. 하지만 디자인은 계속해서 변화해 갈 수 있겠죠. 그래서 하나의 컨텐츠에 여러 가지 서식을 적용할 수 있도록 하는 방법이 중요한 아젠다였습니다.
그 당시 그러한 취지의 게시판이나 쇼핑몰 솔루션, 블로그등의 서비스가 유행했다는 사실을 떠올려보세요.
그러다 보니까 HTML을 건들지 않고 CSS만으로 디자인을 잘 하는 법이 중요했습니다.
HTML을 변경할 수가 없다보니 내가 원하는 어떤 엘리먼트만 지정하기 위해서는 정교한 Selector가 필요하게 되었습니다. 그렇지 않으면 의도하지 않은 영역이 선택이 되어 버려 원치 않는 결과가 나오게 됩니다.
#navbar > ul > li.foo a[href] { color: red }
더욱이 초창기에는 4개 밖에 없는 Selector를 가지고는 영역을 잘 못 지정하는 경우가 많다보니 정교한 Selector의 요구사항이 늘어나게 되었습니다.
그래서 이 당시에는 Selector를 잘 쓰는 것이 중요했기 때문에 많은 방법의 Selector 사용법을 익히는 것이 중요했습니다.
Selector가 단순해진 이유
지금은 어떨까요? 아시다시피 지금은 HTML과 CSS를 프론트엔드에서 작업을 합니다. Ajax가 생겨나면서 HTML을 만들던 백엔드는 이제 데이터만 전달을 하게 되고 HTML의 편집권을 프론트엔드에게 넘겨주게 되었습니다.
그리고 이제는 더 이상 하나의 동일한 컨텐츠에서 여러가지의 스타일을 만들 필요가 적어졌습니다. 예전에는 커스텀을 할 수 있는 것들이 주요한 가치였다면 지금은 하나의 세련된 디자인이 가치를 만드는 세상이 되었습니다.
아직도 네이버 블로그나 티스토리와 같이 테마들을 제공하는 서비스가 있지만 현대에 와서는 미디엄, 브런치, velog등과 같이 아이덴티티가 있는 하나의 디자인을 제공하는 것이 추세가 되었습니다.
누구가 아는 인스타그램을 보세요! 디자인이 곧 아이덴티티입니다.
그러다보니 더더욱 HTML의 편집이 자유로워지고 이는 곧 CSS의 셀렉터를 복잡하게 만드는 것 보다 HTML에 class를 추가하는 편이 더 관리하기가 쉽다는 것을 알게 됩니다.
<section>
<div>
<a href="">foo</a> <!-- 여기에 서식을 적용하고 싶은데 -->
</div>
<div>
<div>
<a href="">bar</a> <!-- 여기는 원하지 않았다. section > div > a 와 같은 식으로 썼어야 했다! -->
</div>
</div>
</section>
<style>
seciton div a { color: red } /* 이렇게 할 경우 의도치 않은 a에 잘못된 서식이 적용할 잠재적 위험이 항상 가지고 있게 된다! */
</style>
vs
<section>
<div>
<a href="" class="link">foo</a> <!-- 그냥 HTML에 class를 추가하는게, -->
</div>
<div>
<div>
<a href="">bar</a> <!-- 여기는 link가 없으므로 적용이 안된다. -->
</div>
</div>
</section>
<style>
.link { color: red } /* 이편이 더 간단하다.*/
</style>
그래서 더이상 복잡한 Selector를 쓰기보다는 class의 이름을 잘 지어서 붙이는 식으로 발전을 하게 됩니다.
이름짓기는 어려워! CSS 방법론
HTML의 편집권을 가져오면서 이제 복잡한 Selector의 잠재적인 위험에서는 벗어났지만, 웹이 거대해지면서 이름 붙여야 할 것들이 엄청나게 많아지다보니 이 이름을 짓는 것에서 엄청난 어려움에 봉착하게 됩니다. 가뜩이나 CSS의 경우 global scope를 가지고 있는 태생적인 한계로 인해서 모든 이름들은 겹치지 않아야 합니다. 또한 HTML의 계층과 CSS의 계층이 다르므로 이해를 할 수 있는 계층구조를 잘 표현 할 수 있어야 했고 특히 협업을 할때 서로의 이름을 짓는 방법이 달라서 여간 고생이 아니었습니다.
ITCSS, SMACSS, OOCSS, BEM, CUBE CSS 등 한번쯤 들어봤던 이 CSS 방법론이라는 것은 결국 어떻게 하면 이 이름을 잘 지을 수 있는가에 대한 노력들이었습니다.
여러가지 방법론이 논의되었으나 현재 살아남은 승자는 BEM와 Atomic CSS(Utiliy-First) 이므로 이 2가지에 대해서만 살펴보겠습니다.
(집필하고 있는 이후에 뭔가 새로운 게 또 나올지도 모르겠습니다. 여기에 없는 이름이라면 배우세요! 뭐든 최신의 것을 배우세요!)
🔥 구조를 포함하는 단순한 명명법: BEM
http://getbem.com/introduction/
(BEM에 대해서는 자세히 다시 쓰겠습니다.)
🔥 직관적인 비주얼한 이름: Atomic CSS(Utiliy-First)
.bold { font-weight: bold }
.text-center { text-align: center }
.pull-left { float: left }
.clearfix { clear: both }
.none { display:none }
.no-text { text-indent: -9999px }
.hbox { display: flex; align-items: center; }
.relative { position: relative }
...
이른바 유틸리티 CSS로 자주 쓰는 CSS등을 미리 만들어서 사용하는 방식입니다.
CSS의 초창기부터 오래된 논쟁거리 중 하나였습니다.
.mt10 { margin-top: 10px }
은 좋은 이름인가?
최초에는 시각에서는 이러한 변경의 여지가 없는 시멘틱하지 못한 이름은 좋지 않은 것으로 여겼습니다.
그래서 사람들에게 이러한 방법은 안 좋은 일종의 꼼수로 여겨졌습니다.
하지만 점점 개발하는 환경이 변화하게 되면서 이러한 유틸리티성 class들로만 구성을 해도 좋다는 시각이 나오게 됩니다.
그 출발점을 알리게 된 것이 바로 tailwindCSS 이며 이름을 차라리 직관적인 비주얼한 이름으로 지어두면 오히려 재사용에 유리하고 조립을 통한 확장성이 뛰어나다고 말하고 있습니다.
이렇게 css를 시각적인 이름의 class를 미리 만들어서 재사용하여 조립하는 방식으로,
미리 만들어 두었기 때문에 css를 매번 작성할 필요없이 HTML에서 바로 원하는 서식을 적용할 수 있습니다.
(2022년) 지금은 어떨까?
React의 점유율이 높아져 주류가 된 지금 React와 CSS의 궁합이 사실상 좋지 못했던 부분을 Styled Component와 같은 CSS in JS라는 방식을 통해서 해결하려는 움직임이 나타나기 시작했습니다. CSS in JS에서는 더이상 Selector는 더더욱 무의미해졌습니다.
Svelte나 Vue등에서는 single File Component방식으로 인해 모듈화를 시켜주고 있습니다.
StateOfCSS의 2021년 자료에는 이제 CSS의 방법론이라는 항목조차 사라졌습니다.
CSS가 하던 디자인을 구조화하고 모듈화 하는 역할은 이제 프레임워크가 다 가져가 버렸습니다.
앞으로도 복잡한 Selector를 써야 하는 경우도 CSS의 Selector를 써야 하는 방향도 점점 줄어드는 방식으로 진행이 될 것입니다.
그럼에도 Selector라는 스펙이 있고 이걸 써야할 상황은 오겠죠? 그래서 특별히 Selector를 써야하는 경우에 대해서는 부록으로 책 후반부에 기록해 두었습니다.
이 챕터의 제목이 Selector의 사용법이 아니라 Selector 이야기인 이유입니다.
이러한 배경을 이해하고 나면 어떤 것이 오래된 개념이고 어떤 것이 최신의 것인지를 알게 되어 배움이나 사용에 있어 조금더 트렌드한 것들을 선택할 수 있는 지식이 되기를 바랍니다.
CSS Property
1. CSS 스펙 학습이 어려운 이유1 - 사전식 나열과 중요도 없음
1. CSS 스펙 학습이 어려운 이유2 - 레이아웃의 과도기적 발전
1. 실제로 관련이 있는 것 끼리 묶어서 생각하자 https://9elements.com/css-rule-order/
1. 일단은 레이아웃과 레이아웃이 아닌것으로 분리하는 것이 시작!
1. CSS Property 순서 컨벤션
1. 잘 안쓰이는 것은 나중에 공부하자.
"왜 figma을 기준으로 CSS를 배워야 할까??
1. CSS 스펙 학습이 어려운 이유1 - 사전식 나열과 중요도 없음
1. CSS 스펙 학습이 어려운 이유2 - 레이아웃의 과도기적 발전
1. 실제로 관련이 있는 것 끼리 묶어서 생각하자 https://9elements.com/css-rule-order/
1. 일단은 레이아웃과 레이아웃이 아닌것으로 분리하는 것이 시작!
1. CSS Property 순서 컨벤션
1. 잘 안쓰이는 것은 나중에 공부하자.
"왜 figma을 기준으로 CSS를 배워야 할까??
피그마는 제일 많이 쓰는 디자인 툴. 우리는 대부분 디자이너와 함께 협업을 해야 한다.
🔥 우선순위가 높은 순으로 만들어 두었고 UI를 너무 잘 만들었다.
그래서 중요한 스펙을 시각적으로 이해하기가 좋다!
속성으로만 완성된 디자인의 모양을 상상하기가 어렵다.
Text
Typography font-family: Roboto;
font-style: normal;
font-weight: bold
font-size: 12px;
line-height: 14px;
text-align: center;
// text-indent: 333px;
text-decoration-line: underline;
// text-transform: lowercase;
// font-feature-settings: 'pnum' on, 'onum' on, 'ss02' on, 'ss01' on, 'ss03' on, 'ss04' on, 'ss05' on, 'ss06' on, 'ss07' on, 'dnom' on, 'numr' on;
// word-break (lang:ko) keep-all
Fill
color: #B75959;
Stroke
text-shadow: ...
Frame
Resizing
width: 90px;
height: 44px;
Constraits
position: absolute;
left: 99px;
top: 38px;
z-index: 1
Fill
background: #B75959;
background-image
background-size: cover | contain
// linear-gradient
Stroke
border: 1px solid #000000;
outline
ring(box-shadow)
Effects
box-shadow: 0px 4px 4px rgba(0, 0, 0, 0.25);
box-shadow: inset 0px 4px 4px rgba(0, 0, 0, 0.25);
filter: blur(4px);
backdrop-filter: blur(4px);
Clip
content overflow: hidden
text-overflow
line-clamp
Layout
🔥 AutoLayout
display: flex;
flex-direction: row;
justify-content: flex-end;
align-items: flex-end;
padding: 38px 99px;
gap: 12px
flex: 1
flex-shrink: 0
Visibility
display: none
visibility: hidden
opacity: 0.5
gone
4장. CSS Reset 이야기
왜 CSS Reset이 생겨났을까?
https://velog.io/@teo/2022-CSS-Reset-%EB%8B%A4%EC%8B%9C-%EC%8D%A8%EB%B3%B4%EA%B8%B0
참고 할만한 사이트 모음
reset: https://www.joshwcomeau.com/css/custom-css-reset/
reset: https://github.com/jgthms/minireset.css
box-shadow: https://shadows.brumm.af/
z-index: https://www.joshwcomeau.com/css/stacking-contexts/
예제: https://100dayscss.com/days/1/
소개: https://cssbattle.dev/
CSS Tip
왜 CSS Reset이 생겨났을까?
https://velog.io/@teo/2022-CSS-Reset-%EB%8B%A4%EC%8B%9C-%EC%8D%A8%EB%B3%B4%EA%B8%B0
참고 할만한 사이트 모음
reset: https://www.joshwcomeau.com/css/custom-css-reset/
reset: https://github.com/jgthms/minireset.css
box-shadow: https://shadows.brumm.af/
z-index: https://www.joshwcomeau.com/css/stacking-contexts/
예제: https://100dayscss.com/days/1/
소개: https://cssbattle.dev/
https://medium.com/swlh/css-flexbox-fundamentals-visual-guide-1c467f480dac
https://brunch.co.kr/@eddwardpark/51
[출판] 샘플원고: Flexbox 편
CSS 공부 어떻게 해야 하나요? - 이론편 (feat. figma)
해당 컨텐츠는 완성되지 않은 원고이며 방향성만 담았습니다. 생각나면 조금씩 업데이트를 해보려고 합니다. 누구나 와서 수정을 할 수 있습니다.
https://hackmd.io/vDwTGL5HRo-XaaSgRerMHA
이 컨텐츠의 앞에는
- 기본적인 서식과 box-model 등 문서기반의 CSS은 설명을 했을거라고 가정합니다.
- Normal Flow에 대한 언급은 반드시 필요하겠네요.
- 유틸리티 클래스 방식에 대해서는 언급이 되었을거라고 생각합니다.
MDN: CSS 레이아웃 입문서
... 각각의 기술은 저마다 용도가 있고, 장단점이 있으며, 어떤 기술도 독립적인 용도를 갖추도록 설계되지는 않았다. 각 메서드가 어떤 용도로 마련된 것인지 이해하게 되면 해당 작업에 가장 적합한 도구가 어떤 것인지 파악하는 데 유리한 입지를 점하게 된다. ...
CSS 공부 어떻게 해야 하나요? - 이론편 (feat. figma)
해당 컨텐츠는 완성되지 않은 원고이며 방향성만 담았습니다. 생각나면 조금씩 업데이트를 해보려고 합니다. 누구나 와서 수정을 할 수 있습니다.
https://hackmd.io/vDwTGL5HRo-XaaSgRerMHA
이 컨텐츠의 앞에는
- 기본적인 서식과 box-model 등 문서기반의 CSS은 설명을 했을거라고 가정합니다.
- Normal Flow에 대한 언급은 반드시 필요하겠네요.
- 유틸리티 클래스 방식에 대해서는 언급이 되었을거라고 생각합니다.
MDN: CSS 레이아웃 입문서
... 각각의 기술은 저마다 용도가 있고, 장단점이 있으며, 어떤 기술도 독립적인 용도를 갖추도록 설계되지는 않았다. 각 메서드가 어떤 용도로 마련된 것인지 이해하게 되면 해당 작업에 가장 적합한 도구가 어떤 것인지 파악하는 데 유리한 입지를 점하게 된다. ...
이번 장에서는 CSS의 꽃이라고 불리는 flexbox Layout에 대해서 알아보도록 하겠습니다!
4장. Flexbox - 핵심 편
문서에서 앱으로 진화하는 과정에서 생긴 레이아웃 스펙의 과도기 시절
Web은 최초 문서를 만들기 위해서 만들어졌지만 웹 산업이 점점 발전하면서 사용자와 인터렉션이 강화되면서 점점 단순한 문서가 아니라 홈페이지의 형태로 그리고 점점 더 어플리케이션과 같은 역할을 하게 되면서 웹 디자인의 요구사항이 변화하게 되었습니다.
CSS는 처음에는 이러한 어플리케이션 UI를 만드는 의도를 가진게 아니었기 때문에 이러한 어플리케이션 UI와 레이아웃을 만드는 방법이 없었습니다.
그래서 원래 이미지와 문서를 어울리게 배치를 하기 위한 float라든가 표를 만들기 위한 table, 기타 inline block과 같은 문서를 만들기 위한 스펙들을 조립해서 복잡하게 레이아웃을 해야하는 과도기 시절이 있었습니다.
flexbox는 Application 레이아웃을 하기 위해 태어났다.
그래서 사람들은 CSS로 복잡한 UI를 만드는 것에 불만이 있었고 이러한 레이아웃을 하기 위한 새로운 스펙을 만들어야 했습니다. 이후 2009된 출시된 box라고 붙여진 레이아웃방식이 태어났지만 다양한 레이아웃을 다 담아내지 못했기에 한번 deprecated 되었고 이후 flexbox라는 스펙이 2012년 정식으로 태어났습니다.
하지만 당시 Major 브라우저인 IE의 지원부족으로 인해 여전히 복잡한 CSS를 통해서 레이아웃을 해야만했고 사람들이 습관처럼 당연히 IE를 지원을 해야하다 보니 해당 스펙이 보편화가 되기까지는 오랜시간이 필요했습니다.
그러면서 이때 만들어진 자료들이 제일 많았기 때문에 flexbox의 사용법이나 응용법에 대해서는 저마다의 방법들이 달랐으며 덕분에 CSS의 레이아웃은 여전히 어려운 스킬이었습니다.
앱 레이아웃의 시작은 가로로 배치한다는 것
(여기는 다다시 쓸 것)
(요점 - 가로로 배치하는 것이 달랐다! 중요하다!)
flebox는 문서가 아니라 어플리케이션의 UI를 만들기 위해서 탄생을 했다고 하였습니다. 그렇다면 문서와 어플리케이션 UI의 가장 큰 차이점이 뭘까요? 아니 기존 CSS에서 가장 하기 힘들었던 UI는 어떤 것이었을까요?
기존 문서기반의 CSS에서 가장 어려웠던 것이 바로 콘텐츠를 가로와 중앙에 배치한다는 거였습니다. 그래서 flex라고 만들어졌던 것들 처음에 기본 개념이 아무것도 속성하지 않았을 때는 가루로 배치된다는 걸 알 수가 있죠.
여하튼 콘텐츠에서 가로로 배치한다는 거는 굉장히 중요합니다. 그래서 플렉스 박스는 내가 어느 방향으로 콘텐츠를 배치할지를 결정할 수 있고 이 콘텐츠를 어떤 식으로 놓을지 어떤 식으로 간격을 벌려놓을지 그리고 남는 크기에 따라서 어떻게 크기를 지정을 할 수 있을지 이러한 단계로 레이아웃을 결정할 수 있게 됩니다.
이때부터 컨테이너라는 개념이 생겼다.
이때부터 컨테이너라는 개념이 생겨납니다. 그전까지 CSS 레이아웃의 기준이 항상 본인을 중심으로 하는 개념이었다면 처음으로 레이아웃을 중심으로 하는 자식의 레이아웃을 구조를 반영하는 부모가 레이아웃을 컨트롤하는 어떤 형태의 구조가 나왔다라고 보시면 될 것 같습니다.
그래서 앞에서 배웠던 css와는 다르게 외부에서 레이아웃을 잡아주는 형태로 생각을 하셔야 돼요 그래서 나의 레이아웃이 아니라 이 자식들의 콘텐츠 간의 배치를 돕는 속성이다라고 생각을 해 주시면 좋을 것 같아요.
그래서 가로로 배치를 하게 되면 지금 보시는 것처럼 내가 어떤 콘텐츠가 있을 때 내가 콘텐츠를 가로로 배치할 것인가 세로로 배치할 것인가 결정을 할 수가 있습니다.
자식 컨텐츠(=컴포넌트)의 레이아웃 요소를 배제하고 레이아웃만 담당하는 컨테이너로 배치를 하는 방식이 보편화 됨.
과도기는 끝났다! 이제는 flexbox만 써도 되는 상황이 왔습니다.
2022년 현재 flexbox는 사용하지 못하는 브라우저가 없으며 인지도 및 사용율의 거의 100%에 가까운 스펙이기에 레이아웃을 한다면 flexbox를 사용하는 것이 너무 당연한 정석이 되었습니다.
그러나 아직도 오래전에 만들어진 사이트들이 float등으로 레이아웃이 되어 있기도 하고 이미 만들어진 커리큘럼이나 웹 문서등으로 인해 flexbox의 최신 방법들이 아닌 레이아웃 방식이 아직 남아있기도 합니다. 지금은 flexbox나 grid가 아닌 다른 방식이 아닌 방식으로 레이아웃을 설명하고 있다면 문서의 연도를 꼭 확인해보시기 바랍니다.
flexbox가 모든 브라우저에 동작을 하고 사용자들의 경험치가 쌓이면서 이제는 각자만의 Best Practice들이 정립이 되고 있는 중입니다.
flexbox의 스펙 역시 모든 스펙을 사용할 필요가 없습니다. 이번 장에서는 제가 정립한 flexbox의 핵심 내용을 함께 배워 보려고 합니다.
이제 옛날 스펙 레이아웃은 사실상 쓸모가 없다. 원래 의도로만 써야한다.
float, inline-block, table 로 레이아웃을 해야할 필요가 없다. XX장에서는 기타 레이아웃 속성을 모아서 이해할 수 있도록 모아두었습니다. 해당 레이아웃의 취지를 이해하고 그 스펙으로만 할 수 있는 레이아웃을 작업 하도록 합시다.
flexbox는 현재 CSS의 보편적인 레이아웃을 쉽게 만들어 낼 수 있는 스펙이기에 꼭 알아야할 CSS의 꽃과 같은 존재입니다.
이번 장에서는 웹의 레이아웃의 가장 기본이 되는 개념 flexbox에 대한 이야기를 해보려고 합니다!
Let's go!
Flexbox 시작하기에 앞서...
필독! CSS는 많이 아는 것보다 Best를 찾는게 중요하다.
(다시 써야됨. 아래 내용은 글이 아니라 메모 입니다. )
CSS는 여러가지 방법으로 같은 모양을 만들어 낼 수 있다. 방법을 많이 아는게 중요하지 않다. 간단하고 최소한의 노력으로 원하는 모양을 만들어 내는 방법을 알고 있는 것이 중요하다. 여기에서도 깊게 얘기하지 않고 꼭 필요한 핵심만 먼저 적을 것이다. 더 몰라도 되니 이것의 사용법에 먼저 익숙해져라. 이후 고급편에 다시 추가적으로 더 알면 좋을 만한 스펙을 알려줄 것이다.
절대로 하나씩 하나씩 다 깊게 팔 배우고 하는 게 아니라 자기 손에 꼭 맞는 베스트한 방법들을 찾는 게 중요하고요 여기서 설명드릴 것은 저도 가장 간소한 방법에 대해서 간단하게 플렉스 박스를 할 수 있는 방법에 대해서 알려드리려고 합니다.
CSS는 숙달이 더 중요하기 때문에 핵심만 먼저하고 추가적인 이론을 뒤에 다루는 방식으로 진행하겠습니다!
Best Practice의 소스: figma의 AutoLayout!
figma AutoLayout은 flexbox의 subset으로 일부 개념만 축소해서 가져왔다.
그럼에도 거의 대부분의 디자인이 가능! 디자이너가 모든 스펙을 쓰지 않아도 디자인이 되는데 개발자가 굳이 복잡하게 바꿔줘야할 이유가 없다.
제가 써왔던 경험과 AutoLayout을 근거로 Flexbox의 핵심과 Best Practice를 알려드립니다.
figma AutoLayout의 핵심 구성
(figma AutoLayout의 UI 설명 - 책에서 사용해도 되나? 아니면 언급 정도만 하면서 넘어가자.)
- 방향 - 가로, 세로
- 배치 + (space-between)
- 패딩
- 간격
- 크기 - hug content, fixed width, fill-container
이것만으로 충분하니 이 정도의 범위만 핵심으로 익히고 실습을 해서 익히고 나면 고급을 배우도록 하자!
flexbox도 이 부분만 가지고 얘기를 하겠습니다.
Flexbox 시작하기
일단 플렉스 박스 이해를 합시다 문서처럼 보이지 않는 레이아웃이라는 것들은 어떤 걸 과연 이런 거죠.
출바라든지 대표적인 케이스가 이 바로
툴과 아니면 내비 모양입니다 가로로 배치하는 부분이거든요.
우선은 기본적으로 콘텐츠는 저렇게 가로로 배치하는 게 없어요.
콘텐츠를 가로로 배치할 것인가 세로로 배치할 것인가: flex-direction(= flex-flow)
그래서 이 방향을 결정해 주는 걸로 flex-direction라는 걸 쓰고 있고요
row한 방향이냐 column만 방향이냐 두 가지를 정할 수 있습니다.
구 버전에서는 horizontal, vertical이어서 조금 더 직관적이었다고 생각합니다. row=가로, column=세로로 기억해두자. 기존 스펙을 덮어 쓸 수 없다는 점이 있고 타이핑 측면에서는 지금이 나은 것 같다.
그리고 이렇게 방향이 결정이 되었다면 이제 콘텐츠들이 박스에서 어디에 놓일지를 한번 생각을 해봅시다 콘텐츠가 존재한다면 이 박스는 레이아웃의 가운데에 배치될지 상단에 배치될지 혹은 하단에 배치될지 왼쪽에 배치될지 오른쪽에 배치될지
혹은 가운데 배치될지 이런 9가지의 배치 방법이 존재합니다.
flow-direction은 방향을 설정한다. flex-flow는 방향과 flex-wrap을 함께 적을 수 있는 속성이다. 결국 짧은 CSS를 작성하는게 좋으니 이후 flex-direction대신 flex-flow로 작성을 하겠습니다.
메인 축과 교차 축
(컨텐츠를 배치하는 9군데 영역, 다 그려서 펼쳐주는 방식으로 그려두자!)
박스형 컨테이너 내부에 컨텐츠를 배치하게 된다면 우리는 위와 같은 다양한 방법으로 컨텐츠를 배치할 수 있게 됩니다. flexbox는 이렇게 다양한 배치를 하기 위해 크게 2가지의 방향으로 나눠서 어떤식의 배치를 할지 조립하도록 설계가 되었습니다.
(이건 좀 좋게 다시 그리자!, 가로 세로 둘다..)
flexbox라는 거는 메인 축이 존재하고 그다음에 교사 축이 존재해서
온라인 바이패지는 교차 축에 대한 어떤 위치를 잡는 것이다라고 되어 있는데요.
조금 더 쉽게 이야기하려고 하면 바라보는 방향에서 좌우를 컨트롤 한다는 개념으로 생각하시면 될 것 같습니다.
내가 가로를 배치하고 있을 때 나는 가로를 이 방향으로 바라보고 있으니까 anline iite들은 왼쪽과 오른쪽
건들게 되는 부분인 거고요 제대로 바라보는 방향에서는 위아래겠네요.
좌.우.가운데, 늘리기! : align-items
그래서 이 배치를 바꿀 수 있는 방법 그걸 알아야 되는데 첫 번째로 알아야 될 내용이 온라인 아이템즈입니다.
온라인 아이템즈는 보통 설명을 배우면 보통 이렇게 되어 있습니다.
메모:
(사람이 바라보고 양팔을 벌리고 있는 그림)
(좌, 우, 가운데, 늘리기를 팔로 보여주고 있는 그림)
align-items는 크로스, 좌우, a키를 누르고 있는 것을 상상해보자. (왼쪽 오른쪽)
가로에서 보았을때는 start가 위, 아래
세로에서 보았을때에는 start가 좌, 우
이것은 글자를 쓰는 순서와 연관이 되어 있다.
이제 해로를 알아봤을 때는 이렇게 이렇게 좌우라고 생각하시면 좋겠습니다.
이렇게 머릿속에 한번 기억만 해주시면 다음부터 어렵지 않으실 거고 머릿속에 그림이 그려지실 거고요 외우는 방법은 왼손의 키보드에 a를 누른다는 생각으로 왼쪽 오른쪽 이 그림 그리고 잡아서 늘린다 이렇게 이름만 생각을 하시면 이거 설명을 해주고 이 얘기를 해줘야겠다.
바이러스 콘텐츠를 가운데 배치하기 위해서는 이 a라인 아이템들을 센터로 두시면 센터 라인에 정렬을 해서 맞출 수가 있게 됩니다.
그리고 네 밑에 만들고 싶으면은 플렉스 랜드를 쓰시면 되고 상단으로 대체하고 싶으면 플렉스 스타트를 쓰시면 됩니다.
콘텐츠가 이렇게 있으면은 나라는 방향으로
어떻게 모아둘까? 벌려둘까? : justify-content
align이 늘리기라고 외웠으면 justify-content는 space-between 과 짝꿍. 꼭 함께 외워야 한다.
(그림으로 보여주기, 왼쪽, 오른쪽, 가운데, space-between)
메인 축으로의 어떤 배치도 봐야겠죠.
이럴 때는 콘텐츠 저스티파이라는 걸 씁니다.
스트레스도 얘기해야 되고 늘린다도 얘기해 줘야 되고
콘텐츠 간의 간격이랑 어떻게 놓을지가 중요하기 때문에 네 앞쪽으로 모아놓을지 뒤쪽으로 모아놓을지
그리고 저스티파이는 스트레이스 비투윈과 함께 연결해서 외우시면 되겠습니다.
그래서 내가 왼쪽으로 모으겠다라고 스타트고요 오른쪽으로 모으겠다라고 마인드입니다.
그리고 언제나 스타트는 위 아래 혹은 자 이렇게 되어 있고 언제든 늘릴 수가 있다.
그리고 콘텐츠가 여러 개 들어가는 공간이면은 콘텐츠를 벌릴 수 있다.
벌리는 거는
스페이스 비투비 비스트 비스 비투비는 저 스티파일이랑 콘텐츠와 함께 묶어주시고 라인 아이템들은 라인 아이템들을 늘려준다 이렇게 개념을 머릿속에 들고 가시면 배치하는 데는 그렇게 어려움이 없습니다.
그래서 우리는 콘텐츠를 어떻게 배치하고 종료해 둘 수 있는지를 알게 되었습니다.
조합 연습해보기
그래서 다음과 같은 순서대로 작성을 해봅시다.
1) flex-flow: 컨텐츠의 방향
2) align-items: 방향과 교차방향의 위치
3) justity-content: 나머지 위치
계속 크로스로 확인하는 것이 포힌트
(말로 설명하니까 이상하다 이 과정을 그림으로 보여주자.)
이러한 방향들은 글을 쓰는 방향을 기준으로 만들어졌다.
헷갈린다면 계단을 그려보자! 방향, flex-end, flex-end
➡️⬇️➡️
.hbox--bottom-right {
display: flex;
flex-flow: row;
align-items: flex-end;
justify-content: flex-end;
}
⬇️➡️⬇️
.vbox--right-bottom {
display: flex;
flex-flow: row;
align-items: flex-end;
justify-content: flex-end;
}
연습해보기
다음 예시들을 보고, 방향, align-items, justift-content 알아맞혀 보기
예시 1) 1 2 3
예시 2) 123
예시 3) 123
(예시 배치 그림 그리기)
이런 것들을 게임으로 해볼 수 있는 연습 방법이 존재한다. flexbox froggy, flexbox 좀비. 추천!
flexbox 세부적인 디자인 잡기
이제 세부적인 디자인은 바로 간격!! 간격은 크게 2가지
1) 컨테이너와 컨텐츠의 간격
2) 컨텐츠 간의 간격
(이것도 좀 그림으로 그리자)
이제는 margin으로 간격을 조절하는 것은 좀 old한 방법...
기존에는 이러한 간격을 조절하는 방식을 Element를
기존에는 이런 것들을 좀 마진으로 해결을 하려고 했어요.
하지만 시간이 지나고 확인을 해보니까 마진으로 작업을 하는 거는 별로다라는 것을 깨닫게 됩니다.
왜냐하면 컴포넌트의 마진을 보통 이런 것들을 프레임워크로 만들다 보면 보통 이 버튼들이 컴포넌트 형태로 정리가 되는데 컴포넌트의 마진이 들어가게 될 경우엔
컴포넌트를 배치하거나 컨트롤하는 데 굉장히 어렵다는 것을 알게 돼요.
(마진을 쓰면 누구에게 마진을 줘야할지 고민하는 내용의 그림)
예전에는 이 세부적인 사이의 간격을 margin을 통해서 작업을 했었어요.
하지만 컴포넌트의 방식으로 변하게 되면서 컴포넌트의 마진을 가지고 있다는 것은 굉장히 안 좋다라는 걸 깨닫게 됩니다.
왜냐하면 마진이라고 하는 거는 아이템의 어떠한 주위에 서로의 영향으로 콘텐츠가 만들어지는 건데 보통은 대부분 어떤 콘텐츠와 어떤 콘텐츠 사이의 간격이라고 표시가 되고 있거든요.
그러면 이 마진에 대한 소유권에 대한 문제가 발생을 하게 됩니다.
과연 이 사이의 간격은 이 친구의 것일까요.
이 친구의 것일까요. 이런 부분이 헷갈리기 때문에 현대에 들어가서는 이렇게 margin을 개념을 쓰기보다는 이 사이의 간격을 표시하는 gap이라는 개념을 가지고 프로그래밍을 하도록 스펙이 나왔습니다.
이게 더 좋다는 것을 알게 되었거든요.
(일반적인 디자인 명세서와 함께 gap의 의미를 설명하는 그림)
이 것이 컨테이너 개념으로 생각하는 연장선상!
margin이 나쁘거나 쓰면 안된다는 얘기가 아니다~ margin을 안씀으로써 우리가 더 편하고 일관되게 CSS를 쓸 수 있다는 의미! 필요하면 써야지. 융통성을 가지자!
그래서 지금은 gap과 padding을 쓰자!
그래서 가급적 컨포넌트에서 마제를 주도하거나 아이템의 margin으로 간격을 맞추는 게 아니라 부모에서 컨트롤 하는 게 좋다는 식으로 만들어지고 그래서 그냥 따끈한 스펙인 갭이라는 게 등장을 합니다.
그래서 이 갭을 통해서 맞추는 걸 확인할 거고요
단순합니다. 그래서 갭을 얼마를 적으시면 이 사이 간격이 얼마씩 늘어나고 있다는 것을 확인할 수 있습니다.
그러면은 이 바깥의 간격은 어떻게 할 거예요.
우리가 알고 있는 패딩을 쓰면 되겠습니다.
그래서 바깥에 있는 여백의 패딩 그리고 콘텐츠 간 간격의 갭을 이용해서 우리가 원하는 레이아웃을 적절히 만들 수 있게 됩니다.
그래서 메모를 그려보시고 내가 콘텐츠를 배치한 다음 이렇게 이렇게 있는 화면에서 각각의 아이템을 통해서 콘텐츠를 배치해보는 해보신다면 디자인을 원하는 대로 만들 수 있게 됩니다.
이렇게 하면 콘텐츠를 그래서 출발을 한번 만들어 봅시다 기본적으로 나중에 해야겠구나 이런 식으로 콘텐츠를 배치하
gap이 없던 시절에는 >*+* 올빼미를 썼다.
그래서 이 갭이 없던 시절에는 다음과 같은 부엉이 표기법으로
이 갭이라는 걸 쓸 수가 있게 되었고요 지금은 정식 표준 스펙이 되었기 때문에 갭이라는 것을 쓰면 됩니다.
gap 스펙은 아직 IE 11과 사파리 14 이하 버전에서 동작하지 않는다.
지금 현재 쓰고 있는 주류 브라우저가 브라우저에 아직까지 사파리 14 이하나 이 11이 존재하고 있다라고 하면 예전에 쓰고 있던 갭을 사용할 수 있기 때문에 그대로 사용하셔도 괜찮습니다.
(올빼미 표기법에 대한 간단한 설명..)
이게 길어지겠다 싶으면 부록으로 옮긴다.
다른 크기의 gap이 필요할 때 1? space
그게 아니라면 가운데에 스페이스를 넣어두는 방식도 추천을 합니다.
하나는 빈 엘리먼트를 집어넣어서 백을 여백처럼 동작하는 어떤 콘텐츠를 집어넣는 방식인 거고요
HTML에 빈 엘리먼트를 만들어서 간격을 채워두는 방법도 있다.
(코드 보다는 이미지가 낫겠다.)
<div class="hbox">
<div>1</div>
<div class="space4"></div>
<div>2</div>
<div>3</div>
</div>
<style>
.hbox { display: flex; }
.space4 { padding: 0 0 4px 4px; }
</style>
다른 크기의 gap이 필요할 때 2? sub-flexbox
나머지 하는 방법은 이제 여기만 다시 다시 그룹으로 묶어서 거기 콘텐츠의 갭을 따로 별도로 지정하는 방식입니다.
이런 방식으로 이런 이렇게 박스를 다시 그룹이 하기 위해서는 부모의 어떤 속성과 똑같으면 되기 때문에 이럴 때는 이런 서브 박스 혹은 서브 클래스라는 어떤 클래스를 만들어서 사용하면 굉장히 편리합니다.
응 그 밖에 그리고 나머지 공간에 대해서 내가 콘텐츠를 늘려서 공간을 채우는 방식 이 필요하게 되고 이게 플렉스 박스에 꽂힌 플렉스라는 속성입니다.
.sub-flexbox {
display: inherit;
flex-flow: inherit;
align-items: inherit;
justify-content: inherit;
}
서브박스는 앞에서 설명을 했지만 한 번 더 설명을 드리자면 서플렉스 같은 느낌을 만들 수가 있습니다.
그는 디스플레이 inn리트를 이용하고 라인 itt나 stfi 콘텐츠를 이내리 해서 내가 그룹을 만들고 거기에 적당한 갭을 주게 되면 이 앱을 통해가지고 내가 원하는 어떤 특정 영역만 조금씩 떨어뜨릴 수 있는 방법으로 만들 수 있습니다.
이렇게 하지 않더라도 가운데
가운데에 어떤 스페이스를 줄 수가 있게 되는데 내가 전체적으로 김을 건 다음에 여기 스페이스를 주게 되면 이 스페이스를 따로 계산해야 되는 어떤 문제가 발생하기 때문에 그걸 생각을 하셔서 이걸 대체하셔도 내가 이게 굳이 감싸는 거에 대해서 귀찮음이 있을 경우에 이런 걸 만들지 않아도 좋고 필요하다면 이런 부분들은 비트리스를 만들어줘서 작업을
컨테이너와 콘텐츠의 크기
figma에서는 3가지 타입으로 나눈다. hug-contents, fixed-size, fill-container
우리도 이렇게 3가지로 나눠서 생각하자.
컨텐츠에 따라서 vs 고정된 크기로
width, height가 auto인 경우에는 내부 컨텐츠의 크기를 따라간다. 크기를 지정하면 컨텐츠와 관계없이 크기가 고정이 된다.
flexbox에는 추가로 가변 크기가 존재한다. flex: 1
가변의 어떤 영역이 필요한데 이 가변의 영역을 정해주는 게 플렉스 플렉스를 알고 있어야
플렉스 박스를 다 아는게 되는 거죠.
플렉스는 복잡하게 생각하지 말고 이 중에 크기 하나를 가변으로 만든다라고 생각하시면 되겠습니다 가변이기 때문에 나머지 공간을 그냥 꽉 채워준다라고 생각하시면 될 것 같아요.
그래서 패치가 필요한 부분에 언제든지 클래스를 통해서
얘를 가변으로 만들어주기 면 나머지 공간을 알아서 채우고 혹은 선택에 따라서 줄어든다 그래서 보편적으로 디자인은 어떻게 하느냐 자식의 콘텐츠는 기본적으로 세 가지 속성을 가집니다.
콘텐츠를 따라 가든가 아니면 고정된 크기가 있거나 혹은 플렉스하게 나쁘거나 이 세 가지 속성을 지정해 주는 방법을 알고 계시면
flex-grow?, flex-shrink?, flex-basis?
이 플렉스라는 속성은 플렉스 글로우 블렉스 슈링크 플렉스 베이시스라는 세 가지 속성으로 만들어지고 있는데
각각에 대해서 설명을 하자면 는 만큼 남는 공간이 있을 때 얼마만큼 정도를 분배를 해서 넣을 것이고 줄일 것이고 크게 할 것이고에 대한 얘기지만 사실 이거를 이론적으로 이해하기에는 되게 복잡하기 때문에 그냥 내가 이 중에서 적어도 하나의 플렉스는 가지고 있다라고 생각을 하시면 굉장히 단순하게 생각을 할 수 있습니다.
그래서 지금까지 알려줬던 plex 박스의 이 개념들 방향을 정하고
어디에 배치하고 좌우로 배치하고 앞뒤로 배치하고 간격을 정해주고 패딩을 정하고 간격을 정해주고 하는 이 방식만 가지고 그리고 나머지 특정 공간에서 반응형 가변으로 작동을 해야 되는 공간 옆 가면으로 작동해야 되는 공간을 지정해 주는 이 단계만 가지고도
플렉스 박스의 90% 이상의 실전에서 나오는 모든 데이터를 할 수가 있습니다.
일단 * { flex-shrink: 0} 으로 설정하고 flex: 1만으로 충분히 다 커버가 가능하다.
자세한 개념은 고급 편에서 다시 설명을 합니다.
일단 flex:1 의 활용법을 익혀봅시다.
(flex:1을 이용하고 있는 예시 이미지들)
나만 특별해! align-self, justify-self
특별히 하나의 컨텐츠만 크기가 다르면 콕 집어서 align-self 혹은 justify-self를 사용해 줄 수 있습니다.
컨텐츠마다 정렬의 기준이 다를 때 사용합니다.
(예시 카톡의 채팅방 디자인의 시간대 표기)
tip2: fill-container를 만드는 방법 align-self: stretch
@TODO: 내용 좀 더 추가할 것
디자인을 보고 flexbox로 생각하기
CSS 공부는 어떻게 해야 하나요 - 실전편
CSS 레이아웃 분할과 Flexbox
(대충 가이드가 없는 디자인)
실전에서는 어떻게 레이아웃을 잡을 수 있느냐 디자인이 있다면 일단 여기 디자인에서 내가 적절한 선으로 잘라주시면 되겠습니다 가로 선을 긋고 새로 선을 긋되 겹치지 않도록 그 선이 선을 지나가지 않도록 선을 최대한 잘라보시면 될 것 같습니다.
(가이드를 그려준 디자인)
그래서 지금과 같은 예시 레이아웃이 있다고 쳤을 때 적당히 예쁘게 선을 그어보면서 분해를 한다고 생각해 보면 이런 식으로 저런 식으로 잘리고 분해가 될 수 있겠죠.
이것까지는 그냥
생각해내야 합니다. 디자이너한테 알려달라고 하셔도 되고 본인이 한번 그거 보시면서 콘텐츠가 글자는 콘텐츠를 겹치지 않게 화면을 잘라 보신다면 충분히 구획을 나누는 게 어렵지 않으실 겁니다.
그러면 이렇게 구획이 다 나눠지고 나면 모든 화면을 자르는 구획이 있는지를 찾습니다.
그냥 말은 어렵지만 예시를 보면 지금 보였듯이 어떤 가로선이든 세로선이든 모든 게 다 딱 2등분이 될 수 있는 반으로 다 쪼개질 수 있는 선이 그어지는 곳이 있다면 그 방향으로 시작을 하게 되는 겁니다.
콘텐츠를 그 선을 통해서 송송 잘랐다고 생각을 해보면
이 cts가 어디에 배치되는지 알 수 있겠죠.
그러면 이렇게 하나의 container가 만들어져서 컨테이너er 안에 이제 cpnt가 배치되어 있다고 보시면 되겠습니다.
그리고 이렇게 plass box를 만들어내서 gap과 padding과 내용을 정리해서 세부적으로 하나씩 하나씩 하나씩 들어가시면 됩니다.
figma의 AutoLayout는 flebox 모든 기능을 다 쓰지 않지만 디자인이 가능하다.
지금까지 배운 것들만 가지고 flexbox를 먼저 이해하고 실습을 한 뒤에 고급을 들어가도록 합시다!
이게 가능하다라고 보여줄 수 있는 방법 증명이 되는 부분은 figm에 있는 atol이아웃에 보면 atlayout은 플렉스 박스의 서브 se 개념으로 만들어진 디자인 툴인데 이걸로 대부분의 디자인을 다 만들 수가 있습니다.
그리고 실제로 이 이상의 기능이 필요한 경우에는 디자인 툴에서 도와주지 않겠죠.
그럼에도 디자이너들은 원하는 디자인들을 토리 해서 다 만들 수 있기 때문에 실제로 해서 css에서는 이 이상의 범주를 만들어내는 것은 굉장히 고급 기법에 속합니다.
이런 식으로 편하게 작업을 할 수 있고요 딱 지금까지 지금까지 알아야 될 속성만 가지고 거의 대부분의 콘텐츠를 레이아웃이 가능하게 됩니다.
이것은 피그마의 오토 레이아웃에 있는 수준이니까요.
여기까지가 핵심이고 이것을 통해서 일단은 익히는 거를 먼저 하시길 바랍니다.
이 이상 필요한 기능에 대해서는
시장에 더 자세하게 기록처럼 다룰 예정입니다.
이렇게 하는 이유는 설명을 하다 보면 자주 쓰이지 않는 기능인데 자주 쓰이지 않는 이유는 당연히 직관적이지 않고 아는 필요도에 비해서 알아야 될 지식들이 많아지기 때문이고요 이러한 과정들에서
사람들이 학습을 할 때는 보통 어렵다라고 생각하는 부분들을 좀 집중해서 공부하게 되는 경향이라는 게 생기고 중요도의 전후 관계를 바꿔서 생각하는 것은 별로라고 생각합니다.
실습을 통해 Flexbox를 익혀보자. UI Component 만들기!
지금까지 배웠던 flexbox의 내용을 통해 자주 쓰이는 UI Component를 만들어보면서 flexbox를 내것으로 만들어보자!
아이콘이 있는 Button 만들기
(샘플 디자인)
(샘플 코드)
.button {
display: flex;
align-items: center;
padding: 1rem;
gap: .4rem;
}
Toolbar 만들어보기
(샘플 디자인)
(샘플 코드)
한번 만들어 봅시다 예시 툴바입니다 가장 보편적으로 많이 쓰이는 툴바인 거고요 거기에서 지금 생긴 게 이렇게 생겼으니까 가로로 배치되겠죠.
그래서 투바의 h 박스 이 디스플레이 플렉스를 걸어주고 보면은 가운데 연결이죠.
그래서 alin intez 센터를 열어주겠습니다.
그리고 적당히 간격이 한 4000 네요.
일단
외부 패딩을 넣을 건지 아니면 간격인 건지 확인을 하고 외부 패딩을 넣어준 다음 간격을 잡아주고
콘텐츠를 배치한 다음 마무리를 하면 될 것 같습니다.
여기서 내부 간격을 쓸 건지 이 사이가 간격인 건지 아니면 타이틀 영역의 패딩인 건지 이것들은 너무 중요하지 않으니까 본인이 생각하는 마음의 눈을 통해서 가장 간단한 방법들을 가지고 개발을 하시면 될 것 같아요.
내친 김에 2단 레이아웃도 한번 해봅시다 이렇게 레이어를 전체가 100%가 돼야 되는 이 바디와 헬치어드 html과 바디에다가 hight 100%를 주고 bod에다가 display prax와 blf로 칼럼을 줬습니다.
그리고 반반씩 나눠야 되기 때문에
t 박스를 줬고요 콘텐츠 메인 콘텐츠를 두 개씩 만들어서 그냥 플렉스하게 준 다음에
왼쪽에다가 내비를 만들고 오른쪽에다가 적당히 콘텐츠를 만들 수 있는 형태로 레이아웃을 잘라봤습니다.
레이아웃은 레이아웃을 자르는 방식은 가위질을 해서 무조건 분빙을 낸다라고 생각하시면 될 것 같고요 콘텐츠가 이렇게 생겨먹었을 때 적당히 콘텐츠를 나눠야 될 영역들이 눈에 보이죠.
이렇게 이렇게 선을 그어봤을 때 완전히 반
로 갈라지는 영역들이 있다면 그 부분이 첫 번째 댑스가 됩니다.
그래서 그렇게 댑스를 만들고 방향성을 확인을 하시고 정 작업을 한 다음에 padding과 갭을 쥐고 마무리를 하고 넘어가게 되겠습니다.
그리고 콘텐츠를 고정 콘텐츠로 따라가야 될지 그러니까 고정 하이트를 줘야 될지 콘텐츠에 따라 가변이 돼야 되는 건지 아니면은
나머지 여백에 따라서 전체 부부에 따라서 가변의 영역이 돼야 될지 세 가지 중에 하나를 선택을 해서 지정을 해 주시면 되고요
가져놨으면은 또 각각의 세부 사항으로 들어가서 어떤 식으로 만들면 좋을지 작업을 하시면 되겠습니다.
는 끝입니다. 이 이상 플래pac 링크는 0으로 만들어 두시고 작업을 하시면 영어로 만들어서 작업을 하시고 내가 콘텐츠를 강제로 이게 줄여야 하는 경우는 말조림밖에 없습니다.
그래서 내가 말조림을 넣어야 되는 어떤 콘텐츠에 대해서만 이렇게 말조림을 넣고 플렉스를 꼭 넣어주신 다음에
그리고 가연이 필요한 콘텐츠 가연이 필요한 콘텐츠에 플렉스 2를 넣어두시면 얼마든지 내가 원하는 디자인의 레이아웃을 간단히 할 수 있게 됩니다.
그래서 이 이상의 어떤 콘텐츠의 어떤 응용법은 따로 플레이스 박스 브록에다가 만들어 고급이 아닙니다 고급이 아니고요 브록에다가 다시 한번 정리를 해보겠습니다.
정리를 하면 그렇습니다. 플래시 박스는 레이아웃을 만들기 위한 장치고 가로냐 새로냐 방향을 결정한 다음에 어디에 배치할지 방향 배치를 정하고 바깥의 패딩과 내부의 간격을 정해서 만든다 내부 간격이 달라질 경우에는 서브박스를 만들어서 감싸주던가
아니면 빈 스페이스를 하나 추가하면 된다
유틸리티를 쓰면 더 좋다 이 이상 쓰려고 하지 마라 콘텐츠 사이즈는 위드 고정이냐 콘텐츠를 따라갈 거냐 나머지 여백을 따라갈 거 부모를 따라갈 거냐 세 가지가 있다.
그리고 고급으로 들어가게 되면 맥스 위드랑 미니드를 통해가지고 이런 고급 부분은 저기 스크롤 스냅이랑 함께 만들어서 스와이프
Card 만들어보기
(샘플 디자인)
(샘플 코드)
블렉스 박스 실습을 하는 느낌으로 한 번 더 설명을 좀 드려볼게요 처음에 우리가 이제 이러한 카드를 만들려고 한다라고 생각을 하고 한번 클래스 박스 작업을 해봅시다 일단 사진이니까 콘텐츠가 옆으로 나란히 있죠.
이럴 경우에는 우리가 생각하지 말고 플렉스 박스를 쓰면 된다고 가로로 대체하기 위해서는 bls 박스를 쓴다라고 생각을 하시면 되겠습니다.
그래서 전체를 감싸주는 플렉스 박스를 하나 만들고요 가로로 배치하죠.
그래서 플렉스 플로우는 로우가 되겠습니다.
물론 이거를 적지 않으셔도 상관은 없습니다 가루가 기본이니까요.
그래도 적어두시면 헷갈리지 않는다
플렉시 flw lo를 적어주겠습니다.
그리고 보시면 어디로 배치되어 있죠 위로 사진이 위로 배치되어 있죠 그렇기 때문에 라인 아이템들을 하고 넷플렉스 스타트를 적어주시면 되겠습니다.
그리고 적당히 간격을 줘야겠네요. 외부 간격은 어떻습니까 한 이 정도 띄워주면 될 것 같네요.
그래서 패딩은 10픽셀 정도로 적어주겠습니다.
그리고 사이 간격은 얼마죠 사이 간격은 대충 12세 되겠네요.
그래서 갭을 12세를 적어줍니다. 그리고 이미지를 감싸고 콘텐츠를 감싸고 제목을 집어넣고 글자 폰트를 적당히 이렇게 적어주시면 짜잔하고 멋있는 가로 카드가 완성이 되었습니다.
이 괄호 카드를 모바일에서 만들기 위해서는 반응형으로 만들어야겠죠.
그래서 이 자리에서 그대로 복사를 한 다음에 한번
다시 한번 만들어봅시다 일단 세로를 배치해야 되니까 디스플레이 박스을 유지한 상태에서 네 칼럼으로 바뀌게 되겠죠.
이렇게 칼럼으로 바뀌게 될 거고요
네 다를 거 없습니다. 컬러문으로 바뀌면은 우리가 원하는 그를 만들 수 있겠네요.
그리고 크기나 크기를 원으로 적당히 줄여서 모바일에서는 이런 식으로 그리고 이렇게 걸었을 때는 가로로 배치될 수 있는 작업들을 해보았습니다.
지금처럼 만들어지는 콘텐츠를 한번 만들어 봅시다 하단에 있는 탭발을 한번 만들어 보려고 합니다.
태안 같은 경우에는 콘텐츠에 따라서 내용이 바뀔 수 있으니까 일단은 가로로 배치되니까 뭐다 리스 클래스를 씁니다.
그리고 콘텐츠들은 여기 보시면 서로 높이에 따라가지고 콘텐츠들이
크기가 커지겠죠. 그래서 부모의 콘텐츠를 따라가야 되기 때문에 ali 아이템 중에 스트래치를 적어주겠습니다.
그리고 각 요소들 맞다 위치와 동일하겠죠.
그래서 플렉스 아이템에는 모든 자식의 드노드를 전부 다 플렉스 1을 걸어주겠습니다.
그러면 콘텐츠가 배치될 때마다 짠짠짠 이런 식으로 배치가 될 거예요.
이게 아니면 플렉스 아이템의 플렉스 2를 걸어주시면 되겠습니 그리고 각 아이템의 콘텐츠들은 새로로 배치되어 있죠 좋습니다.
그래서 v 박스를 선택해서 플렉스를 적어주시고 플렉스 플로우를 코 로글럼이라고 적어주겠습니다.
둘 다 전부 다 가운데 배치되어 있죠 그래서 온라인 아이템 센터
저스티파이 클레스 센터를 적어주시고 간격은 얼마죠 한 8000 정도 띄워드리고 휴대폰도 작업 주시고 아무 이미지 작업하면 짜장을 하고 우리가 원하는 토파들이 완장이 됩니다.
목사를 해서 빠빠빡 하면 우리가 원하는 스텝바가 만들어졌습니다.
Modal Dailog 만들기
(샘플 디자인)
(샘플 코드)
모델 박스를 만들어 봅시다 가운데 정렬을 하기 위해서는 디스플레이 플렉스를 써주시고요 그건 말 그대로 가운데 정결하기 위해서 라인 아이템즈 센터 서비스를
적어주시면 되겠습니다. 이때 가운데 정렬을 하기 위해서 mrgin을 쓰는 건 어떠신가요라고 얘기하지만 아까 얘기했지만 콘텐츠에다가 마진을 집어넣어서 정렬을 하는 방식은 아이템에 항상 많이 들어가기 때문에 좋지 않습니다.
그래서 한쪽이면 그게 잘못됐다가 아니라 그냥 하나의 방식으로 가능한 게 있다면 그 방식으로 작업을 해보시는 게 좋지 않나라고 생각을 합니다.
그래서 지금처럼 작업을 해주시면 될 것 같고요 모다 박스를 만들고 모다 박스를 만들려면 또 술로 하고 다 알아야 되잖아요.
모다 박스를 만들어 봅시다 모다 박스는 이렇게 생겼고요 밑에 부터가 있네요.
부터를 작업하고 그 대신 가운데 공간은 부터는 항상 밑으로 가야 되겠죠.
그래서 헤더를 이렇게 만들고 가운데 역은 가변의 크기로 변해야 되니까 플렉스를 걸어주겠습니다.
그리고 fter의 영역은 hit가 고정이 됐니까 hit 고정을 잡아주시고 버튼이 오른쪽으로 배치되어 있네요.
그래서 aria td
라인 아이템들을 센터로 잡아주시고 저스티파이 콘텐츠를 밴드로 잡아주시면 오른쪽으로 가게 될 겁니다.
그리고 패딩을 잡아주시고 간격을 적당히 잡아주시면 일단 이런 식으로 우리가 원하는 모델 팝업을 만들 수 있게 되었습니다.
Tabbar 만들기
(샘플 디자인)
(샘플 코드)
지금처럼 보이는 트위터 화면을 잡아봅시다 일단 콘텐츠가 가로로 배치되어 있네요.
그래서 플렉스 디스플레이 플렉스를 걸어주시고 전반적으로 정렬이 강제되어 있는 거 보니까 라인 아이템즈 센터를 잡아주시면 될 것 같습니다.
그런데 이 콘텐츠는 차로로 커지게 될 것 같죠.
그래서 이것만 작업하기 위해서 이 아이템즈의 라인 아트 샘플을 걸어서 탑으로 올려 올리겠다.
나머지 패딩 정리하고 에 갭 정리하고 나머지는 그걸 자른하고 정리를 하면 블랙스 파크 완성
예 이런 식으로 플레이스 박스를 디스플레이 값으로 걸고 라이언스를 정하고 이 컨텐츠를 넣 방향을 정하고 anlin rate를 정하고 tspy cont츠를 정한 다음에 padding을 정하고 tv을 정한 다음에 마무리 어렵지 않죠.
이것들만 정해서 작업하는 것들이 대부분입니다.
그리고 레스티드하게 걸리는 경우는 플렉시가 걸린다라고 보시면 될 것 같고요
순서는 플렉스가 먼저고 그게 헷갈려 있습니다.
헷갈리지 않습니다. 그리고 디스플레이 플렉스 라인 아이템즈 st바이 콘텐츠
이런 식으로 작업을 하시면 되겠습니다.
스크롤 스냅과 flexbox를 이용해서 케로셀을 만들어보자.
풀 화면을 써서 만들어내는 특수한 경우에 어떤 레이아웃이 있을 때 이렇게 쓸 수 있을 것 같고요 일반적인 경우에서는 찾아보기는 힘들다 하지만 필요하면 써야 된다 그다음에 플러스 박스와 민 위드 그리고 스프로스네을 이용해서 만드는 캐로셀 같은 게 있을 수 있습니다.
이거는 이제 적절히 css를 섞어서 만드는 캐로셀을 만드는 방법인 거고요
보시다시피 플렉스 박스로 방향 걸어놓고 내가 여기 위드를 안 되게 되면 콘텐츠가 벗어날 수 없겠지만 그래 크를 영어로 바로 두고 이들을 100%를 하게 되면 이런 식으로 콘텐츠마다 사이즈가 넘어갈 수 있고 여기에 스크롤을 걸 수가 있게 됩니다.
그래서 이 scrol을 건 상태에서 skrl de 걸어주시고 그 때의 content 위치를 start 혹은 센터로 맞춰주시면 지금처럼 별다른
자바스크립트 없이 해당 기능을 구현할 수가 있게 됩니다.
퍼포먼스는 네이티브 앱 스크롤을 따르고 있기 때문에 굉장히 퍼포먼스가 좋고요 그래서 간단한 캐로셀은 이런 식으로 작업을 하시면 되겠습니다.
flexbox 복습 및 정리
한번 플렉스 박스에 대한 어떤 내용들 다시 한번 복습해 보겠습니다.
플렉스 박스는 가로를 넣는다 세로를 넣는다 배치가 중요하고요 이 한번 배치를 했을 때 내가 바라보는 가로 방향에서는 위아래 세로 방향에서는 좌우를 먼저 결정을 한다 그리고 콘텐츠들이 여러 개가 있을 때 어느 쪽으로 몰아둘지 내가 벌려둘지 좁혀놓지 가운데 놓을지 등을 정할 수가 있다.
이렇게 콘텐츠 배치의 어떤 특성이 끝나고 나면 세부적인 디테일을 잡게 되는데 여백의 패딩을 잡고 사이에 간격을 잡게 된다.
대부분의 디자인은 간격을 동일하게 만들려고 하기 때문에 사실 크게 문제가 되지 않겠지만 특별한 경우 그 사이에 간격을 조금 더 벌려야 될 경우에는 그 그룹을 묶어서 서브 플렉스라는 박스를 이용해서 간격을 벌릴 수가 있게
이 내부 콘텐츠의 크기는 세 가지 종류로 나뉘는데 하나는 첫 번째는 콘텐츠가 콘텐츠의 내부 콘텐츠에 따라서 움직이는 경우가 생기고 두 번째는 콘텐츠의 고현택 크기 두 번째는 콘텐츠에 콘텐츠가 남는 공간에 따라서 부모의 크기에 남는 공간에 따라서 여백을 줄 수 있는 어떤 플렉스라는 방식이 존재한다 이때 콘텐츠 따라 가고 싶은데
서지 따라 바꾸고 싶은데 강제로 들려보는 경우가 있으니 플렉스 0으로 세팅하는 게 좋다.
플렉스 0을 디폴트로 세팅하는 게 나쁘지 않다.
좋다라고 할 수 없습니다. 이건 저만의 방법이니까요.
그리고
그래서 일반적으로 보고 그에는 플렉스 박스에서는 적어도 플렉스 한 애들이 하나 정도는 있는 게 좋다.
그게 맨 마지막이라면 굳이 넣을 필요는 없습니다.
그래서 예시를 들었을 때 출발을 만든다고 생각하면 h 박스입니까 h 박스니까 디스플레이 플렉스를 걸고 하운드 열니까 언라인하트 센터를 건 다음에 각각의 paddi은 얼마 간격은 얼마 이렇게 작업을 하시고 내가 콘텐츠가 가별에 따라서 조정되는 부분에 따라서
구정될 부분 가변으로 변할 부분을 정한 다음에 가변으로 변하는 부분에다가 스펙스를 두든 콘텐츠로 두든 스펙스하게 걸어두시면 앱 레이아웃은 굉장히 간단하게 만들 수 있습니다.
다음 장에서는 이 플렉스 박스를 이용해서 앱 ui에서 가장 보편적으로 쓰이는 컴포넌트 한 20가지 정도를 한번 예제를 통해서 개발해보는 시간을 가져보겠습니다.
그래서 어떤 식으로 접근을 하고 어떤 식으로 잘라서 어떤 식으로 복제를 하고 있는지 한번 같이 들어보시면서
작업을 해보시면 될 것 같아요. 여기까지 css 레이아웃에 꽃 붙인 클래스 박스에 대해서 한번 알아봤습니다.
플렉스 박스만 이해하고 있으면 css에 대해서 어려운 부분들은 대부분 다 거의 끝납니다.
그리고 어려워지는 거는 플렉스 박스 안에 플렉스 박스 안에 플렉스 박스가 있는 경우고 특별한 거 온라인 아이템이지도 않았구나 세이프 온라인 온라인 셀프도 해야 되네
그러한 굉장히 예외적인 케이스가 존재하는데 사실 그런 것들은 굉장히 드물다 그래서 그렇죠 그냥 열심히 빨리빨리 만들어 보면서 숙자를 내는 게 굉장히 중요합니다.
그래서 나만의 지금 제가 알려드린 내용을 방식으로 나만의 도티 나만의 방식을 찾아내서 빨리빨리 속단할 수 있는 게 중요하다라고 생각을 합니다.
이론적인 깊이 중요하지 않다라고 말씀드렸고요
이런 식으로 조금 작업을 해보면서 약간 불편한 부분 약간 좀 괜찮은 부분들이 있을 때는 과감하게 작업을 교체하는 방법들 찾아보시길 추천을 드립니다.
5장. Flexbox - 고급편
지금까지 플렉스 박스 핵심 편을 알아봤습니다.
이제 플렉스 박스 고급편에 대해서 알아볼 건데요.
플렉스 박스 고급이라고 하면 그만큼 사실 경우 의수가 별로 많지 않다라는 거기 때문에 이런 상황에서 이런 게 쓰는구나 정도만 이해를 하시고 넘어가시면 될 것 같습니다.
고급이라고 쓰고 특수한 경우라고 읽는다.
고급이라고 표현하면 안 되겠다. 굉장히 특수한 경우에 속합니다.
그래서 이렇게 특수한 경우는 따로 뒷장에 다 몰아서 다 몰아놓을 거고요
이런 것들을 알면 도움이 되지만 몰라도 크게 상관이 없는 이 정도의 느낌이기 때문에 이게 괜히 어렵게 설명을 해서 이게 마치 어렵게 설명을 하게 되면 중요한 것처럼 느껴져서 쓸데없는데 시간을 많이 투자하는 것들을 막아 막기를 바라요 하지만 모르고 있으면 내가 알고 있다는 것도 모르기 때문에 이거를 안 써야 되기 때문에 가르쳐드리는 거다.
라고 해서 뒤에 브록으로 브록의 느낌으로 고급 파트를 따로 정리를 해봤습니다.
어렵다는 얘기는 그만큼 쓸 기회가 적다는 것을 의미한다!
그래서 여기서는 이런 것들을 이런 기초만 확실하게 알고 숙달이 되는 것이 가장 중요합니다.
그래서 실전에서는 어떤 감각으로 써야 되느냐 실제로 에서는 이 플렉스 박스를 다 타이핑하면서 일일이 타이핑해서 가기에는 너무너무 힘든 작업이죠.
그렇기 때문에
사실 여러 가지 어떤 해법들이 나오고 있습니다.
여러 가지 라이브러리들이 존재하고 클래스들이 존재를 하지만
이것들의 선택 쓸지 말지의 선택은 본인의 문제이기 때문에 어떠한 방향성이 있는지 정도만 설명을 좀 드리려고 합니다.
기본은 기본은 이렇게 쓴다고 알고 있다는 것 그리고 실전에서는 이런 것들을 잘 쓸 수 있는 라이브러리를 쓴다는 것 하지만 라이브러리는 취향이자 선택의 문제이기 때문에 뭐를 지정해 줄 수는 없는 부분 그래서 스타일 박스에서는
그래서 저는 이러한 유틸리티를 만들어서 사용하고 있고요 가로로 만드는 박스를 h 박스 그리고 세로로 만드는 박스를 v박스 그리고 가로는 라인 센터가 기준 그리고 새로는 라인 스트레치가 기준으로 해서 nom flow랑 비슷한 형태를
형태로 만들 수 있도록 작업을 했고요 여러 가지 유틸리티 클래스들을 만들어서 직접 작업을 하는 방식으로 작업을 하고 있습니다.
이렇게 하면 굉장히 빠른 속도로 화면을 만들어낼 수가 있어요.
그게 아니라면 차크라 ui나 스타트 컴포넌트나
컨텐츠도 줄바꿈을 해보자! flex-wrap
플렉스 랩이랑 그다음에 리버스가 있습니다.
사실 이 두 개이 또 굉장히 특수한 케이스가 아니고서는 잘 쓰지 않는데요.
pleas rap 같은 경우에는 이제 콘텐츠가 풀어졌을 때 밑으로 떨어뜨리게 해서 약간 그리드와 같은 형태로 보여줄 수 있도록 해주는 콘텐츠 요소입니다.
이때 정렬을 하고 싶을 때는 묶음들에 대해서 나머지 요구 처리하는 부분에 대해서 온라인 콘텐츠라든지 아니면 after를 이용하는 방식이 있고요 사실은 이렇게 만들어내는 것보다 그리드를 사용해서 만드는 게 훨씬 더 좋기 때문에 이런 케이스에 대해서는 플렉스 랩이라는 게
있다는 걸 알고 우리가 간단하게 쓸 수는 있지만 가급적 이러한 디자인을 만들 때는 플렉스보다는 그리드를 사용하시는 것을 추천을 드립니다.
그 그리드라는 어떤 스펙은 아이 101에서 제대로 동작하지 않았던 문제가 있었고 빨던 문제가 있었기 때문에 사람들이 좀 깊이 하던 부분이랑 그리고 그리드라는 부분들을 프레스 랩으로 많이 사용을 했었지만 그리드
스펙도 이제는 아예 없어질 거기 때문에 그리드 스펙은 기본적인 스펙이 될 거라서 그리드 한 부분들은 확실하게 그리드하게 하지만 대부분의 레이아웃은 플렉스하게 이렇게 작업을 하시는 게 좋다라고 생각을 해 주시면 될 것 같습니다.
그래서 플렉스 랩이라는 게 존재한다 그리고 플렉스 랩도 plas rap도 reves라는 게 존재한다 rebs 같은 경우에는 건들 보고 위로 올라갈 수 있게 보일 수 있다.
사실 이러한 예시들은
flex-flow에 wrap을 추가할 수 있다.
flex-wrap 전용 배치 align-content
flex-wrap이 되어 있으면 컨텐츠간 정렬을 해야하는 방식이 필요해집니다. align-items와 헷갈릴 수가 있는데 justiy-content에서 왜 content라고 이름 붙였는지 생각해보자!
(그림으로 컨텐츠 사이의 간격을 표기 해주자!)
이러한 정렬을 하기 위해서 align-content 스펙은 다음과 같은 경우의 수를 가집니다.
(스펙과 배치 이미지 나열)
자주 사용되지는 않고 특수한 경우가 아니라면 grid layout을 통해서 해당 배치를 만들어 낼 수 있다. 물론 목적인 다르기 때문에 알고는 있어야 한다.
grid vs flexbox-wrap
미묘하게 서로가 유리한 조건이 다르다. 특히 반응형을 처리해야할 때. 컨텐츠의 크기가 제각각인 경우라면 flexbox로 해야하고 컨텐츠의 크기 (정확히 말하자면 레이아웃의 격자)가 균든하면 grid가 훨씬 더 유연하다. 해당 방식의 차이는 7장 grid 편 에서 다시 다루도록 하겠습니다.
HTML 수정 없이 순서를 바꿀수 있다. order!
order 같은 경우에는 콘텐츠의 순서를 바꿀 수 있게 됩니다.
대부분의 경우에는 콘텐츠 순서는 콘텐츠의 html 구조에 따라서 만들어지기 때문에 이 오더를 직접적으로 쓰는 경우는 굉장히 드뭅니다.
그러면 이 오더가 언제 유용할까요. 이 오더는 이제 구조를 건들지 않고 레이아웃상 반응형으로 변경을 했을 때 혹은 특이한 상황에서 이제 순서를 변경해야 될 때 사용한다라고 보시면 될 것 같습니다.
그래서 내가 데스크톱 화면일 때는 이렇게 배치되어 있던 것들이 모바일에서는 조금 더 이미지가 먼저 다르게 배치됐으면 좋겠다.
라고 판단을 하거나 혹은 어떠한 옵션을 눌러서 클래스 상황이 다른 클래스가 되었을 때 이거 순서를 바꿔서 표시를 하고 싶다.
카드 뷰라고 되어 있는 상태에서 목록들로 바꿀 때 이러한 콘텐츠가 먼저 나오는 게 좀 더 괜찮은 것 같다.
이러한 컨셉을 있을 때 이 오더라는 것을 사용하게 됩니다.
그래서 반응형이나 아니면 조건부 랜더링에서 이 오더를 사용하시면 좋다라고 말씀드릴 수 있을 것 같아요.
NOTE: order:-1
order는 음수도 가능하다
특정 조건에 맞는 정렬을 하는 방식으로도 사용이 가능하다! 특정 상황일때 이 컨텐츠만 맨위로 보이게 하기.
flex-shrink와 말줄임...
ㅌㅌㅌㅌㅌㅌㅌㅌ
두 번째는 플렉스 시링크입니다.
사실 플렉스 슈링크 같은 경우에는 안 쓰시는 거를 추천을 드립니다.
안 쓴다라기보다는 플렉스 슈링크를 디폴트는 1로 되어 있어요.
그래서 플렉스 박스를 쓰시면은 이 플렉스 영역을 벗어나지 않도록 해주는 식으로 디자인을 작업을 하고 있습니다.
이 경우 문제가 뭐냐면 내가
콘텐츠의 어떤 크기를 내가 지정을 해놨는데 강제로 이 콘텐츠가 줄어지는 경우를 볼 수 있게 됩니다.
그래서 내가 의도하지 않았는데 콘텐츠가 줄어 보이는 현상이 발생할 수 있기 때문에 가급적 모든 플렉스 박스 영역에 hit를 0으로 두시고 기본적으로 작업을
하시면 좀 더 플렉스 하나만 가지고 작업을 할 수 있기 때문에 굉장히 편해집니다.
그러면 반대로 이 0으로 세팅했을 때 문제가 되는 케이스는 뭘까요.
문제가 되는 케이스는 플렉스 시링크라는 거는 내가 어떤 콘텐츠가 콘텐츠 영역을 벗어났을 때 어떻게 얘를 다룰 것인가라는 어떤 개념이에요.
그래서 의경우에서는
내가 일부러 줄여야 되는 경우 일부러 줄여서 화면에 보여줘야 되는 경우 콘텐츠가 오 플로우가 됐을 때 줄여서 보여줘야 되는 경우는 바로 이 말 줄임에 있습니다.
앞에서 보던 이전에서 배웠던 어떤 콘텐츠가 오버플로우 되었을 때 이렇게 말조림을 넣게 되면 콘텐츠를 강제로 줄여서 보여줘야 되는 경우가 생깁니다.
그래서 이 말주 효과가 날 수 있게 하기 위해서는 이런 식으로
플렉스 시링트 1을 따로 넣어주시는 방법을 추천을 드립니다.
이렇게 작업을 하시면 갑자기 내가 어느 상황에 대해서 콘텐츠가 갑자기 좁아지거나 아니면은 콘텐츠 위드가 약간 정해져 있는 상태에서 콘텐츠를 따라가지 않고 이미지를 줄여버리는 그런 상황을 미연에 방지할 수 있기 때문에 작업을 하셔도 됩니다.
나는 이 방식이 싫다
이 방식은 보편적이지 않은 것 같아요라고 하시는 분들은 반대로 이미지라든지 동적인 콘텐츠에 대해서 되게 뭔가 의도치 않은 콘텐츠가 줄어들었을 때 플래시 시크 0을 그때그때 걸어주시면
flex-basis
https://css-tricks.com/understanding-flex-grow-flex-shrink-and-flex-basis/
된다고 생각을 합니다. 세 번째 플렉스 베이시스 플렉시 베이시스는 사실상 거의 사용되지 않는 않는 겁니다.
왜냐하면 플렉스 베이시스의 어떤 역할을 위드가 충분히 수행을 하기 때문이죠.
위드가 있고 플렉스 베이시스가 있을 경우에는 플렉스 베이시스가 위드를 덮어 쓰는 현상을 발생하게 됩니다.
그래서 이러한 것을 응용할 수 있는 부분이 딱히 있지는 않은 것 같아요.
제가 위드가 정해진 상태에서 플렉스 박스에 들어 있을 때는 콘텐츠를 늘려서 보여주고 그렇지 않을 경우에는 콘텐츠를 다르게 보여준다 이 정도의 어떤 상황이 있을 것 같은데 사실 이런 상황이 현실 세계에서 그렇게 자주 발생하는 건 아닙니다.
그냥 이론적으로 플렉스 베이시스가 위드의 속성을 덧붙일 수 있다.
하지만
자체적으로 가지고 있는 max wid나 minid를 이길 수는 없다라고 생각을 해주시면 될 것 같고요 사실상 거의 쓰이지 않는 스펙입니다.
모든 스펙들이 골고루 쓰이지 않는다. 많이 쓰는 것 위주로 간단하게 쓰자.
플렉스 박스는
초기 설계를 할 때에는 이제 여러 가지 것들을 많이 시행착오를 겪었고 중간에 한번 스펙이 부러진 적도 있습니다.
그리고 나왔던 스펙들 중에서도 굉장히 많은 게 있잖아 많은 게 있으나 실질적으로 충분히 검증이 되고 나면서 여기서 꼭 필요한 것들 중요한 것들은 이런 식으로 쓰면 좋다라는 어떤 내용들이 정리가 되었어요.
그 정리에 대한 어떤 결과물이 여러분들이 보고 있는 fig mi의 오토레이어
그렇기 때문에 플렉스에 대해 플렉스 박스에 대해서 굉장히 이론도 많고 복잡하게 설명하는 부분도 많겠지만 결국은 가장 간단하게 내가 직관적으로 이 화면을 어떻게 구성을 하면 좋을지를 생각을 하시고 최소한의 노력으로 최소한의 이해로 최소한의 타이핑으로 작업을 할 수 있는 방법을 생각하시면 될 것 같고요 쉽다고 해서
절대로 나쁜 게 아니다. 어렵다고 해서 공부를 해야 될 거고 자주 뭐지 고급진 기법이 되는 게 아니다.
tss는 그죠 잘 놓고 잘 그리스만 쓰면 된다 요 마인드를 잊지 마시고
유틸리티 클래스 사용해보기
(유틸리티 클래스 방법에 대한 설명은 앞 장에서 이미 언급을 했을 것)
두 번째 해야 되는 작업 utlit 클래스를 활용하는 방식입니다.
생각보다 이러한 작업들은 굉장히 빈도가 높고 대규모 콤포넌트 같은 경우에는 컴포넌트에서 담동을 처리할 수 있기 때문에 이러한 레이아웃을 관리하는 유틸리티 클래스를 만들어주면 굉장히 유용하게 작업을 할 수가 있습니다.
유틸리티 클래스를 사용해보자. tailwindCSS, AdorableCSS
해 주시면 좋을 것 같습니다.
유틸리티 클래스에 대해서는
배포 배포의 라이브러리 배포의 문제 css
사이드 판 포인트
이렇게 유틸리티하게 생각해 주시는 거는 굉장히 개발을 할 때 상당히 유용한 개념을 줍니다.
모든 것을 처음부터 이렇게 빌드를 해오기 시작하면 실전에서 생각보다 그런 효율을 낼 수가 없어요.
그렇다고 해서
그렇기 때문에 이렇게 유틸리티한 클래스 한 방법을 쓰시는 것들은 추천을 드립니다.
이거는 css를 잘 이용하는 방식이에요.
그래서 h 박스라든지 v박스라든지 갭이라든지 이러한 속성을 통해서 작업을 하신다면 훨씬 더 편하게 작업을 하실 수 있다라는 내용을 알려드리고 콘텐츠의 배치를 쉽게 확인하는 방법은 이제 아웃라인을 통해서 가이드를 만들게 되면
이런 식으로 레이아웃을 편하게 확인하실 수가 있습니다.
그래서 이러한 유틸리티 css도 만들어 주시면 내가 플렉스 박스에서 내가 원하는 형태로 잘 배치를 했는지 이해를 하실 수 있게 되기 때문에 이거를 같이 한번 적용을 해보시면 좋을 것 같습니다.
그래서 최종 정리를 해보겠습니다. 플렉스 박스는 애플리케이션 레이아웃을 하기 위해서 태어났다 이 애플리케이션 레이아웃의 가장 중요한 점은 역시 가로로 배치한다는 거죠.
그 콘텐츠가 있고 이 콘텐츠가 내 문화가 있을 때 각각을 어떻게 자유 자유 자재로 배치할 것이며
이 콘텐츠에 대한 어떤 배치에 대한 위치라든지 정렬 방법이라든지 중간에 남아 있는 간격이나 비어 있는 간격을 어떻게 처리할 것인지 그리고 콘텐츠가 구공의 콘텐츠가 바뀌었을 때 반응형으로 어떻게 반응을 하게 할 것인지 이 모든 것을 고려해서 만든 콘텐츠이다.
그래서 안드로이드의 라인업 그래서 방향을 정하고 거기에 콘텐츠를 어떻게 배치하고 정리를 하고 간격을 어떻게 만들 것인지에 대해서 접근을 하면 하기 위해서 만들어진 방법입니다.
그리고 대부분이 css만 가지고 작업을 해야 되는 경우가 별로 없기 때문에 css를 이용해서 반응형으로 작업하기 위해서는 이제 클래스를 만들어야 되는 경우도 생기겠지만 대부분의 경우 그 정도까지는 아니기 때문에 클래스를 다이팩터로 바로 작업을 하게 되면 그 구조를 통해가지고 빠르게 작업을 할 수 있기 때문에 트리티 클래스는 현재
적용하는 가장 좋은 방법입니다. 그중에서 가장 유명한 테르윈드 클래스를 쓸 거고요 제가 개발하고 있는 어드로버 css를 써서 같이 한번 작업을 해보도록 하겠습니다.
아까랑 똑같죠. 모다 커브를 만들겠습니다.
그래서 전체적으로 클래스를 걸고요 라인 아이템 센터를 해가지고 직접 바이컨테스 잡아준 다음에 패딩을 얼마나 고 배분을 얼마나 넣으면 세트는 사고가 해성이 됩니다.
똑같은 방법으로
앞서 실습한 내용중 1~2개를 유틸리티 클래스 기반으로 만들어보기
제가 만들었던 오도로브 c세스에서 작업을 한다면 지 v박스 2개 방향을 정할 수가 있고요 그 안에서 어느 방향을 정할지 한 라이트를 섞어서 작업을 할 수 있게 되고요 여기에 패딩 넣고 넣고 마무리 중간 사이 갭을 다르게 넣고 싶으면은 서브 박스를 이용해서 제가 갭을 이용해서 충분히 원하는 만큼의 작업을 할 수 있게 됩니다.
이렇게 해서 그리스 박스 실전 작업이랑 내용을 알아봤고요 그래서 이런 것들이 2단계 3단계 4단계 들어가면 굉장히 복잡해진다.
그래도 별로 어렵지 않다. 그리고 내부 차일드의 콘텐츠에 대해서는 이제 스트레치와 그다음에 플렉스의 어떤 차이만 고민을 하신다면 잘 모르겠다면 그대로 쓰시면 되니까 이 두 개만 잘 생각을 해서 필요할 때만 하나씩 하나씩 넣으면 된다
나머지 플렉스 박스에 대해서는 이거에 어떤 이해를 하고 나면 나머지 복잡한 플렉스 박스에 대한 어떤 이론들도 필요에 따라 이해하게 되실 겁니다.
사실 그리고 더 이상의 깊이가 필요 없기도 하고요 그래서 프레스박스는 이렇게 이해를 하시면 되고 나머지 복잡한 부분에 대해서는 으셔도 괜찮다라는 말씀 드리면서 오늘 플래시 박스 강의 영상 여기서 마치도록 하겠습니다.
어렵지 않았죠.
tailwindCSS로 구현해보기,
(샘플 화면)
(예시 코드)
AdorableCSS로 구현해보기
(샘플 화면)
(예시 코드)
CSS 최적화
... SideNav
창 크기를 조절(파란색 border)할 때 하드웨어 가속을 위해 transform을 사용하고 싶었지만, SideNav
를 collapse를 하면, Contents
부분이 전체 영역을 차지할 수 없게됩니다. 그래서 창크기 조절을 할 때마다 flex-basis
를 줄이고 늘리는 식으로 사용했습니다. transform을 사용하는 방법은 없을까요??
... SideNav
창 크기를 조절(파란색 border)할 때 하드웨어 가속을 위해 transform을 사용하고 싶었지만, SideNav
를 collapse를 하면, Contents
부분이 전체 영역을 차지할 수 없게됩니다. 그래서 창크기 조절을 할 때마다 flex-basis
를 줄이고 늘리는 식으로 사용했습니다. transform을 사용하는 방법은 없을까요??
블로그 소재를 제공해준 홀리몰리에게 다시 한번 감사드립니다.
해당 질문에 대한 대답은 이러했습니다.
왜 trasform으로 바꿔보고 싶어 하는지는 알 것 같아요. 하지만 trasform으로는 레이아웃을 변경할 수 없어요.
질문에 언급된 하드웨어 가속 에 대한 개념과 함께 Critical rendering path
, reflow
, repaint
와 같은 CSS 에니메이션 최적화에 대한 얘기를 해보면 좋을 것 같아 이 글을 쓰게 되었습니다.
프롤로그
CSS 에니메이션을 공부하다 보면 하드웨어 가속이나 렌더링 최적화에 대한 글을 접하게 되고 transform으로 에니메이션을 만들어야 가장 빠르다 라는 얘기를 종종 듣게 됩니다.
그래서 내가 만들고자 하는 에니메이션을 어떻게 transform으로 바꿔보려고 하지만 도저히 그렇게 되지 않는 경우가 만들어지곤 합니다.
그래서 한번 reflow, repaint, 하드웨어 가속등 CSS 에니메이션에 대한 이해를 한번 해보고 나면 왜 해당 에니메이션을 transform으로 만들 수 없는지 아시게 될 거에요.
이번 글에서는 CSS Animation에 대해 다음과 같은 이야기를 해볼까 합니다.
1) CSS 렌더링 최적화 (reflow vs repaint)
2) 하드웨어 가속
3) 실전에서 최적화를 위한 주의사항
⭐️ Critical rendering path
이렇듯 브라우저에서는 실제 코드 변경으로 인해 다시 화면이 변경이 되기까지간의 일련의 과정이 존재합니다. 이것을 Critical rendering path 라고 합니다.
이 과정을 세분화 해보면 아래 그림과 같습니다.
간단하게 정리하면 JS, CSS가 변경이 되면 그에 맞는 다시 레이아웃을 계산하고 레이어에 픽셀을 그린 후 조합해서 하나의 화면을 만들어 화면에 보여주는 과정을 통해서 변경된 화면을 우리가 볼 수 있게 됩니다.
DOM과 Style
출처: 구글: 모던 웹 브라우저 들여다보기 (파트 3) 꼭 읽어 보세요!
CSS Animation
우선 먼저 에니메이션에 대해서 생각을 해봅시다. 에니메이션이란 서로 다른 정지된 이미지를 일정시간 이하의 간격으로 빠르게 다시 그리면 움직이는 것처럼 보여지는 것을 말합니다.
다시말해 에니메이션이 제대로 동작하기 위해서는 빠른시간내에 다시 그리는 것이 중요합니다.
브라우저에서는 어떻게 하면 다른 이미지로 보여줄 수 있을까요? 간단합니다. 자바스크립트 코드에서 DOM을 조작하거나 스타일을 변경하게 되면 변경된 부분을 렌더링 엔진이 다시 그려주게 됩니다.
Reflow, Repaint
하지만 JS, CSS 변경이 되어도 이 모든 과정을 항상 거치는 것은 아닙니다. 화면을 다시 그린다는 것은 UI 프로그래밍 성능에 있어 가장 중요한 부분이기에 최대한 효율적으로 계산하여 적은 수의 변경을 만들어 내려고 하게 됩니다.
이미 그려져 있는 화면에서 Layout을 다시 하는 것을 Reflow
, 화면을 다시 그리는 것을 Repaint
, 각각 만들어진 레이어들을 하나의 이미지로 출력하는 과정을 Composite
라고 부릅니다.
가급적 이러한 단계를 생략할 수 있다면 좋겠죠? 그래서 여러가지의 렌더링 과정 중 Layout와 Paint의 과정을 생략할 수 있다면 훨씬 더 나은 성능을 보여줄 수 있게 됩니다.
⭐️ Reflow (= ReLayout)
웹 브라우저에서 inline과 block으로 인한 레이아웃을 normal-flow라고 합니다. reflow라는 용어는 이 flow를 다시한다는 데에서 유래했고 직관적으로는 레이아웃을 다시 잡는다고 보시면 됩니다.
브라우저의 DOM 요소들의 크기가 위치들은 상대적인 개념을 가지고 있습니다. 글자의 양에 따라 width와 height가 변경이 되고, 부모의 크기나 위치에 따라 내 위치가 결정이 됩니다. 또한 내 앞의 엘리먼트에 따라 위치가 가변적이죠.
이말은 곧 내 위치가 결정되기 위해서는 부모든 이전 노드의 위치가 필요하다는 의미입니다.
이러한 특성이 있기에 훨씬 더 UI 개발을 편하게 만들어 줍니다. 모든 것들이 절대 좌표였다면 컨텐츠를 삭제하고 추가할때마다 일일히 위치를 계산해줘야 할 것입니다. 이러한 부분들은 브라우저가 대신해주고 있죠.
Reflow가 느린 이유
DOM은 하나의 Layout이 결정되기 위해서는 선행되어야 하는 Layout이 존재해야 합니다. 바꿔 말하면 선행되는 Layout가 변경이 된다면 도미노 처럼 다음 레이아웃이 변경되고 또 그로인해 다음 Layout이 변경이 된다는 의미입니다.
예를들어 우리가 반응형을 만들때 root의 width가 변하면 연쇄적으로 다른 모든 레이아웃들이 변하고 있다는 것을 알고 있잖아요.
그렇기에 과도한 reflow가 발생하는 형태의 animation, 가령, width가 바뀐다거나 margin등이 변경이 되어 하나의 레이아웃의 변경이 미치는 파급력이 큰 경우 많은 양의 계산과 대규모의 화면 변환이 필요하기에 가급적 reflow가 발생하지 않도록 해야 합니다.
⭐️ Repaint
repaint는 다시 그렸을때 레이아웃의 변화가 없는 속성들입니다. 나만 다시 그리면 되니 상대적으로 속도가 적을 수 밖에 없습니다. 글자와 색깔, outline등이 포함됩니다. 도미노 효과가 없으므로 상대적으로 에니메이션 속도가 빠른 편에 속합니다.
어떻게 확인해야 할까?
margin이나 border, width등을 변경을 한다고 모든 지역을 다시 그리지는 않습니다. 브라우저에도 언제나 최적화 노력을 기울이고 있어요. 그러니 단순히 width, margin을 안 쓸게 아니라 확인을 해야 합니다.
크롬을 기준으로 한다면 콘솔 > 하단 패널 > 렌더링 탭 으로 들어가면 paint와 layout을 확인 할 수 있는 체크 버튼이 존재합니다.
에니메이션을 만들거나 DOM의 변화를 만들어낼 때 과도한 layout변경이 일어난다면 그렇게 하지 않기 위해서 구조를 변경할 필요가 있습니다.
하드웨어 가속
그러면 어떻게 하면 layout도 수정하지 않고 paint도 다시 하지 않는데 화면이 변경이 되는 에니메이션을 할 수 있을까요? 비밀은 렌더링의 마지막 과정의 Composition에 있습니다.
Composition은 레이어로 쪼개긴 픽셀 데이터를 순서대로 다시 그리면서 하나의 이미지 데이터 배치하는 작업을 말합니다.
엄밀하게는 아니지만 직관적으로 개념을 이해하기 위해서 opacity를 예를 들어 보겠습니다. 일단 우리는 Layout와 Paint를 통해 만들어진 이미지가 있습니다. 해당 이미지를 투명도를 조절하는 fade 에니메이션을 하고 싶어요.
그러면 우리는 배치를 할때 이미 그려놓은 원본픽셀 데이터에 각 필셀마다 opacity를 곱해버리기만 하면 원하는 불투명한 이미지를 만들어 내는 것을 상상할 수 있습니다.
이러한 경우에는 에니메이션 과정에서는 Paint의 동작이 필요없다는 것을 알게 됩니다. 원본데이터는 바뀌지 않았고 원본 데이터의 각 픽셀에 불투명도의 값만 다른 값을 곱해서 만들어 내되면 됩니다.
이렇게 원본픽셀 데이터의 일부 연산을 통하여 변환하는 것을 matrix multiplication
이라고 부르며 이러한 동작은 CPU가 아니라 GPU의 도움을 받을 수 있으므로 훨씬 더 빠른 속도(= 하드웨어 가속)로 장면을 만들 수 있게 됩니다.
GPU를 이용한 하드웨어 가속이 더 빠른 기술적인 이유
400x300 사이즈의 이미지를 불투명하게 만들기 위해서는 400x300의 연산이 필요합니다. cpu는 순차적인 방식으로 동작하도록 되어 있기에 이러한 연산은 120,000의 반복회수가 필요하게 됩니다. 하지만 각 이미지 픽셀 변환은 독립적인 동작이기에 순차적으로 진행할 필요가 없습니다. gpu의 경우에는 병렬로 처리해야할 연산들을 한번에 처리할 수 있습니다. 그렇기에 120,000이 아니라 1회에 모든 연산 결과를 출력할 수 있게 됩니다.
Why can GPU do matrix multiplication faster than CPU?
https://stackoverflow.com/questions/51344018/why-can-gpu-do-matrix-multiplication-faster-than-cpu
출처: https://developers.google.com/web/updates/2018/09/inside-browser-part1
원본이미지를 변형하는 방식인 translate, rotate, scle, skew, opacity, blur와 같은 filter 등만 하드웨어 가속이 가능하며 처음 질문을 했던 레이아웃을 조절하기 에니메이션 요구사항을 transform으로 해결할 수 있는가에 대한 대답은 No 입니다.
어떤 속성이 reflow, repaint, compoition을 만들어낼까?
브라우저마다 조금씩 달라서 잘 정리해둔 사이트를 공유합니다.
어떤 속성이 reflow, repaint, composition을 만들어 낼까?
https://csstriggers.com/
하지만 가독성이 좋은 자료는 아니라서 앞선 이론들을 통해 상식선으로 생각해주세요.
하지만 이 역시 브라우저와 상황에 따른 케바케이기 때문에 이러한 이론을 머리 속에 기억 해 둔채 실전 경험을 통해서 익혀두시길 바랍니다.
또한 opacity, transform, blur 등의 속성을 가지고 있으면 자동으로 하드웨어 가속을 받게 되는데 브라우저 렌더링 엔진은 하드웨어 가속을 받는 렌더링 엔진과 일반 렌더링 엔진 2가지로 분리가 되어 있습니다. 그래서 opacity: 1과 opacity: 0.99는 다른 식으로 동작하기도 합니다.
그래서 하드웨어 가속처리를 미리 해둬야 하는 경우에는 transform: translateZ(0.1px)
나 will-change: transform
과 같은 속성을 통해서 다른 렌더링 엔진을 통해 그려내기도 합니다.
[CSS] opacity는 reflow가 발생 안 한다구요...? 정말??
https://blinders.tistory.com/93
그러면 전부 하드웨어 가속을 받으면 좋지 않을까요?
당연히 아니겠죠? 여러가지 이유가 있지만 gpu의 하드웨어 가속을 받기 위해서는 해당 원본데이터를 메모리에 보관을 해두어야 합니다. 브라우저의 메모리 용량은 정해져 있기 때문에 남는 메모리의 용량이 적으면 스왑이 자주 발생하게 되면서 오히려 느려지는 경우가 발생을 하게 됩니다.
그리고 대부분의 경우 브라우저 자체에서 가능한 최적화가 될 수 있도록 하고 있습니다. 그러니 큰 문제가 없다면 그냥 놔두길 바랍니다. 애써 건드린다고 해서 더 드라마틱한 성능 개선을 기대하기는 힘듭니다.
그러면 will-change는 뭔가요?
will-change속성은 어떤 속성과 요소가 조작될 가능성이 있는지 브라우저에 미리 알려주는 방법입니다. 그러면 내부적으로 해당하는 요소에 대한 정보를 미리 메모리에 올려두는 등 브라우저에서 해당 속성을 통한 에니메이션 처리를 할기 위한 사전 작업을 미리하여 조금 더 부드럽게 에니메이션 처리를 할 수 있도록 해줍니다.
일부 특수한 경우를 제외하고는 많은 부분에 will-change를 거는 것은 위에서 모든 요소들에게 하드웨어 가속을 받도록 하는 것은 오히려 성능 저하를 일으킵니다.
제일 추천하는 방법은 CSS에서는 사용하지 않고 JS에서 에니메이션이 시작될때 will-change의 값을 지정했다가 animation이 끝나면 다시 auto로 돌려두는 것이 가장 좋습니다.
CSS will-change Property: When and When Not to Use It
https://www.digitalocean.com/community/tutorials/css-will-change
그래서 실전에서는 어떻게 하면 좋을까요?
그냥 하세요.
크게 생각을 하지 말고 에니메이션을 만듭시다. 브라우저도 최적화를 시도하기에 대부분은 크게 문제가 없습니다. 다만 absolute top, left이나 margin에 비해서 translate를 사용했을때 원하는 바가 같다면 translate를 사용해 주는 것이 좋겠죠
transform과 opacity를 이용할 수 있는 에니메니션을 대체한다.
1에서 성능 저하가 별로 없다면 굳이 더 나은 방법을 크게 고민하지 마세요. 하지만 정말로 성능 문제가 중요해지는 시점이 왔다면 머리를 싸매서 에니메이션을 바꿔 봅시다.
가령 width를 변경해야 한다면 윤곽선으로만 에니메이션을 처리하고 끝나는 시점에 width를 한번에 바꾸면서 fade in / out으로 에니메이션을 하는 착각을 주는 법도 있습니다.
가급적 레이아웃을 중간 과정 없이 그리도 proxy로 에니메이션을 대체하고 (윤곽선이나 반투명) 한번에 반영하는 형태
물론 디자이너와 합의를 통해서 설명을 드리면 멋진 결과물을 만들어 주실 거에요!
Javascript에서 Style 사용시 최적화 하기
보시라고 전문가의 쓰는 말을 한번 보시라고 적었고 자바스크립트랑 관계는 이제 몇 가지 있어요.
오프셋 위드나 오프셋 타이틀을 호출하게 되면 리플로우가 발생하거든요.
왜냐하면 이거를 하고 계산하기 위해서 자바스크립트가 리플로우를 강제로 발생시켜요 그래서 코드 상에서 얘를 쓰고
내가 위치 바꾸고 또 얘를 쓰고 위치 바꾸고 이런 거 하지 마라 이런 거 있는데 사실 그럴 일이 별로 없어서
네
그다음에 인라인 스타일을 호출할 때마다 리플로우가 발생하기 때문에 가급적 그냥 한 번에 몰아서 그러니까 점 스타일 뭐 뭐 어떻게 점 스타일은 뭐 어떻게 이렇게 되는 거 있잖아요.
그래서 그렇게 쓰지 말고 한 번에 보내라 리드 라이트는 안 하라 똑같은 얘기인데 이제 엘리먼트 한 개를 읽어오고
수정하고 그 다음 번에 엘리먼트를 위드를 읽어와서 거기서 플러스 100만큼 내가 바꾸겠다.
이거를 한 세 번 해버리면 이거 할 때마다 리플로우가 발생한다 했잖아요.
네 한 펑션에서 리프로를 10번 발생시킨단 말이에요.
네 그러지 말고 10개를 다 읽어오고 그다음에 스타일을 바꾸는 걸 한 번에 해라 이런 거고 리퀘스트 애니메이션 프레임 안 해서 다 그려라 이거 제가 나중에 예시는 또 최대한 모아볼게요
근데 찾으면 나올 거예요. 그러니까 이 용어만 알고 있으면 검색해보시면 워낙 많이 나오는 얘기라서 req스트 애니메이션 프레임 안에서 끝내라 그 일반적인 블록에서 하지 말고요 네 리퀘스트 애니메이션 펑션 안에서 블로그를 하게 되면 그 콜백이 다 끝나고 나면 한 번에 반영해 주거든요.
네
이해되시나요. 모르겠는데 내가 자바스크립트에서 뭔가 이런 거 하지 말라는 건데 이런 코를 내가 하잖아요.
하잖아요. 네 이게 그냥 노멀 펑션 콜에서 하게 되면 이거 하나하나하나에 다 반응을 하거든요.
네 리퀘스트 애니메이션 프레임을 걸고 위에다 여기 위에다가 안에 걸면 한 프레임 뒤에 해주긴 하는데 여기 있는 동작을 다 끝내고 해줍니다.
네 그래서 훨씬 빠르다 근데 이게 다 보통 프레머커 다시 다 해주고 있죠 요새 그래서 내가 뭐 굳이 이걸 안 생각해도
프레임 워크에서 해줘요. 웬만하면 타 리액트 가 다시 그릴 때도 다 리퀘스트 애니메이션 프리 안에서 그리고 있고 이렇게 해서 괜히 프레임 나누지 않으셔도 되는데 내가 바닐라를 해야 된다거나 아니면 알고 계시면 이런 것들이 이용할 수 있겠죠.
네
will-change는요?
그래서 윌 체인지 체인지 같은 경우에는 진짜 내가 애니메이션이 되게 중요한 거 슬라이드 쇼나 드로그 랩이라든지 이렇게 되게 큰 거 있잖아요.
이런 거
네
액션 시트 모바일에서 이렇게 위에 올라오는 거 이런 거 이 정도급이 아니면 가급적 안 쓰셔도 됩니다.
왜냐하면 이게 메모를 쓴다고 그랬잖아요.
쓰면 목 안에 두고 있는데 크롬도 그렇고 가끔씩 이거 많이 쓰면 죽어요.
앱이 알 수 없는 이유로 튕겼습니다.
이런 거 뜨거든요. 되게 안 좋은 경험이라서 그러니까 그거에 목숨 걸지 않았으면 좋겠다.
그러니까 이게 문제다 싶으면 아까 말씀드렸지만 약간 아까 이런 거 이런 식으로 좀 생각해 보시면 좋을 거예요.
네
그리고 그래서 하드웨어 관련된 밑에 질문도 있었는데 대충 이 정도면 충분히 이해하셨을 거라 생각하고
네
bm에서는 어떻게 하면 좋나요라고 했는데 뭐 사실 크게 상관없는 것 같아요.
상관없는데 지금 짜시는 거 코드도 지금 제가 코드를 기여이 pc에 넣는데 코드를 봤을 때는
네
한 파일에 컴포인트가 너무 많거든요.
물론 이제 그게 네 그렇게 해서 되겠습니다.
그러니까 실제로 그게 아닌데 제가 보여주려고 한 파일을 다 몰아서 했을 수도 있는데 어쨌든 보내주신 예시에서는
네
한 파일에 컴포넌트가 너무 많았어요.
아 네
보통은 요새는 거의 1 대 1 그러니까 외부로 노출되는 익스포트 한 거 있잖아요.
네
한 파일 당 익스포트 되는 컴포넌트는 한 개
그래야 css도 어차피 뭐 블록 단위로 하는 게 아니고 그러면 자연스럽게 css도 그냥 한 블록으로 쪼개질 거예요.
네
귀찮긴 하죠. 그러니까 이런 게 싫으니까 사람들이 이제 스타일더 컴포터 같은 거 쓰려고 하는 거고 어떻에 쓰려고 하는 거고 근데 어쨌든 가급적이면 하나면 좋을 것 같고요
네
제가 봤는데 반응형 같은 경우에 반정엽 같은 경우에 이런 거 있으면 네 장을 만드셔서 잉쿨루더 같은 걸로 해놓으시면 편하실 거예요.
나중에 바꾸기도 하네 해 주실 거라고 생각을 하고 있습니다 라이브러리도 많던데 이런 걸 좀 주시면
것 같았고요 bm이랑 css 묘들이 지금 시각으로 봤을 때는 조금 낡은 방법이기는 해요.
저게 또 낡은 게 낡은 것도 2018년 2018년 정도 기준에서는 괜찮은 거여서
네 2017
사실 몇 년 안 지났거든요. 이게 최신이었던 시기가 세상이 너무 빨리 변하는 것 같아요.
그래서 당장 가 바꾸라 이건 아니고 그냥 그래도 이제 한 5년 정도 지났으니까 한번 알고 계시면 해보시면 좋겠다.
https://www.digitalocean.com/community/tutorials/css-will-change
감사합니다.
완성도가 없는 글인데도 혹시 여기까지 읽어주셨다면 너무 너무 감사드립니다. 완성되지 않은채로 블로그에 올리는 일은 없었으면 했지만 여기에서 올린 글은 당분간은 완성도를 올리는게 너무 하기 싫을 것 같아요. 😅
그래도 현재 CSS Framework을 만들고 홍보(?)를 하고 있으므로 CSS와 관련된 주요한 포스팅과 내용들인 flexbox나 grid layout, CSS Animation이나 컴포넌트 제작 팁, 디자인 패턴과 같은 이야기들은 준비하고 있습니다.
다음 번에는 꼭 완성도 있는 CSS글로 찾아뵙겠습니다.
끝으로 제가 만든 CSS Framework 홍보 한번만 할게요!
좋은 하루 되세요 :)
세상 귀여운 CSS Framework!
Rapid on-demand atomic css framework
https://developer-1px.github.io/adorable-css/
Author And Source
이 문제에 관하여(CSS책 출판제의를 받고 작성했던 원고들 공유... (지금은 부러졌어요)), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://velog.io/@teo/CSS책-출판제의를-받고-작성했던-원고들-공유...-지금은-부러졌어요저자 귀속: 원작자 정보가 원작자 URL에 포함되어 있으며 저작권은 원작자 소유입니다.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)