Важные аспекты работы браузера для разработчиков. Часть 1

[csmile]

Надо отметить что иметь отдельное RenderingTree совсем не обязательно.

В Sciter например DOM element содержит как список DOM nodes так и layout controller — список дочерних объектов для размещения и отображения. У параграфа свой text layout controller, а у div, который содержит блочные элементы, — block vertical layout controller. У таблиц — свой и т.д. Такая архитектура более компактна помимо всего прочего.

[Vladimir_Sklyar]

Спасибо за живое авторское изложение простых, но важных моментов. А запись упомянутого вебинара имеется? Или это внутренний ресурс DataArt?

[DataArt]

Да, вебинар — часть нашей внутренней образовательной программы. Но совсем скоро мы опубликуем вторую часть статьи на его основе.

[AlexanderY]

Спасибо. Полезная статья. В дереве отображения не указан элемент html. Однако он явно отображается во всех упомянутых браузерах, т.к. мы можем повлиять на него с помощью правил CSS. Однако указан некий root. Скажите, root == html? Или в схеме ошибка?

[DataArt]

Здесь все же будет не совсем правильно приравнивать узел root в дереве отображения к узлу html в DOM-дереве. Дерево отображения отвечает за то, что отображается на экране, т. е. за то, что находится в данный момент во viewport. А узел html может включать элементы, которые во viewport в тот или иной момент времени не попадают. Поэтому равенство здесь не совсем корректно.

Другими словами, узел root дерева отображения соответствует viewport браузера.

[AlexanderY]

Но узел body тоже может включать в себя такие элементы, а на схеме он есть.

[DataArt]

Да, верно. Но дерево отображения и DOM-дерево все-таки две разных структуры, несмотря на то, что можно провести соответствие. Схема показывает, что есть соответствие между узлами в DOM-дереве и узлами в дереве отображения. И, например, в дереве отображения есть какой-то узел, который так или иначе соответствует узлу body в DOM-дереве. Но я бы осторожно ставил знак равенства между ними. В источнике, из которого я брал, корневой элемент указан как root, возможно, как раз чтобы подчеркнуть, что аналогия с узлом html неполная, и нужно иметь ввиду, что он соответствует viewport, а не документу.

[AlexanderY]

