I would like to know about the "dom tree" and "render tree" difference ?
Is the render tree constructed from the "dom tree" or It is different tree made by browser ?
Great question. The DOM tree is essentially the tree containing all of your HTML elements (nodes), whereas the render tree is a culmination of the DOM and CSSOM trees. The render tree is the one that is actually rendered onto the page. Hope this helps! I have written an article about this, check it out :)
http://www.jjburton.com/2016/02/12/web-science-browser-internals-rendering.html
The big question...'How does the browser render a web page?'. Before starting, let's quickly answer some sub-questions:
These are some very good articles, I think you should read first!
What Every Frontend Developer Should Know About Webpage Rendering
http://frontendbabel.info/articles/webpage-rendering-101/
How browsers work : Behind the scenes of modern web browsers
http://taligarsiel.com/Projects/howbrowserswork1.htm
Render-tree Construction, Layout, and Paint
https://developers.google.com/web/fundamentals/performance/critical-rendering-path/render-tree-construction
hope for help for you!
Render tree is created by combining the DOM tree (Made from parsing the HTML) and CSSOM(Made from parsing the CSS defined for the document) tree.
Render tree only contains the nodes which will be visible on the screen, i.e. if the display for any of the node is marked as none then it won't be the part of the render tree.
Render tree is then passed to the layout phase and eventually to the paint phase which paints the actual pixels on the screen and the content is visible to you.
To answer your question: Both dom tree and render tree is created by the browser only and yes render tree is made from the dom tree as explained above.
Related
Good day!
Can someone tell me how to make courses on the main page in the form of tiles in the Boost theme? For example, as it is done in the Adaptable theme (picture below).
I thought that the output is through a mustache template, but I could not find where this happens and how to change it.
In what files is the list of courses formed and its appearance for the main page determined?
Does implementing Shadow DOM in my projects will make them faster like virtual DOM that's used by React?
They are different things for different purposes, so comparing performance doesn't make sense.
Virtual DOM
Virtual DOM is about avoiding unnecessary changes to the DOM, which are expensive performance-wise, because changes to the DOM usually cause re-rendering of the page. Virtual DOM also allows to collect several changes to be applied at once, so not every single change causes a re-render, but instead re-rendering only happens once after a set of changes was applied to the DOM.
Shadow DOM
Shadow dom is mostly about encapsulation of the implementation. A single custom element can implement more-or-less complex logic combined with more-or-less complex DOM. An entire web application of arbitrary complexity can be added to a page by an import and <body><my-app></my-app> but also simpler reusable and composable components can be implemented as custom elements where the internal representation is hidden in the shadow DOM like <date-picker></date-picker>.
Style encapsulation
Shadow DOM is also about preventing styles being applied accidentally to elements the designer didn't intend to, for example because the CSS or components library you are using changed a selector that now applies to other elements that use the same CSS class names. Styles added to components are scoped to that component and bleeding out or in of styles is prevented.
Shadow DOM and performance
Even though shadow DOM is not about performance in the first place it also has performance implications. Because styles are scoped, the browser can make assumptions about some changes to affect only a limited area of the page (the shadow DOM of a custom element) which can limit re-rendering to the area of such a component, instead of re-rendering the entire page.
This is the reason the >>>, /deep/, and ::shadow CSS combinators, which allowed to apply styles across shadow DOM boundaries, were deprecated and are subject to be removed soon from Chrome (other browsers never had them AFAIK). The mere existence of these combinators prevents the kind of optimization mentioned in the previous paragraph.
Angular2 uses the advantages of both worlds.
It uses unidirectional data flow and runs change detection on the model only. If it detects changes it causes the DOM to be updated by updating bindings and make structural directives like *ngFor, *ngIf, ... update the DOM. Therefore the DOM is only updated when the model actually changed.
Angular2 uses shadow DOM (only with ViewEncapsulation.Native which is currently not the default) to utilize style encapsulation capabilities provided by the browser, or (current default) just emulate style encapsulation by rewriting styles added to components, as a workaround until native shadow DOM and CSS variables (for dynamic global style changes) become widely available.
No, Shadow DOM and Virtual DOM are unrelated, although somewhat similarly named:
Virtual DOM: React concept of keeping two copies of the DOM (the original, and the updated) for differential reasons. Before rendering, React diffs the two objects to determine if it should apply an update(s) to the actual DOM tree. This results in boosted performance, as we're only updating the portions of the view that require it, not the entire screen.
Shadow DOM: Part of the Web Components spec as proposed by W3C, which basically allows the encapsulation of smaller DOM elements and CSS styles into a single DOM element:
Example Shadow DOM Element
<my-video width="300" height="150" />
However, <my-video> actually encapsulates the following elements:
<div>
<input type="button" style="color: blue;">Play
<input type="button" style="color: red;">Pause
<source src="myVideo.mp4">
</div>
So by using Shadow DOM, we're able to hide the implementation details of our web element, and only pass along necessary information to the sub-elements (i.e. height, width), which, perhaps confusingly, strongly resembles the ReactJS idiom of passing props to components.
Information provided via:
http://www.funnyant.com/reactjs-what-is-it/
http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/
I use the sitemap content element so that the editor can explicitly reference to individual pages in my page tree. Of course those pages do contain content elements (Textpic, Media, all the good stuff...) in their "normal" section. I need advice on how to modify the sitemap content element that it will output the content of the referenced pages.
I know there is already a plugin called "kb_sitemap" which basicaley does this job... but it does not handle the output of images or media (flash-, quicktime movies..) elements which is absolute necessary. The rendering relevant stuff is handled by Css Styled Content (CSC) which is necassary for me because it renders the media content element.
Do you use templavoila ?
Ok, go to page properties -> General tab (bottom part of the tab) and then you'll find all containers that possibly contain CEs, click to the lil folder icon and you may select content elements from any other page.
EDIT: added screenshot, page properties...
Note, showcase, maincontent, right content are just my names for my TV elements, could of course be name differently.
I have a task where I need to segment a web page visually so that I may be able to calculate the distance between two segments of the web page at various levels of the DOM tree. In the simple way I want to be able to obtain the boxes that enclose the display of the pages on the screen. e.g. consider this image: Image to visual of DOM structure as on display
This I drew using Chrome, which provides for each DOM node the corresponding rectangle on the display of the page in the browser. How can I get these boxes in my program so that I can process the page based upon how it looks on the screen.
I was able to do so by using QtWebkeit. It provides for each level of DOM tree the geometry() method and also access to the CSS properties.
I'm fighting to understand the weird behavior of GWT Layout Panels. I'm wondering how GWT translate Layout logic into javascript and html. sometimes we don't get the expected Layout . something under the cover is done by GWT compiler.
the GWT documentation is not clear enough on how Layout is performed under the cover.
is there some good books or tutorials that explains well the GWT Layout issues?
thanks.
I don't know about good books or tutorials but here's a little information that may be helpful.
First, as you may know there's a big difference between the FooPanels and the FooLayoutPanels. These are two different sets of panels that are based on different layout mechanisms. The Layout Panels are the new stuff that seems to be suited better for layouts that have hard-coded sizes, Google Wave style. The older FooPanels (VerticalPanel, etc.) are based on HTML tables mostly.
FlowPanel - this is simply something that outputs your widgets as successive HTML elements in a single DIV. As documented: "A panel that formats its child widgets using the default HTML layout behavior".
DockLayoutPanel - Looking at the code shows that it hard-codes the sizes of the different regions according to what you specify in the children (north, east, etc.)
Finally - my experience has led me to abandon all usage of the Layout Panel system and rely only on HTML and CSS wherever I can. This means using HTMLPanel + UiBinder mostly and sometimes FlowPanel, rarely also some of the other panels.
Trying to understand and battle the Layout Panel system to do things that are not the "default case" was a waste of time. I'm not saying it's the best thing to do, but I just couldn't get the kind of control I wanted without this - especially with regard to elements that should automatically expand vertically. If you haven't already, take note of this from the GWT documentation about Layout Panels:
The panels described above are best used for defining your application's outer structure — that is, the parts that are the least "document-like". You should continue to use basic widgets and HTML structure for those parts for which the HTML/CSS layout algorithm works well. In particular, consider using UiBinder templates to directly use HTML wherever that makes sense.