코드스피츠 css 렌더링 강의 내용 정리
graphics system
•
.을 찍는 일 (픽셀로 이루어진 화면)
◦
x, y, width, height 와 같은 고정된 숫자로 표현 (fixed number system)
◦
하지만 이런 시스템은 다양한 기기의 환경에 적응할 수 없음
▪
모니터 해상도 말고도 브라우저의 크기, 모바일의 가로/세로 모드도 영향을 준다.
◦
그래서 범용성 있는 graphic system을 생각하게 됨
*ui에 있는 여러 요소들을 chrome 이라고 한다.
⇒ abstract calculator: 고정된 숫자로 표현하지 않고%, left, block, inline 이라는 메타포, 공식이자 함수를 사용하게 됨.
•
%: 비율로 표현하겠다. 공식이자 함수. 해상도가 주어지면 크기를 반환
•
right: 부모 width에서 자신의 width를 뺀 다음 그 숫자를 자신의 x 좌표로 삼음
◦
부모가 100, 자신이 10이면 90 위치에 자신을 놓는다.
⇒ components: 복잡한 화면을 그리기 위해 추상화된 그래픽스 시스템 내에서 공통적인 엘리먼트를 만들게 됨
⇒ framework: 해당 컴포넌트가 일정한 규칙과 사용방법을 지키도록 하게 되어있다면 프레임워크라고 함
rendering system
•
graphics뿐 아니라 범용적으로 사용되는 말
•
내가 원하는 모습으로 다시 그려내는 일
•
데이터를 어떻게 그림으로 표현하는가.
◦
그림으로 표현하기 위한 정보는 뭘까?
•
2단계: 영역을 나눈 뒤 그린다
◦
geometry calculate: 박스 영역을 나눔.
◦
fragment fill: 하나하나 칠하는 대상을 fragment라고 함. fill은 색칠하는 것
◦
브라우저도 똑같다. reflow → repaint 과정을 거친다.
css specifications
•
css 등장 배경
◦
고정된 숫자가 아니라 계산된 체계로 그래픽을 표현할까
◦
박스 영역을 어떻게 나눌까
◦
어떻게 칠할까
•
css 속성을 배운다 = '메타포가 어떻게 계산되서 표현되는가'를 배우는 것
•
기존에 있는 렌더링 시스템 차용함 → 그래서 복잡하고 일관성이 없음. 그러므로 specifications document를 봐야 함
◦
그래야 표준에 맞게 구현한 다음에 pollyfill로 구현함(응용해서)
1.
css level1
•
html에 스타일을 넣으니 너무 복잡한데 그래픽스 시스템을 차용해서 렌더링 시스템을 만들면 어떨까
2. css level2 + module
•
IE가 시장 독점을 하고 있던 시기에 MS에서 제안한 css 속성 대부분이 받아들여짐
•
css는 그림에 대한 건데 이걸 하나의 스펙으로 관리하는 건 무리다.
◦
그러므로 spec/기능/사양 별로 모듈을 나누자.
◦
level2의 스펙들이 모듈화됨
3. css level 2.1
•
include level 3 module
•
어떤 모듈은 일을 너무 열심히 해서 3 module까지 발표해버림
◦
syntax, values, text, color, selector 등
•
하지만 다른 스펙에서는 기능이 발전하지 않았기때문에 3으로 버전업하기 어려웠음
•
그래서 우리가 css3라고 부르는 것들은 3버전으로 발표된 것들만 모아서 부르는 것
4. module level
•
transforms, masking, compositing, flexbox, effects, grid → 1버전들
•
level3, 1버전 모듈들이 각자 버전업을 하고 있음
•
그래서 브라우저 제조사가 모두 각 모듈의 최신 사양을 따라가기 어려움 → 브라우저마다 지원되는 속성이 달라짐
other specifications
•
w3c community and business groups
•
wicg(구글이 주 멤버), ricg(wicg에게 먹힘)
•
스티브잡스가 아이폰 발표하면서 MS의 힘이 약해짐. MS의 어용단체인 w3c의 힘이 덩달아 약해지면서 위의 group들이 등장함.
•
그전에 w3c에는 스펙 개발을 통제했었는데, 힘이 약해지면서 자율적인 w3c 커뮤니티를 인정하고 그 커뮤니티에서 스펙 개발을 하면 draft를 w3c에 제안.
◦
wicg: 크롬에서 먼저 반영한 후 w3c에 draft 제안해버림
여기까지 기본적인 배경지식
normal flow: 브라우저에서 가장 많이 쓰이는 계산 공식이므로 normal flow라고 함
1.
css2.1 스펙의 'visual formatting model'이라는 문서가 있음 (화면에 보이는 모델을 어떻게 포맷팅할 것인가)
2.
position: static, relative, absolute, fixed, inheirt
•
어떤 geometry 영역에 추상적인 위치를 결정하게 하는 시스템
•
static, relative만 normal flow에 속함.
3.
normal flow 의 2가지 계산 공식
•
block formatting contexts (BFC)
•
inline formatting contexts (IFC)
•
relative positioning → positioning 모델에서 정의하므로 실제 normal flow는 위의 두 가지라고 할 수 있다.
block/inline
•
block: 부모의 width를 가득 채운 한 줄 = 한 줄을 다 먹는다. 부모 width 만큼
◦
그래서 width를 전체 width보다 작게 해도 fragment의 width만 작아지고, block은 전체 width를 유지함
◦
그래서 width를 전체 width보다 작게 해도 다음 줄로 넘어감
•
x는 항상 같기 때문에 '다음번 block이 나올 때 y 위치는 어딘가?'라는 질문만 대답하면 됨
◦
세번째 block의 y는 '첫번째 블록, 두번째 블록의 height를 합친 값'에 위치함
•
전체 block은 안에 있는 block height들의 합
•
inline: 나의 콘텐츠 크기만큼 가로를 차지함
•
공백을 주는 순간 하나의 inline 요소가 됨
◦
만약 word-break 속성을 주면 문자 하나하나를 inline으로 보게 됨. 그래서 inline이 아니더라도 width를 넘어가면 다음줄로 넘어가게 됨
◦
한편으론 word-break 속성을 주면 문자 하나하나를 geometry로 보게 되서 계산이 느려짐
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa -> block
aaaaaaaaaaaaaaaa -> inline
aaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaa
HTML
복사
•
다음 번 inline의 x 위치는 어디인가? → 첫번째 inline의 width 값이 x 위치가 됨
•
그리고 inline 요소들의 width의 합이 부모 width를 넘으면 한 줄을 넘어감 (넘어간 만큼)
◦
y는 윗 줄에서 가장 높이가 큰 요소의 height 값. 이것을 기준으로 정렬하기 위해 baseline이라는 것이 생김
•
ifc가 있어도 bfc가 다음에 오면 ifc는 종료됨
•
bfc + ifc
◦
span 안에 div가 있으면 어떻게 되는 걸까?
◦
렌더링 시스템과 DOM의 구조는 무관함
◦
Hello World
<div>
Hello // inline
<span>
World // inline
<div> </div> // block
</span>
!! // inline
</div>
HTML
복사
•
span tag에 relative 포지션을 주면?
◦
relative position을 먹게 됨
◦
static으로 그린 뒤 상대적으로 위치를 이동시킴 = normal flow로 먼저 그린 뒤 상대적으로 이동시킴 = 즉, width와 height는 변경되지 않고 위치만 이동시킴.
◦
이때, static과 relative 포지션이 함께 쓰이면 relative 포지션이 static 포지션 위로 가서 다른 엘리먼트들을 가려버림
▪
relative끼리는 z-index로 쌓임
◦
world, 빨간 박스만 relative이므로 이들만 50px 이동시킴
normal flow가 아닌 것들을 사용하면, width나 height를 줘야만 포지셔닝이 된다든지 하는 문제가 있음. normal flow를 써야만 width, height가 자동으로 계산됨
html 모든 태그들의 기본 포지션은 static. 그래서 평소에는 따로 지정해주지 않아도 쓸 수 있음.
