Comments 30
Надо отметить что иметь отдельное RenderingTree совсем не обязательно.
В Sciter например DOM element содержит как список DOM nodes так и layout controller — список дочерних объектов для размещения и отображения. У параграфа свой text layout controller, а у div, который содержит блочные элементы, — block vertical layout controller. У таблиц — свой и т.д. Такая архитектура более компактна помимо всего прочего.
В Sciter например DOM element содержит как список DOM nodes так и layout controller — список дочерних объектов для размещения и отображения. У параграфа свой text layout controller, а у div, который содержит блочные элементы, — block vertical layout controller. У таблиц — свой и т.д. Такая архитектура более компактна помимо всего прочего.
+1
Спасибо за живое авторское изложение простых, но важных моментов. А запись упомянутого вебинара имеется? Или это внутренний ресурс DataArt?
+2
Спасибо. Полезная статья. В дереве отображения не указан элемент html. Однако он явно отображается во всех упомянутых браузерах, т.к. мы можем повлиять на него с помощью правил CSS. Однако указан некий root. Скажите, root == html? Или в схеме ошибка?
0
Здесь все же будет не совсем правильно приравнивать узел root в дереве отображения к узлу html в DOM-дереве. Дерево отображения отвечает за то, что отображается на экране, т. е. за то, что находится в данный момент во viewport. А узел html может включать элементы, которые во viewport в тот или иной момент времени не попадают. Поэтому равенство здесь не совсем корректно.
Другими словами, узел root дерева отображения соответствует viewport браузера.
Другими словами, узел root дерева отображения соответствует viewport браузера.
0
Но узел body тоже может включать в себя такие элементы, а на схеме он есть.
0
Да, верно. Но дерево отображения и DOM-дерево все-таки две разных структуры, несмотря на то, что можно провести соответствие. Схема показывает, что есть соответствие между узлами в DOM-дереве и узлами в дереве отображения. И, например, в дереве отображения есть какой-то узел, который так или иначе соответствует узлу body в DOM-дереве. Но я бы осторожно ставил знак равенства между ними. В источнике, из которого я брал, корневой элемент указан как root, возможно, как раз чтобы подчеркнуть, что аналогия с узлом html неполная, и нужно иметь ввиду, что он соответствует viewport, а не документу.
0
Спасибо, что уделяете время. Можно ссылку на источник? Я пока что всё равно не понимаю. Про DOM-дерево я ничего не говорю. И про root элемент на минуту забудем. Вот эта картинка (https://habrastorage.org/files/f8b/efd/ac0/f8befdac02e04eab9eb3ed56e483f4bc.jpg) из вашей статьи. Правая часть. Дерево отображения. В дерево включён элемент body, но не включён html, и я не пойму, почему. Они оба находятся во viewport, всё время. Оба включают в себя элементы, которые во viewport время от времени не попадают. Фактически, для большинства веб-страниц, html и body совпадают по расположению в браузере.
0
Browser/rendering engine — резанул уши «механизм браузера» — звучит отвратительно (browser mechanism, представляется эдакий тормознутый 30км/ч трактор). В профессиональной среде (где использовать слэнг между коллегами разрешено) engine переводится как «движок» (например, unreal engine, game engine, rendering engine — все движки). «Браузер» ведь почему-то оставили (не стали «переводить» его как «просмотрщик» там или еще как)…
+2
Про async написана неправда, script2 никак не может быть выполнен раньше script1, async указывает только на асинхронные загрузку и выполнение, все происходит в том же самом потоке, ничего параллельного здесь нет. Тем более, если у script1 нет атрибута async, то браузер даже не начнет парсить строку script2.
0
Спасибо за замечание. Здесь действительно недочет. Script5.js (я так понимаю, вы про него, а не про script2) не может выполниться раньше script1.js, т. к. анализ документа блокируется на время выполнения script1.js. Упустил, что script1.js без атрибута async здесь. Исправил в тексте.
По моим данным, выполнение script5.js все же происходит в другом потоке.
По моим данным, выполнение script5.js все же происходит в другом потоке.
0
Как оно должно быть описано в спецификации: html spec attr script async
0
ошибка здесь «Но при этом он выполняется в параллельном потоке». Параллельно выполняется загрузка, но не скрипт.
> По моим данным, выполнение script5.js все же происходит в другом потоке.
У вас неверные данные, можно достаточно просто проверить. https://plnkr.co/edit/6wHGeCMXQsR3zhKYoPRm
здесь, если script.js загрузится раньше script2.js и начнет выполняться, script2.js будет ждать своей очереди, и наоборот. И это очень правильно, т.к. никто в js не ожидает параллельного выполнения в одной области видимости. Исключение — background script+debugger, но это баг.
> По моим данным, выполнение script5.js все же происходит в другом потоке.
У вас неверные данные, можно достаточно просто проверить. https://plnkr.co/edit/6wHGeCMXQsR3zhKYoPRm
здесь, если script.js загрузится раньше script2.js и начнет выполняться, script2.js будет ждать своей очереди, и наоборот. И это очень правильно, т.к. никто в js не ожидает параллельного выполнения в одной области видимости. Исключение — background script+debugger, но это баг.
0
Заранее извиняюсь за грубость! Очень неприятно, что автор не указал источник статьи taligarsiel.com/Projects/howbrowserswork1.htm (2009 года), а выдает как «свой вебинар». За проведенную работу по переводу конечно же огромное спасибо, но очень прошу, указывайте ссылки на используемые источники!
0
Спасибо за бдительность. Как я уже писал, статья основана на вебинаре и состоит из двух частей. Список источников я привел в конце вебинара и планировал его прикрепить ко второй части. Наверное, во избежание подобной ситуации имело смысл его продублировать в обеих частях. Первая часть действительно во многом основана на приведенной статье (на русский она уже давно переведена). Намерения выдавать что-то чужое за свое, тем более, такую известную и широко распространенную информацию, у меня не было.
0
Вы написали
«Стили, в отличие от скриптов, никак не могут повлиять на документ. Если скрипты могут добавить дополнительные узлы или теги, то стили этого сделать не могут. ...»
но как быть с ::before, ::after?
Разве они не могут добавить узлы?
«Стили, в отличие от скриптов, никак не могут повлиять на документ. Если скрипты могут добавить дополнительные узлы или теги, то стили этого сделать не могут. ...»
но как быть с ::before, ::after?
Разве они не могут добавить узлы?
0
UFO just landed and posted this here
Не понял из Вашей статьи, в чем фишка дерева отображения?
Вы писали: «Дерево отображения служит для того, чтобы браузер понимал, что выводить на экран. Оно содержит информацию о том, из каких блоков состоит страница», но ведь в ДОМ-дереве видны всякие текстовые ноды и различные теги. Разница лишь в том, что в дереве отображения нет тега и нет тегов со стилями в параметрах?
Не понял смысла разделять деревья.
Вроде бы и понятно, но… зачем, почему?..
Вы писали: «Дерево отображения служит для того, чтобы браузер понимал, что выводить на экран. Оно содержит информацию о том, из каких блоков состоит страница», но ведь в ДОМ-дереве видны всякие текстовые ноды и различные теги. Разница лишь в том, что в дереве отображения нет тега и нет тегов со стилями в параметрах?
Не понял смысла разделять деревья.
Вроде бы и понятно, но… зачем, почему?..
0
Скажем есть такой markup:
Этот div не содержит блочных элементов поэтому он будет представлен как TextBlockCntr ( или TextBlockRenderer ):
А вот этот markup
будет нормализован в rendering tree как
Где первый TextBlockCntr выше это т.н. anonymous paragraph
<div>Привет Вася</div>
Этот div не содержит блочных элементов поэтому он будет представлен как TextBlockCntr ( или TextBlockRenderer ):
<TextBlockCntr>
Привет Вася
</TextBlockCntr>
А вот этот markup
<div>
Привет Вася
<p>Ты крут!</p>
</div>
будет нормализован в rendering tree как
<VerticalFlowBlockCntr>
<TextBlockCntr>Привет Вася</TextBlockCntr>
<TextBlockCntr>Ты крут!</TextBlockCntr>
</VerticalFlowBlockCntr>
Где первый TextBlockCntr выше это т.н. anonymous paragraph
0
Не все ноды из дома есть в рендеринге и не все ноды из рендеринга есть в доме (например, псевдоэлементы)
+1
UFO just landed and posted this here
UFO just landed and posted this here
Вот это «А display:inline указывает, что ширина прямоугольника...» смысла не имеет. У display:inline нет прямоугольника (border box в технических терминах). Элемент с display:inline содержащий текст это коллекция отдельных glyph boxes.
0
Атрибут 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 выполнится самым последним
0
Sign up to leave a comment.
Важные аспекты работы браузера для разработчиков. Часть 1