브라우저 동작원리

기본 구조

사용자 인터페이스
브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어
렌더링 엔진 : 요청한 콘텐츠를 표시. HTML 을 요청하면 HTML과 CSS를 파싱하여 화면에 표시함.
통신
UI 백엔드 : 콤보박스와 창 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서 OS 사용자 인터페이스 체계를 사용함.
자바스크립트 해석기
자료저장소 : Localstorage, SessionStorage, Cookie

크롬은 각 탭마다 별도의 렌더링 엔진 인스턴스를 유지함. 즉, 각 탭은 독립된 프로세스로 처리됨.

렌더링 엔진

HTML 및 XML 문서와 이미지를 표시할 수 있음
- 플러그인이나 브라주어 확장 기능을 통해 PDF 와 같은 유형도 가능하다.
엔진 종류
- 게코 : 파이어폭스
- 웹킷 : 사파리, 크롬
동작과정
1. DOM 트리 구축을 위한 html 파싱
  - HTML을 파싱하고, 콘텐츠 트리 내부에서 태그를 DOM 노드로 변환함.
  - 그 다음 외부 css 파일과 함께 스타일 요소도 파싱함.
  - 스타일 정보와 HTML 표시 규칙은 렌더 트리라고 부르는 또 다른 트리를 생성한다.
2. 렌더 트리(게코에서는 frame tree) 구축
  - 색상 또는 면적과 같은 시각적 속성이 있는 사각형을 포함하고, 정해진 순서대로 화면에 표시한다.
3. 렌더 트리 배치
  - 각 노드가 화면의 정확한 위치에 표시되는 것을 의미함.
4. 렌더 트리 그리기
  - ui 백엔드에서 렌더 트리의 각 노드를 가로지르며 형상을 만들어냄.

파싱과 DOM 트리 구축

파싱 : 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것
- 결과 : 보통 문서 구조를 나타내는 노드트리가 나옴. 파싱트리, Syntax tree 라고도 불림
파서-어휘 분석기 조합
- 어휘분석 : 자료를 토큰으로 분해하는 과정.
  - 토큰 : 유효하게 구성된 단위의 집합체로 용어집이라고도 함.
- 구문분석 : 언어의 구문 규칙을 적용하는 과정
- 파서 : 문서 -> 어휘분석 -> 구문분석 -> 파싱트리로 만듬.
  - 자료를 유효한 토큰으로 분해하는 어휘 분석기와 언어 구문 규칙에 따라 문서 구조를 분석함으로써 파싱트리를 생성하는 파서가 있음.
  - 어휘 분석기는 공백과 줄바꿈 같은 의미없는 문자를 제거
- 파싱과정은 반복됨.
  - 파서는 어휘 분석기로부터 새 토큰을 받아서 구문 규칙과 일치하는지 확인함.
  - 규칙에 맞으면 토큰에 해당되는 노드가 파싱트리에 추가되고, 파서는 또 다른 토큰을 요청함.
  - 규칙에 안맞으면 파서는 토큰을 내부적으로 저장하고 토큰과 일치하는 규칙이 발견될 때까ㅏ지 요청함. 맞는 규칙이 없으면 구문 오류가 있다는 것.
변환 : 파싱과정을 통해 나온 파싱트리를 기계코드로 변환시키는 과정
어휘화 구문에 대한 공식적인 정의
- 어휘는 보통 정규표현식으로 표현된다.
- 구문은 보통 BNF라고 부르는 형식에 따라 정의된다.
- 문법이 문맥 자유 문법이라면 언어는 정규 파서로 파싱할 수 있음.
  - 문맥 자유문법 === 완전히 BNF로 표현가능한 문법
파서의 종류
- 하향식 파서 : 구문의 상위 구조로부터 일치하는 부분을 찾음.
  - 가장 높은 수준의 규칙을 먼저 찾음.
- 상향식 파서 : 하위 구조로부터 일치하는 부분을 찾음.
  - 입력 값이 규칙에 맞을 때까지 찾아서 맞는 입력값을 규칙으로 바꿈.
  부준적으로 일치하는 표현식은 파서 스택에 쌓이며, 오른쪽으로 갈수록 남는 것이 점차 감소하기때문에 이동-감소 파서라고 부름.
