히카맹 선생님의 코드스피츠 강의를 들으며 자바스크립트에 대한 이해를 높이기 위해 스터디를 하게 되었다. 이 포스팅은 그에 대한 정리글이다.
들어가면서...
히카맹 선생님의 코드스피츠 강의를 듣고 포스팅한다고 말한 지 어느덧 한달이다. 사실 다 듣고는 있었는데 (스터디를 하니까 .. ) 뭔가 욕심에 이해가 조금도 안되는 부분에 대해서는 포스팅하기가 꺼려지는 터라 포스팅을 미뤄왔다. ES6+ 기초편 이후 객체 지향도 들었는데 어우... 이게 다 무엇인가 싶다. 다시 한번 듣고 개념적으로라도 포스팅을 할까 싶은데 사실 어떻게 될지는 모르겠다.
뭐 어쨌든 일단 어제 진행한 CSS Rendering 1,2회차 스터디에 대해서는 포스팅을 할 수 있을 정도는 되는 것 같아 이렇게 포스팅을 해본다.
위 이미지는 심심하고 새로 안 사실에 헉 하며 만들어본 CSS 카세트테잎... gif로 변환했더니 뭔가 이상하게 일렁이는구만
🎨 Graphics System과 Rendering System
Graphics System
그래픽 시스템이란 말 그대로 그래픽(그림)을 표현하는 방법이다. 그리고 이 시스템에는 몇개의 개념이 있는데,
- 그림을 그리는 행위는 무엇일까요? 라고 물어보면 연필로 그리는 그림, 태블릿을 통해서 그리는 그림 등 많은 방법을 얘기할 것이다.
하지만 브라우저에서 그림을 그리는 행위란 "특정한 좌표에 있는 Pixel에는 검정색을 주도록 해"와 같이 아주 저차원적이지만 구체적인 방법을 의미한다. 그리고 이 과정을 이를 Fixed Number라고 부른다.
-
하지만 사람은 일일이 이런 Pixel 좌표를 브라우저에게 전달하며 그림을 그릴 것을 요구할 수 없다. 그래서 이를 %, left, right, float, block 등 조금 더 사람이 알아듣기 편한 은유적인 단어, 즉 메타포로 표현한 것을 Abstract Calculator라고 한다.
-
그리고 그런 추상화된 그래픽 시스템의 체계를 공통적으로 가지고 있는 개체들을 Component라고 부르게 되는데 이는 마치 HTML tag와 같다. 예를 들어 img태그를 사용할 때 img src만 넘겨 준다면 pixel의 위치를 일일이 그려주지 않아도 img가 렌더링 된다.
-
마지막으로 이런 Component들이 일정한 규칙과 사용방법을 지키는 형태로 구현되어있는 것을 Framework라고 한다. HTML 태그의 집합인 HTML이 Framework에 해당할 것이다.
🌟중요🌟
중요한 점은 3, 4번의 component와 framework는 유동적이다 라는 것을 깨닫는 것인데, A가 B와 Framework/Component 관계에 있었다고 해도 A와 C의 관계가 Component/Framework 일 수 있다는 점이다.
Rendering System
렌더링 시스템이란 그림을 그리는 데 필요한 데이터를 어떻게 그림으로 표현하는가에 대한 방법이다. 즉 그래픽 시스템을 기반으로 받아온 데이터를 어떻게 브라우저에 표현을 할 것이냐라는 것.
렌더링 시스템은 크게 두가지 과정을 거치게 된다.
-
영역을 일종의 박스로 구분하는 과정, Geometry Calculate를 우선적으로 수행하게 되는데 이때 Geometry(영역)을 계산하는 과정을 Reflow라고 부른다.
-
영역을 계산한 후 그 영역을 채우는 과정이 당연히 필요할텐데 이 과정을 Repaint라고 하고 Fragment Fill이라고 부른다.
📄 CSS Specifications
자 그래서 이 Graphics System과 Rendering System을 합치면 CSS냐구? 음. 반쯤 맞는 정답 같다.
정확히는 "어떻게 하면 고정된 숫자를 사용하지 않고 계산된 체계로 그래픽을 데이터화할 수 있을까? 그리고 그 데이터를 토대로 어떻게 geometry를 나누고 브라우저에 그려넣을 수 있을까?"와 같은 고민에서 나온 스타일 언어정도로 정의할 수 있다.
CSS Level 과 Module Level
CSS는 초반에 CSS Level이라는 것으로 구분되었다. 그래서 처음 생겨났을 때의 문서는 CSS Level1 이다. 하지만 CSS Level2로 버전업하게 되면서 특이점이 발생하게 되는데.. 바로 기능을 개개인 또는 그룹이 기능을 개별적으로 만들어 추가하는 module의 추가였다.
이 module이란 게 CSS와 같이 Level이 업데이트 되었으면 참 좋았겠지만, CSS Level과는 달리 module의 Level이 독자적으로 먼저 오르는 사태가 발생했고 CSS Level이 2.1 임에도 몇몇 모듈은 Level이 3이 되는 기현상이 발생했다.
그래서 이후로는 CSS Level이 아닌 module의 레벨을 정식으로 추가해 지원하게 되었다.
Other Specifications
시간이 흘러 브라우저의 성능이 좋아지기 시작하면서 CSS의 제안자였던 W3C의 입김이 서서히 줄어들기 시작하는데 이 때 W3C의 권고안을 따르지 않고 독자적인 CSS스펙을 개발하는 그룹들이 생겨나기 시작했다. 대표적으로 구글과 같은 웹 플랫폼 제공자들이 속한 WICG(Web Platform Incubator Community Group)이 있고 지금은 사실 상 WICG에 흡수되고있지만 2대 세력인 RICG(Responsive Issues Community Group) 이 있다.
🔜 Normal Flow
브라우저 상에 렌더링이 이루어질 때, 브라우저가 "기본값"으로 레이아웃을 렌더링 하는 것을 의미하는데, 쉽게 얘기해 별도의 CSS를 적용하지 않았을 때 브라우저가 레이아웃을 렌더링 하는 기본값을 뜻하는 것이다. (가령 position의 static과 같이..)
NORMAL FLOW의 3가지 계산 시스템
Normal Flow에는 3가지의 계산 시스템이 있는데
-
블록 요소가 발생하는 지점 또는 Float 속성을 가진 요소가 등장했을 때 발생하는 Block Formatting Context (BFC)
-
문장(Inline 요소)이 작성되는 방향으로 배치되는 Inline formatting context (IFC)
-
Position Static 일 때의 위치를 기준으로 top, bottom, left, right 속성이 적용되어 렌더링되는 Relative Positioning
이렇게 3가지가 있다.
BFC의 경우 BFC 내부에 있는 요소들의 y값(height)을 계산해 offset 값으로 지정을 해주게 되는데 이 때 IFC의 height값 역시 BFC에서 자연스럽게 합산되어 계산된다.
위의 사진에서 토마토색 상자부터 초록색 상자까지의 y값이 BFC의 height가 된다.
이 때 중간 (여러개의 span태그로 이루어진) IFC의 경우에도 height값을 계산해 BFC에 넘겨주게 된다.(IFC가 그런 기능을 가진다!)
그리고 위처럼 초록색 상자에 Relative 속성과 top, right 속성을 주었을 때, static을 기준으로 해 주어진 top과 right만큼 이동하게 된다.
또 Relative Positioning에 대한 재밌는 사실로는 IFC 바로 위에 있던 Block요소인 파란 상자를 Relative로 위치를 변경했음에도 파란 상자의 블록영역을 IFC가 침범하지 않고 있는 것을 볼 수 있다.
🚢 Float
CSS를 처음 학습하면서 가장 곤혹스러웠던 개념은 아무래도 Float 아니었나 싶다. Float로 레이아웃을 잡는다는 것은 종잡을 수 없는 바람을 뱉으며 날아가는 풍선의 동선과 같았다... 하지만 그래도 코드스피츠의 CSS Rendering 수업을 들으면서 조금은 감이 오긴 하는디..!
Float의 특성
Float가 가진 특성은 4가지 가량이다.
- Float는 새로운 BFC를 생성해낸다.
- Float는 Normal Flow 위에 있다. (마치 z-index 상위에 있는 것처럼)
- Text와 같은 Inline요소에 대한 Guard 기능이 있다.
- Line Box라는 개념을 가진다.
Float는 생성이 되면 새로운 BFC를 같이 생성하며 Inline 요소가 Float 위 혹은 아래에 올 수 없는 Guard 기능이 있다.
위의 이미지는 Float의 1번, 2번의 특성이 나타나있다.
- float 속성을 적용한 초록박스는 빨강과 파랑(normal flow)박스 위에 위치해있다
- 그리고 float 속성의 초록박스는 또 다른 BFC를 생성해내어 내부에 Block요소를 담고 있다.
위의 이미지는 2, 3, 4번의 특성이 나타나있다.
- float 요소들이 빨강 박스(normal flow) 위에 위치해있다.
- 빨강 박스에서 작성된 텍스트들이 Float 요소들을 피해 렌더링 되었다.
- Line Box 의 특성이 반영되어있다. <- 그래서 이게 무슨 말?
Line Box
Line Box라는 개념은 BFC의 영역 중 Float 요소가 차지하고 남은 부분 정도로 이해해볼 수 있다.
위 이미지를 보면 초록색 박스는 left 속성이 파란색 박스는 right 속성이 적용되어 있는데 이 사이의 공간이 Line Box가 되며, Float 요소를 추가하게 되면 이 Line Box에 들어갈 수 있는 지를 먼저 확인하게 된다.
그런데 이떄 이 Line Box 내부에 또 다른 Float 요소가 들어가려면 조건이 있는데, 첫째로 무조건 left속성과 right속성 사이에 (있는 Line Box에) 들어가야하며 자리가 있다면 Line Box의 하단 라인을 기준으로 요소가 렌더링 된다.
그래서 위 첫이미지를 보았을 때 3, 4번 사이의 빈공간에 Line Box가 생성이되고 5번 요소가 그 자리를 차지 했다.
마지막으로 무조건 Left속성과 Right속성 사이에만 (inline 같은) 요소들이 들어갈 수 있다고 했는데, 위 이미지로 표현하면 아래와 같다.
🌊 Overflow
마지막으로 Geometry(영역)를 넘어서는 컨텐츠에 대해 어떻게 렌더링 할 것인 지에 대한 옵션으로 Overflow: Hidden 혹은 Overflow: Scroll 속성이 float와 간접적인 관계를 가지는데, 이는 hidden이나 scroll일 때 새로운 BFC를 생성한다는 규약이 있기 떄문에 그렇다. 그리고 이런 새로운 BFC가 생성될 떄는 Line Box Bound를 인식해서 만들게 되는데 렌더링할 높이가 부족하거나 할 떄에는 영역만 지정되고 그래픽은 렌더링되지 않는 현상이 발생한다.
위 이미지는 완벽히 동일한 코드에 overflow: hidden 속성을 주었느냐 아니냐만으로 이렇게 레이아웃이 달라졌다.
초록 상자에 overflow: hidden을 사용함으로서 맨위 중앙의 1, 2번 요소 사이의 공간이 height를 감당하지 못하자 3,4 사이의 공간으로 넘어와 렌더링 됐다. 하지만 overflow: hidden인 상태이므로 텍스트는 두글자 외에는 렌더링이 되지 않았고 hidden 속성을 적용하지 않은 핑크색 박스를 제외하고는 모두 동일하게 빈공간만 사용하게 되었다.
마치며...
오늘 1,2화 스터디를 하고 모두 정리를 하고자 하였으나 생각보다 1화의 양만으로도 충분히 많아 1화까지만 먼저 끊어 포스팅하려고 한다.
1화에서 가장 충격적이었던 건 아무래도 float에 대한 부분이었던 것 같다. CSS를 배울 떄 가장 많이 괴롭혔던 기능이기 떄문에 그럴까..?
또 CSS 역시 원론적으로 접근해 기술문서를 읽어야겠다는 생각이 뿜뿜 들게 만든 스터디였다. 갓... 공부는 즐겁~
