CSS Rendering - 코드 스피츠 76회차를 보고나서 정리

목차

 

 

코드 스피츠라는 유튜브를 보고 나서 여태까지 내가 깊게 공부하지 않았다는 느낌을 받았습니다.

그래서 이제부터라도 깊게 공부하기 위해서 코드 스피츠에 올라온 영상들을 차근 차근 정리해보는 시간을 가지려고 합니다.

CSS 배경 지식 

CSS를 배우기 전에 알아야할 배경 지식에 대해서 설명을 해주셨다.

Graphics System

Graphics System은 한마디로 점 찍는 방법에 대한 것입니다.

X, Y, Width, Height, Color로 표현할 수 있습니다. 어떻게 이루어져 있든 마지막에는 점으로 이루어져 있습니다.

 

Graphics System 발전 과정

Fixed Number -> Abstract Calculator(추상화된 계산) -> Components -> FrameWork

 

Fixed Number

(0,0) (1, 100) 와 같이 고정된 숫자로 표현하는 체계를 말합니다.

예전에는 특정 기기의 특정 해상도에만 맞추면 되어서 이러한 고정된 숫자로 만든 그래픽스 시스템을 적용할 수 있었지만,

지금은 핸드폰, 태블릿, PC등 다양한 환경이 있습니다. 그래서 범용성 있는 그래픽 시스템을 만들려고 하면 고정된 숫자로 하기에는 굉장한 어려움이 있습니다. 

 

Abstract Calculator

다양한 환경에 따라서 그래픽스 시스템을 적용하기 위해서는 위에서 말씀드린 원시적인 숫자로 기술하는 그래픽스 시스템으로는 어렵기 때문에 함수를 통해서 어떻게 계산할 것인지로 발전하게 됩니다. 숫자 대신에 공식을 쓰는 형식입니다.

( %, Left, Block, Inline, Float 와 같은 메타포를 사용합니다. 여기에서 정의하는 메타포는 한마디로 함수라고 할 수 있다고 하십니다.) 

 

Components

추상화된 그래픽스 시스템 체계를 이어받는 공통점을 갖고 있는 것들을 컴포넌트라고 합니다.

컴포넌트의 대표적인 예 -> HTML

 

FrameWork

컴포넌트들이 일정한 규칙과 사용방법을 지키는 형태로 구현되어 있다면 프레임워크라고 부릅니다.

HTML 태그는 공통적인 스타일 속성이 붙어있습니다. 즉 공통되어 있는 규칙과 체계가 있으니 HTML 체계를 프레임워크라고 볼 수 있습니다.

 

Computer Science를 배울 때 주의할 점은 항상 상대적으로 생각해야 한다는 점입니다.

자식클래스가 꼭 자식클래스가 아니라 부모 클래스가 될 수 있듯이, JS파일 입장에서 브라우저는 OS로 보이지만 window 입장에서 보면 브라우저는 어플리케이션인 것처럼 항상 상대적으로 생각할 수 있어야 합니다.

Rendering System

렌더링이란?

- 어떠한 대상을 내가 원하는 모습으로 다시 그려내는 것을 렌더링이라고 합니다.

- 보다 구체적이고 시각적인 형태로 바꿔주는 것(꼭 시각적일 필요는 없다.)을 렌더링이라고 합니다.

- 사람이 보다 인식하기 쉽거나, 기계가 보다 인식하기 쉽게 만드는 것도 렌더링이라고 할 수 있습니다.

- 어떠한 체계를 통해서 그림이 표현되는가와 같은 개념입니다.

 

순서

1. Geometry Calculate(지형지물 계산)

 -> 어떻게 영역이 나누어져 있는 지 계산을 합니다.

2. Fragment Fill(색칠을 한다.)

 -> 하나하나의 대상을 색칠을 합니다.

(* Fragment는 고유명사로 그때 하나하나의 대상을 Fragment(단편, 조각)라고 합니다.)

 

브라우저 또한 똑같이 구현이 되어 있다.

1. Geometry Calculate -> 영역이 나누어져 있는 지 계산하는 것 브라우저에서는 이것을 Reflow라고 합니다.

2. Fragment Fill -> 영역을 색칠을 한다. 브라우저에서는 이것을 RePaint라고 합니다.

 