파서 자동생성
- 파서 생성기 : 파서를 생성해 줄 수 있는 도구
- 웹킷
  - 플렉스(Flex) : 어휘 생성. 토큰의 정규 표현식 정의를 포함하는 파일을 입력 받음.
  - 바이슨(Bison) : 파서 생성. BNF 형식의 언어구문규칙을 입력받음.

HTML 파서

Html 마크업을 파싱 트리로 변환함.
문법 정의 : W3C 에서 명세로 정의되어있음.
문맥 자유문법이 아니다. 따라서 BNF로 표현불가능.
HTML vs XML
- HTML : 더 너그로운편. 암묵적으로 태그에 대한 생략이 가능함. 가끔 시작 또는 종료 태그 등을 생략함.
- 따라서 HTML은 파싱하기 어렵고 전통적인 구문 분석이 불가능하기때문에 문맥 자유 문법이 아님.
HTML DTD
- HTML의 정의는 DTD 형식 안에 있는데 SGML 계열 언어의 정의를 이용한 것이다.
- DTD 형식은 허용되는 모든 요소와 그들의 속성 그리고 중첩구조에 대한 정의를 포함한다.
DOM : 문서 객체 모델(Document Object Model)
- 파싱트리는 DOM 요소와 속성 노드의 트리로서 출력 트리가 된다. 트리의 최상위 객체는 문서이다ㅏ.
- DOM은 HTML 문서의 객체 표현이고, 외부로 향하는 자바스크립트와 같은 HTML 요소의 연결지점이 된다.
파싱 알고리즘
- 일반적인 하향식, 상향식 파서로 파싱이 안됨. 그 이유는
  - 언어의 너그러운 속성
  - HTML 오류에 대한 브라우저의 관용
  - 변경에 의한 재파싱. document.write를 포함하고 있는 스크립트 태그는 토큰을 추가할 수 있기 때문에 실제로는 입력과정에서 파싱이 수정됨.
- 파싱 알고리즘은 HTML 문서에 자세히 설명되어있다.
- 알고리즘은 토큰화와 트리 구축으로 나누어져있음
- 토큰화 : 어휘 분석으로서 입력값을 토큰으로 파싱함.
  - HTML 에서 토큰은 시작태그, 종료태그, 속성이름과 속성 값이다.
토큰화 알고리즘
- State Machine으로 볼 수 있음.
- 각 상태는 하나 이상의 연속된 문자를 입력받아 이문자에 따라 다음 상태를 갱신함.
- 결과는 현재의 토큰화 상태와 트리 구축 상태의 영향을 받음.
트리구축 알고리즘
- 트리 구축이 진행되는 동안 문서 최상단에서는 DOM 트리가 수정되고, 요소가 추가됨.
- 토큰화에 의해 발행된 각 노드는 트리 생성자에 의해 처리됨.
- 각 토큰을 위한 DOM 요소의 명세는 정의되어있다.
- DOM 트리에 요소를 추가하는 것이 아니라면 열린 요소는 스택에 추가됨.
  - 부정확한 중첩과 종료되지 않은 태그를 교정함.
- 알고리즘은 상태 기계라고 설명할 수 있고, 상태는 ‘삽입모드’라고 부른다.
파싱이 끝난 이후의 동작
- 브라우저는 문서와 상호작용할 수 있게 됨.
- ‘지연’ 모드 스크립트를 파싱하기 시작함
- 문서 상태는 ‘완료’가 되고, ‘로드’ 이벤트가 발생한다.
브라우저의 오류처리
- 브라우저는 HTML 의 모든 오류구문을 교정해준다.
- 파서는 적어도 ㄷ음과 같은 오류를 처리해야함
 - 어떤 태그의 안쪽에 추가하려는 태그가 금지된 것일 때, 일단 허용된 태그를 먼저 닫고 금지된 태그는 외부에 추가한다.
 - 파서가 직접 요소를 추가해서는 안된다. 문서 제작자에 의해 뒤늦게 요소가 추가될 수 있고 생략 가능한 경우도 있다. HTML, HEAD, BODY, TBODY, TR, TD, LI 태그가 이런 경우에 해당한다.
 - 인라인 요소 안쪽에 블록 요소가 있는 경우 부모 블록 요소를 만날 때까지 모든 인라인 태그를 닫는다.
 - 이런 방법이 도움이 되지 않으면 태그를 추가하거나 무시할 수 있는 상태가 될 때까지 요소를 닫는다.