Спасибо, что уделяете время. Можно ссылку на источник? Я пока что всё равно не понимаю. Про DOM-дерево я ничего не говорю. И про root элемент на минуту забудем. Вот эта картинка (https://habrastorage.org/files/f8b/efd/ac0/f8befdac02e04eab9eb3ed56e483f4bc.jpg) из вашей статьи. Правая часть. Дерево отображения. В дерево включён элемент body, но не включён html, и я не пойму, почему. Они оба находятся во viewport, всё время. Оба включают в себя элементы, которые во viewport время от времени не попадают. Фактически, для большинства веб-страниц, html и body совпадают по расположению в браузере.

[DataArt]

http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/

[Sinatr]

Browser/rendering engine — резанул уши «механизм браузера» — звучит отвратительно (browser mechanism, представляется эдакий тормознутый 30км/ч трактор). В профессиональной среде (где использовать слэнг между коллегами разрешено) engine переводится как «движок» (например, unreal engine, game engine, rendering engine — все движки). «Браузер» ведь почему-то оставили (не стали «переводить» его как «просмотрщик» там или еще как)…

[VolCh]

Собственно даже в непрофессиональном сленге уже «движок» устоялось, например

[Opaspap]

Про async написана неправда, script2 никак не может быть выполнен раньше script1, async указывает только на асинхронные загрузку и выполнение, все происходит в том же самом потоке, ничего параллельного здесь нет. Тем более, если у script1 нет атрибута async, то браузер даже не начнет парсить строку script2.

[DataArt]

Спасибо за замечание. Здесь действительно недочет. Script5.js (я так понимаю, вы про него, а не про script2) не может выполниться раньше script1.js, т. к. анализ документа блокируется на время выполнения script1.js. Упустил, что script1.js без атрибута async здесь. Исправил в тексте.

По моим данным, выполнение script5.js все же происходит в другом потоке.

[lastmac]

Как оно должно быть описано в спецификации: html spec attr script async

[Opaspap]

ошибка здесь «Но при этом он выполняется в параллельном потоке». Параллельно выполняется загрузка, но не скрипт.

> По моим данным, выполнение script5.js все же происходит в другом потоке.
У вас неверные данные, можно достаточно просто проверить. https://plnkr.co/edit/6wHGeCMXQsR3zhKYoPRm

здесь, если script.js загрузится раньше script2.js и начнет выполняться, script2.js будет ждать своей очереди, и наоборот. И это очень правильно, т.к. никто в js не ожидает параллельного выполнения в одной области видимости. Исключение — background script+debugger, но это баг.

[DataArt]

Да, согласен. Спасибо, поправил.

[Homcenco]

Заранее извиняюсь за грубость! Очень неприятно, что автор не указал источник статьи taligarsiel.com/Projects/howbrowserswork1.htm (2009 года), а выдает как «свой вебинар». За проведенную работу по переводу конечно же огромное спасибо, но очень прошу, указывайте ссылки на используемые источники!

[DataArt]

Спасибо за бдительность. Как я уже писал, статья основана на вебинаре и состоит из двух частей. Список источников я привел в конце вебинара и планировал его прикрепить ко второй части. Наверное, во избежание подобной ситуации имело смысл его продублировать в обеих частях. Первая часть действительно во многом основана на приведенной статье (на русский она уже давно переведена). Намерения выдавать что-то чужое за свое, тем более, такую известную и широко распространенную информацию, у меня не было.

[Zhyhana]

Вы написали
«Стили, в отличие от скриптов, никак не могут повлиять на документ. Если скрипты могут добавить дополнительные узлы или теги, то стили этого сделать не могут. ...»
но как быть с ::before, ::after?
Разве они не могут добавить узлы?

[VolCh]

нет, в дом они узлов не добавляют, поэтому они и называются «псевдоэлементы» — визуально вроде как полноценные элементы, а в доме их нет.

[DataArt]

Спасибо, поправили опечатку.

[denqa]

Не понял из Вашей статьи, в чем фишка дерева отображения?
Вы писали: «Дерево отображения служит для того, чтобы браузер понимал, что выводить на экран. Оно содержит информацию о том, из каких блоков состоит страница», но ведь в ДОМ-дереве видны всякие текстовые ноды и различные теги. Разница лишь в том, что в дереве отображения нет тега и нет тегов со стилями в параметрах?
Не понял смысла разделять деревья.
Вроде бы и понятно, но… зачем, почему?..

[csmile]

Скажем есть такой markup:

<div>Привет Вася</div> 

Этот div не содержит блочных элементов поэтому он будет представлен как TextBlockCntr ( или TextBlockRenderer ):

<TextBlockCntr> 
   Привет Вася
</TextBlockCntr>

А вот этот markup

<div>
       Привет Вася
        <p>Ты крут!</p>
</div> 

будет нормализован в rendering tree как

<VerticalFlowBlockCntr>
  <TextBlockCntr>Привет Вася</TextBlockCntr>
  <TextBlockCntr>Ты крут!</TextBlockCntr>
</VerticalFlowBlockCntr>

Где первый TextBlockCntr выше это т.н. anonymous paragraph

[VolCh]

Не все ноды из дома есть в рендеринге и не все ноды из рендеринга есть в доме (например, псевдоэлементы)

[csmile]

Вот это «А display:inline указывает, что ширина прямоугольника...» смысла не имеет. У display:inline нет прямоугольника (border box в технических терминах). Элемент с display:inline содержащий текст это коллекция отдельных glyph boxes.

[Opaspap]

забавное следствие из вашего комментария:
https://jsfiddle.net/mnewqLa3/

[IsaNesquik]

Атрибут async тоже говорит браузеру, что дальнейший html-документ может быть проанализирован, пока скрипт выполняется. При этом он загружается в параллельном потоке и выполняется сразу после загрузки.

Выполняется сразу после загрузки — это неверное утверждение.
Приведу пример:

<head>
    <meta charset="UTF-8">
    <title>Async test</title>
    <script  src="file_1.js"></script>
    <script async src="file_5.js"></script>
    <script  src="file_2.js"></script>

    <script>console.log('inline');</script>
</head>
<body>
    <script  src="file_4.js"></script>
</body>

file_5.js с аттрибутом async выполнится самым последним