* CSS란 어떻게 하면 고정되어 있는 숫자를 사용하지 않고 계산된 체계로 그래픽을 표현할까?,

Geometry의 영역을 어떤 식으로 표현을 할까?,  색칠을 어떻게 명령을 내릴까?에 대한 일종의 언어입니다.

CSS Specification

브라우저가 작동하는 것이 맞는 지 틀린 지 알기 위해서는 사양서를 알아야합니다.

그래야 표준이 무엇인지를 알고, 올바른 문법으로 작성을 하고 안되는 부분은 폴리필을 할 수 있기 때문에 사양서가 중요합니다.

 

CSS Level 1

-  HTML에 그림과 관련된 것을 넣으니 너무 복잡해져서 그림과 관련된 부분을 따로 빼서 관리, 문서 한장에 담길 정도로 내용이 적습니다.

CSS Level 2

- MSI4가 제안을 많이 했습니다.

- CSS는 그림과 관련된 것인데 그림에 관련된 것을 하나의 스펙으로 관리하는 것이 어렵다는 제안에 Module로 관리하자는 내용이 제안 되었습니다.

CSS Level 2.1

- Include Level 3 Module

- 모듈별로 어떤 모듈은 모듈3을 발표하는 팀이 생기고 어떤 Spec은 활발히 연구되어 버전 업이 자주 되는 것에 비해 어떤 사양은 확정되어 레벨이 올라갈 일이 없다는 것을 깨달았습니다.

 

CSS Level 3는 나올 수 없다는 깨달음이 있고 CSS 2.1때 모듈들 중에 Level3을 모아서 CSS3으로 부르게 됩니다.

이후에는 Module Level(Transform 1, Grid1, FlexBox1)이라고 부릅니다.

 

CSS 사양의 세계는 끊임 없이 모듈이 생성되고 어떤 모듈은 계속해서 업데이트가 이루어 지고 있을 것입니다.

브라우저마다 다 특이하게 동작하는 이유는 CSS 스펙이 이렇게 모듈별로 진행상황이 다르기 때문에 브라우저 제조사가 전부 다 최신으로 따라갈 수 없기 때문입니다.

 

이러한 개념을 알고있다면,

만약 브라우저가 Transform을 지원하더라도 Transform모듈의 레벨 1을 지원하는 지, 레벨 2를 지원하는 지 확인을 할 수 있습니다.

 

최근에는 W3C의 권고안에 없어도 브라우저에서 구현할 수 있게 제약을 풀었고 드래프트에 있어도 브라우저에서 사요이 가능합니다.

Normal Flow

CSS 2.1 스펙에 Visual Formatting Model이라는 것이 있습니다.

거기에 Positioning Schemes & Normal Flow라고 쓰여 있고 거기에서 처음 용어가 등장 했습니다. 이것은 고유 명사입니다.

 

Position?

어떤 Geometric 영역에 x, y, width, height를 결정할 때 추상적인 위치를 결정하는 어떤 시스템을 말합니다.

Static | Relative | Absolute | Fixed | Inherit | sticky 등이 있습니다.

 

Normal Flow는 총 3개로 이루어져 있습니다.

Block Formatted Context(BFC), Inline Formatted Context(IFC), Relative Positioning 이 있습니다. Relative Positioning은 포지션에서 살펴볼 것이라서 BFC, IFC를 보겠습니다.

 

Block 계산 방식으로 그려질 것인지 Inline 계산 방식으로 그려질 것인지에 대한 원리를 BFC, IFC라고 합니다.

Block Formatted Context(BFC)

Block -> 부모의 가로 길이를 가득 채운 한 줄, 한 줄을 다 먹는 행위

Block요소는 x는 언제나 0, width는 언제나 부모의 width입니다.

그렇기에 BFC 요소에서 생각할 것은 다음에 Block이 나올 때 Y자리가 어디인지만 생각하면 됩니다. (Y자리는  첫 번째 블록 컨텍스트의 height가 두 번째 블록 컨텍스트의 Y값이 됩니다.)

 

- 안에 있는 블록 요소의 height의 합이 나의 height가 됩니다.

Inline Formatted Context(IFC)