- ex)
 - 대신 
 - 어긋난 표
 - 중첩된 폼요소
 - 태그 중첩이 너무 깊을 때
 - 잘못 닫힌 html 또는 body 태그
CSS 파싱
- CSS는 문맥 자유 문법. 즉 위에서 설명한 파서로 파싱 가능하다.
- 웹킷 CSS 파서 : 플렉스와 바이슨 파서 생성기 사용
- 게코 : 하향식 파서 사용
스크립트와 스타일 시트 진행 순서
- 스크립트
  - 웹은 파싱과 실행이 동시에 수행되는 동기화 모델임.
  - 제작자는 파서가 script 태그를 만나면 즉시 파싱하고 실행하기를 기대한다.
  - 스크립트가 실행되는 동안 문서의 파싱은 중단됨
  - 제작자가 스크립트를 ‘지연(defer)’로 표시하면 문서파싱은 중단되지 않고 문서 파싱이 완료된 이후에 스크립트가 실행된다.
  - HTML5는 스크립트는 비동기로 처리하는 속성을 추가했기 때문에 별도의 맥락에 의해 파싱되고 실행됨.
- 예측 파싱
  - 스크립트를 실행하는 동안 다른 스레드는 네트워크로부터 다른 자원을 찾아 내려받고 문서의 나머지 부분을 파싱한다.
  - 예측 파서는 DOM 트리를 수정하지 않고 메인파서의 일로 넘긴다.
- 스타일 시트
  - 이론적으로 스타일 시트는 DOM 트리를 변경하지 않기 때문에 문서파싱을 기다리거나 중단할 이유가 없음
  - 그러나 스크립트가 문서를 파싱하는 동안 스타일 정보를 요청하는 경우라면 문제가 됨.
  - 파이어폭스는 로드 중이거나 파싱 중인 스타일 시트가 있는 경우 모든 스크립트의 실행을 중단함.
  - 웹킷은 로드되지 않은 스타일 시트 가운데 문제가 될만한 속성이 있을 때에만 스크립트를 중단함.

렌더 트리 구축

DOM 트리가 구축되는 동안 브라우저는 렌더 트리를 구축함.
- 표시해야 할 순서와 문서의 시각적인 구성요소로써 올바른 순서로 내용을 그려낼 수 있도록 하기 위한 목적
- 파이어폭스에선 “형상(Frame)”이라 부르고, 웹킷은 “렌더러” 또는 “렌더 객체”라고 부른다.

렌더러

렌더러는 자신과 자식 요소를 어떻게 배치하고 그려내야하는지 알고 있음.

웹킷 렌더러 기본 객체 : RenderObject 클래스

class RenderObject { virtual
    void layout(); virtual
    void paint(PaintInfo); virtual
    void rect repaintRect();
    Node * node; //the DOM node
    RenderStyle * style; // the computed style
    RenderLayer * containgLayer; //the containing z-index layer
}

각 렌더러는 CSS2 명세에 따라 노드의 CSS 박스에 부합하는 사각형을 표시함.
렌더러는 너비, 높이와 같은 기하학적 정보를 포함함.
박스유형은 노드와 관련된 display 스타일 속성의 영향을 받는다.
요소 유형도 고려해야함.
- ex) 폼 컨트롤과 표는 특별한 구조이다.
- 요소가 특별한 렌더러를 만들어야 한다면 웹킷은 createRenderer 메서드를 무시하고 비기하학 정보를 포함하는 스타일 객체를 표시함.

Dom 트리와 렌더 트리의 관계
- 렌더러는 DOM 요소에 부합하지만 1:1로 대응하지는 않는다.
  - 예를들어 head나, display:none 으로 할당된 요소는 트리에 나타나지 않는다.
  - visibility :hidden 은 나타난다.
- 여러개의 시각 객체와 대응하는 DOM 요소도 있다.
  - ex) select 요소 : ‘표시영역, 드롭다운 목록, 버튼’을 위한 3개의 렌더러가 있음.
  - 한줄에 표시할 수 없는 문자가 여러 줄로 바뀔때 새 줄은 별도의 렌더러로 추가됨.
- 어떤 렌더객체는 DOM 노드에 대응하지만 트리의 동일한 위치에 있지 않다.
  - float 처리된 요소 / position:absolute 처리된 요소 등은 흐름에서 벗어나 트리의 다른 곳에 배치된 상태로 그려짐.
  - 대신 자리표시자가 원래 있어야할 곳에 배치된다.
트리를 구축하는 과정
- 파이어폭스 : 프레젠테이션을 DOM 업데이트를 위한 리스너로 등록함
  - 프레젠테이션은 형상만들기를 FrameConstructor에 위함하고, FrameConstructor는 스타일을 결정하고 형상을 만든다.
- 웹킷 : 스타일을 결정하고 렌더러를 만드는 과정을 ‘attachment’라고 부른다.
  - 모든 DOM 노드에는 attach 메서드가 있다.
  - attachment는 동기적인데, DOM트리에 노드를 추가하면 새 노드의 attach 메서드를 호출함.
- html 태그와 body 태그를 처리함으로써 렌더트리루트를 구성한다.
- 루트렌더 객체 : CSS명세에서 포함블록이라고 불림. 파이어폭스에서는 ViewPortFrame, 웹킷은 RenderView라고 부른다.
  - 문서가 가리키는 렌더 객체이다.
  - 트리의 나머지부분은 DOM 노드를 추가함으로써 구축된다.
스타일계산
- 렌더 트리를 구축하려면 각 렌더 객체의 시각적 속성에 대한 계산이 필요한데 이것은 각 요소의 스타일 속성을 계산함으로써 처리된다.
- 스타일 계산에는 다음과 같은 어려움이 따름.
 - 스타일 데이터는 구성이 매우 광범위한데 수 많은 스타일 속성들을 수용하면서 메모리 문제를 야기할 수 있다.
 - 최적화되어 있지 않다면 각 요소에 할당된 규칙을 찾는 것은 성능 문제를 야기할 수 있다. 예를 들어 이런 복합 선택자가 있다.
 div div div div { … }
 규칙을 적용할 <div> 요소를 확인하려면 트리로부터 임의의 줄기를 선택하고 탐색하는 과정에서 규칙에 맞지 않는 줄기를 선택했다면 또 다른 줄기를 선택해야 한다.
 - 규칙을 적용하는 것은 계층 구조를 파악해야 하는 복잡한 다단계 규칙을 수반한다.
- 이 문제를 어떻게 해결하는가? -> 아래 설명-
- 웹킷 노드 : 스타일 정보 공유
 - 웹킷 노드는 스타일 객체(RenderStyle)를 참조하는데, 일정 조건 아래서 공유할 수 있게한다.
- 파이어폭스 규칙 트리
 - 파이어폭스는 스타일 계산을 쉽게 처리해주는 규칙 트리와 스타일 문맥 트리라고 하는 두 개의 트리를 더 가지고 있다.
 - 스타일 문맥에는 최종값이 저장되어있다.
 - 값은 올바른 순서 안에서 부합하는 규칙을 적용하고, 논리로부터 구체적인 값으로 변환함으로써 계산된다.
 - 노드 사이에서 이 값을 공유함으로써 다시 계산하는 일을 방지한다.
 - 부합하는 모든 규칙은 트리에 저장하는데, 경로의 하위 노드가 높은 우선순위를 갖는다.
 - 규칙 저장은 느리게 처리된다. 트리는 처음부터 모든 노드를 계산하지 않지만 노드 스타일이 계산될 필요가 있을 때 계산된 경로를 트리에 추가한다.
 - 트리가 작업량을 줄이는 방법
 1. 구조체로 분리 :
 - 스타일 문맥을 구조체로 나눈다.
 - 상속할 데이터와 상속하지 않을 데이터를 나눔.
 2. 규칙 트리를 사용하여 스타일 문맥을 계산
 - 어떤 요쇼의 스타일 문맥을 계산할 때 가장 먼저 규칙트리의 경로를 계산하거나 또는 이미 존재하는 경로를 사용한다.
 - 그 다음 새로운 스타일 문맥으로 채우기 위해 경로 안에서 규칙을 적용한다.
 - 가장 높은 우선순위(최하위) 부터 시작하여 구조체가 가득찰 떄까지 트리의 상단으로 거슬러 올라간다.
 - 규칙 노드 안에서 구조체를 위한 특별한 선언이 없다면 상당한 최적화가 가능.
 - 구조체에서 어떤 선언도 발견할 수 없는 경우 구조체는 “상속(inherit)” 타입인데 문맥 트리에서 부모 구조체를 향하면서 구조체를 공유한다.
 - 같은 트리노드를 가리키는 형제 요소가 있는 경우 전체 스타일 문맥이 공유된다.