inline -> 자신의 콘텐츠 크기만큼 가로를 차지합니다. 

x값을 생각해보면 다음 번 요소의 x는 첫 번째 IFC요소의 가로길이만큼 떨어진 자리에 x가 결정될 것입니다.

inline width의 합이 부모의 width를 넘어가게 되면 밑으로 내려갑니다. 얼만큼 밑으로 내려가는 지는 구성된 인라인 요소 중 height가 가장 큰 애가 line-height가 되어서 line-height만큼 y값이 내려오게 됩니다.

See the Pen Untitled by dev-sangwon (@dev-sangwon) on CodePen.

위의 결과물을 보면 a가 부모의 width를 벗어나게끔 됩니다. 브라우저는 공백문자가 없는 연속된 문자열을 하나의 inline요소로 봅니다.

이를 해결하기 위해서는 두가지 방법이 있습니다.

1. 공백문자를 삽입해준다.

2. word-break 속성을 이용해서 단어 하나하나를 인라인으로 보게 한다.

 

첫 번째 방법을 이용해서 수정해보겠습니다.

See the Pen CSS Rendering1 - 2 by dev-sangwon (@dev-sangwon) on CodePen.

공백문자를 삽입해서 총 3개의 인라인 요소로 해석하게끔 했습니다. 위에서 인라인 요소는 부모 요소의 크기를 넘어가게 되면 자동으로 아래로 이동하게끔 된다고 했습니다. 그 특성을 이용해서 공백문자를 삽입해서 해결이 됩니다.

 

두 번째 방법은 word-break를 이용하는 방법입니다.

원래 브라우저는 공백문자가 없는 문자열을 하나의 인라인으로 처리해서 그림을 그렸습니다. 그런데 이 속성을 주게 되면 공백문자가 붙어 있지 않는 문자열도 하나하나 인라인으로 보기 때문에 계산할 것이 많아져서 브라우저가 느려지게 됩니다.

 

See the Pen CSS Rendering1 - 3 by dev-sangwon (@dev-sangwon) on CodePen.

 

 

Rendering System과 DOM의 구조는 무관합니다.

아래 코드를 보시면 span안에 div가 들어있으면 span이 부모이기 때문에 span의 크기만큼 div가 그려질 것으로 예상이 되지만 아닙니다.

브라우저는 IFC요소인지 BFC요소인지를 확인해서 그리기 때문에 DOM구조와는 무관합니다.

 

IFC + BFC 예제

See the Pen CSS Redering 1 -4 by dev-sangwon (@dev-sangwon) on CodePen.

 

 

Relative Position은 지금 까지 해왔던 개념에 살짝 추가가 되는 것입니다.

모든 엘리먼트의 기본 값은 Position Static입니다.

Static으로 그린 다음에 상대적으로 위치를 이동시킬 뿐입니다. 위에서 했던 예제에 position: relative로 변경을 해보면 이해가 갑니다.

 

 

See the Pen Untitled by dev-sangwon (@dev-sangwon) on CodePen.

 

Position Relative와 static이 섞여있으면 무조건 Relative가 위로 올라옵니다. 물론 같은 Relative라면 z-index로 위치를 가립니다.

그래서 빨간 박스와 글자가 파란박스보다 위에 있습니다.

 

position: relative;는 normal Flow로 그린다음 상대적으로 위치를 이동시키는 것입니다.

 

+ (수정)

 word-break

브라우저는 공백문자가 없는 하나의 문자열을 인라인 속성으로 보게됩니다. 하지만 word-berak를 이용하면 문자열의 하나하나를 인라인 요소로 구분해서 바라보기 때문에 브라우저의 속도가 느려진다는 내용이 있었습니다.

그러면 어떤 방식을 이용해야 하는 지 궁금해서 찾아보았습니다.

 

word-wrap: break-word;를 사용하게 되면 영역을 벗어나는 문자열을 쪼개게 됩니다.

word-break: break-all; 보다는 덜 쪼개기 때문에 브라우저에 부하가 적지 않을까라는 생각이 들어서 게시물을 수정하게 되었습니다.

틀린 점이 있다면 지적해주시면 감사하겠습니다 :) 

 

감사합니다.