쉬운 선택을 하기 위한 규칙 다루기
- 인라인 스타일 속성과 HTML 시각적 속성은 자신이 스타일 속성을 가지고 있거나 HTML 소고성을 이용하여 연결할 수 있기 때문에 요소에 쉽게 연결된다.
 1 2 
- 외부 스타일 시트에 선언하거나, style 요소안에서 선언하면 까다로울 수 있다.
 - 스타일 시트를 파싱한 후 규칙은 선택자에 따라 여러 해시맵 중 하나에 추가된다.
 - 선택자가 아이디인 경우 규칙은 아이디 맵에, 클래스인 경우 클래스 맵에 추가된다.
 - 이런 처리 작업을 통해, 필요할때 해당 맵을 찾아보아서 모든 선언을 찾아 볼 필요가 없다.
다단계(cascade) 순서에 따라 규칙 적용하기
- 어떤 규칙과도 일치하지 않는 일부 속성은 부모 요소의 스타일 객체로부터 상속 받는다. 그 외 다른 속성들은 기본 값으로 설정된다.
- 문제는 하나 이상의 속성이 정의될 때 시작되고, 다단계 순서가 이 문제를 해결하게 된다.
- 스타일 시트 다단계 순서 : 낮은 거에서 높은 순
  1. 브라우저 선언 (browser declarations)
  2. 사용자 일반 선언 (user normal declarations)
  3. 저작자 일반 선언 (author normal declarations)
  4. 저작자 중요 선언 (author important declarations)
  5. 사용자 중요 선언 (user important declarations)
- 선택자 특정성
  - CSS2 명세
    - 선택자 없이 ‘style’ 속성이 선언된 것이면 1을 센다. 그렇지 않으면 0을 센다. (=a)
    - 선택자에 포함된 아이디 선택자 개수를 센다. (=b)
    - 선택자에 포함된 속성 선택자(클래스 선택자와 속성 선택자)와 가상 클래스 선택자의 숫자를 센다. (=c)
    - 선택자에 포함된 요소 선택자와 가상 요소 선택자의 숫자를 센다. (=d)
  - 네 개의 연결된 숫자 a-b-c-d 를 연결하면 특정성의 값이 된다.
  - 사용할 진법은 분류 중에 가장 높은 숫자에 의해서 정의된다.(17이면 17진법 사용)
- 규칙 정렬
  - 맞는 규칙을 찾으면, 다단계 규칙에 따라 정렬된다.
  - 웹킷은 목록이 적으면 버블 정렬을 사용하고, 많을 때는 병합정렬을 사용한다.
  - 웹킷은 규칙에 “>” 연산자를 덮어쓰는 방식으로 정렬을 실행한다.
점진적 처리
- 웹킷은 @import를 포함한 최상위 수준의 스타일 시트가 로드되었는지 표시하기 위해 플래그를 사용한다.
- DOM 노드와 시각정보를 연결하는 과정(attaching)에서 스타일이 완전히 로드되지 않았다면 문서에 자리 표시자를 사용하고 스타일 시트가 로드됐을 때 다시 계산한다.

배치(리플로)

크기와 위치정보를 계산하는 것 (렌더러가 생성되어 트리에 추가될 때는 이러한 정보가 없다.)
HTML 은 흐름기반의 배치 모델을 사용함 == 단일 경로를 통해 크기와 위치 정보를 계산할 수 있다는 것을 의미.
- 일반적으로 흐름 속에서 나중에 등장하는 요소는 앞서 등장한 요소의 위치와 크기에 영향을 미치지 않기 때문에 배치는 왼쪽에서 오른쪽으로, 또는 위에서 아래로 흐른다.
- 단, 표는 크기와 위치를 계산하기 위해 하나 이상의 경로를 필요로 하기 때문에 예외가 된다.
배치는 반복되며 HTML 문서의 <html> 요소에 해당하는 최상위 렌더러에서 시작된다.
- 배치는 프레임 계층의 일부 또는 전부를 통해 반복되고, 각 렌더러에 필요한 크기와 위치정보를 계산한다.
- 최상위 렌더러의 위치는 0,0 이고, 뷰포트만큼의 면적을 갖는다.
모든 렌더러는 “배치” 또는 “리플로” 메서드를 갖는데, 각 렌더러는 배치해야할 자식의 배치 메서드를 불러온다.
더티 비트 체제
- 소소한 변경 때문에 전체를 다시 배치하지 않기위해 브라우저는 더티비트 체제를 사용한다.
- 렌더러는 다시 배치할 필요가 있는 요소와 그 자식을 “더티”라고 표시함.
- “더티”와 “자식이 더티” 라는 두가지 플래그가 있다.
전역배치와 점증배치
- 배치는 렌더러 트리 전체에서 일어날 수 있는데 이것을 “전역”배치라고 한다. 다음과 같은 상황에서 발생
  - 글꼴 크기 변경과 같이 모든 렌더러에 영향을 주는 전역 스타일 변경
  - 화면 크기 변경에 의한 결과
- 점증 배치 : 렌더러가 더티일 때 비동기적으로 일어남.
비동기 패치와 동기배치
- 전역배치 : 동기적으로 실행.
- 점증배치 : 비동기적으로 실행
  - 파이어폭스 : 리플로 명령을 쌓아놓고 스케줄러는 이 명령을 한꺼번에 실행함.
  - 웹킷 : 타이머가 존재하고, 트리를 탐색하여 더티 렌더러를 배치한다.
최적화
- 배치가 크기변경 또는 렌더러 위치변화 때문에 실행되는 경우, 렌더러는 크기는 다시 계사나하지 않고 캐시로부터 가져온다.
- 입력필드에 틱스트를 입력하는 경우와 같이 변화범위가 한정적이어서 주변에 영향을 끼치지 않을 경우, 하위트리만 수정이 되고 최상위로부터 배치가 시작되지 않음
배치과정
1. 부모 렌더러가 자신의 너비를 결정.
2. 부모가 자식을 검토.
  1. 자식 렌더러를 배치(자식의 x와 y를 설정)
  2. (부모와 자식이 더티하거나 전역 배치 상태이거나 또는 다른 이유로) 필요하다면 자식 배치를 호출하여 자식의 높이를 계산한다.
3. 부모는 자식의 누적된 높이와 여백, 패딩을 사용하여 자신의 높이를 설정한다. 이 값은 부모 렌더러의 부모가 사용하게 된다. -> 즉 높이는 자식에서부터 계산이 된다.
4. 더티 비트 플래그를 제거한다.
- 파이어폭스는 상태객체(nsHTMLReflowState)를 배치하기 위한 매개변수로 사용하는데, 상태는 부모의 너비를 포함한다
- 파이어폭스 배치늬 결과는 매트릭트 객체(nsHTMLReflowMatrics)인데, 높이가 계산된 렌더러를 포함한다.
너비계산
- 렌더러의 너비는 포함하는 블록의 너비, 렌더러의 너비와 여백, 테두리를 이용하여 계산된다.
- 웹킷 계산
  1. 컨테이너의 너비는 컨테이너 availableWidth와 0 사이의 최대값이다. 이 경우 availableWidth는 다음과 같이 계산된 contentWidth이다.
    clientWidth() - paddingLeft() - paddingRight()
    clientWidth와 clientHeight는 객체의 테두리와 스크롤바를 제외한 내부 영역을 의미한다.
  2. 요소의 너비는 “width” 스타일 속성의 값이다. 이 컨테이너 너비의 백분률 값은 절대 값으로 변환될 것이다.
  3. 좌우측 테두리와 패딩 값이 추가된다.
- 위는 미리 획득한 너비의 계산.
- 최소 너비와 최대너비 계산
  - 미리 획득한 너비가 최대 너비보다 크면 최대너비가 사용된다.
  - 미리 획득한 너비가 최소 너비보다 작으면 최소너비가 사용된다.
- 배치할 필요가 있지만 너비가 고정된 경우 값은 캐시에 저장된다.
줄바꿈
- 렌더러가 배치되는 동안 줄을 바꿀 필요가 있을 때 배치는 중단되고 줄 바꿀 필요가 있음을 부모에게 전달함.
- 부모는 추가 렌더러를 생성하고 배치를 호출함.

그리기

화면에 내용을 표시하기 위한 렌더 트리가 탐색되고 렌더러의 “paint” 메서드가 호출됨. 그리키는 UI 기반의 구성요소를 사용한다.
전역과 점증
- 배치와 마찬가지로 전역 또는 점증 방식으로 수행됨.
- 점증 그리기 : 일부 렌더러는 전체 트리에 영향을 주지 않는 방식으로 변경됨.
  - 변경된 렌더러는 화면 위의 사각형을 무효화하는데 OS는 이것을 더티영역으로 보고 paint 이벤트를 발생시킨다.
  - OS는 몇 개의 영역을 하나로 합치는 방법으로 효과적으로 처리한다.
  - 크롬은 렌더러가 별도의 처리 과정이기 때문에 더 복잡하다. OS의 동작을 어느정도 모방하는 방식
  - 파이어폭스 프레젠테이션은 이런 이벤트를 리슨하고 렌더 최상위로 메시지를 전달한다.
    - 그러면 트리는 적절한 렌더러에 이를 때까지 탐색되고 스스로 다시 그러진다.
그리기 순서
- CSS2 명세에 정의되어있음.
  1. 배경 색
  2. 배경 이미지
  3. 테두리
  4. 자식
  5. 아웃라인
파이어폭스 표시 목록
- 파이어폭스는 렌더트리를 검토하고 그려진 사각형을 위한 표시목록을 구성한다.
- 목록은 올바른 그리기 순서에 따라 사각형을 위한 적절한 렌더러를 포함함.
- 이런 방법으로 트리는 여러번 리페인팅을 실행하는 대신 한번만 탐색한다.
- 최적화 : 다른 불투명 요소 뒤에 완전히 가려진 요소는 추가하지 않는 방법으로 최적화를 진행
웹킷 사각형 저장소
- 기존의 사각형을 비트맵으로 저장하여 새로운 사각형과 비교하고 차이가 있는 부분만 다시 그린다.

동적변경

브라우저는 변경에 대해 가능한 한 최소한의 동작으로 반응하려고 한다.
- 요소의 색깔이 바뀌면 해당 요소의 리페인팅만 발생한다.
- 요소의 위치가 바뀌면 요소와 자식, 형제의 리페인팅과 재배치가 발생.
- DOM 노드를 추가하면 노드의 리페인팅과 재배치가 발생
- html 요소의 글꼴 크기를 변경하는 것과 같은 큰 변경은 캐시를 무효화하고 트리 전체의 배치와 리페인팅 발생

렌더링 엔진의 스레드

렌더링 엔진은 통신을 제외한 거의 모든 경우에 단일 스레드로 동작함.
파이어폭스와 사파리의 경우 렌더링 엔진의 스레드는 브라우저의 주요 스레드에 해당함.
크롬에서는 탭 프로세스의 주요 스레드임.
통신은 몇개의 병렬 스레드에 의해 진행될 수 있는데, 병렬 연결의 수는 보통 2개에서 6개로 제한.
이벤트순환
- 브라우저의 주요 스레드는 이벤트 순환으로 처리과정을 유지하기 위해 무한 순환된다.
- 배치와 그리기 같은 이벤트를 위해 대기하고 이벤트를 처리함.

CSS2 시각모델

캔버스
- CSS2 명세에선 “서식 구조가 표현되는 공간”이라고 설명됨. 브라우저가 내용을 그리는 공간이라는 뜻
- 캔버스 공간 각각의 면적은 무한하지만 브라우저는 뷰포트의 크기를 기초로 초기너비를 결정함.
- 캔버스는 기본적으로 투명하기 때문에 다른 캔버스와 겹치는 경우 비쳐보이고, 투명하지 않을 경우에는 브라우저에서 정의한 색이 지정됨.
CSS 박스 모델
- CSS 박스모델은 문서 트리에 있는 요소를 위해 생성되고, 시각적 서식 모델에 따라 배치된 사각형 박스를 설명함.
- 각 박스는 콘텐츠영역(문자, 이미지 등)과 패딩과 테두리, 여백이 있다.
- 각 노드는 이런 박스를 0에서 n개 생성한다.
- 모든 요소는 만들어질 박스의 유형을 결정하는 display 속성을 갖는데, 이 속성의 유형은 다음과 같다.
  - block - 블록 상자를 만든다.
  - inline - 하나 또는 그 이상의 인라인 상자를 만든다.
  - none - 박스를 만들지 않음.
- 기본 값은 인라인이지만 브라우저의 스타일 시트는 다른 기본값을 설정함. 예를 들어 “div” 요소의 기본값은 block이다.
위치 결정방법
- 세가지
  1. Normal - 객체는 문서 안의 자리에 따라 위치가 결정된다. 이것은 렌더 트리에서 객체의 자리가 DOM 트리의 자리와 같고 박스 유형과 면적에 따라 배치됨을 의미한다.
  2. Float - 객체는 우선 일반적인 흐름에 따라 배치된 다음 왼쪽이나 오른쪽으로 흘러 이동한다.
  3. Absolute - 객체는 DOM 트리 자리와는 다른 렌더 트리에 놓인다.
- position속성과 float 속성에 의해 결정된다.
- 박스가 배치되는 방법은 다음과 같은 방법으로 결정된다.
  1. 박스 유형(display, inline …)
  2. 박스 크기(width, height …)
  3. 위치 결정 방법(position, float)
  4. 추가적인 정보 - 이미지 크기와 화면 크기 등
박스 유형
- 블록박스 : 브라우저 창에서 사각형 블록을 형성한다.
- 인라인박스 : 블록이 되지 않고 블록 내부에 포함된다.
- 블록은 다른 블록 아래 수직으로 배치되고, 인라인은 수평으로 배치된다.
- 인라인 박스는 “라인박스” 안쪽에 놓인다. 라인은 적어도 가장 큰 박스만큼 크지만, baseline 정렬일 때 더 커질 수 있다. 이것은 요소의 하단이 다른 상자의 하단이 아닌 곳에 배치된 경우를 의미함.
- 포함하는 너비가 충분하지 않으면 인라인은 몇 줄의 라인으로 배치되는데 이것은 보통 문단 안에서 발생한다.
위치잡기
- 상대적인 위치
- 플로트 : 플로트 박스는 라인의 왼쪽 또는 오른쪽으로 이동함. 다른 박스는 이 주변을 흐른다.
- absolute, fixed : 일반적인 흐름과 무관하게 결정됨.
층 표현 : z-index 속성에 의해 명시됨.
- 뒤쪽 요소가 먼저 그려지고 앞쪽 요소는 사용자에게 가까운 쪽으로 나중에 그려진다.
- 가장 앞쪽에 위치한 요소는 겹치는 이전 요소를 가린다.

출처

https://d2.naver.com/helloworld/59361

브라우저 동작원리

기본 구조

렌더링 엔진

파싱과 DOM 트리 구축

HTML 파서

렌더 트리 구축

배치(리플로)

그리기

동적변경

렌더링 엔진의 스레드

CSS2 시각모델

출처

Further Reading

bfcache

Content-Disposition

STOMP

Trending Tags