Please note: the following text is necessarily brief, formal and technical as it is meant to give a quick summary of my intentions for my Master thesis.
Rendering the DOM
Before a browser displays a web page, it loads HTML, Javascript and CSS. The code is interpreted and a Document Object Model is constructed. The DOM represents the data and functionality of the web page and is loaded in RAM memory so that it can be quickly accessed and manipulated. A graphical representation of the DOM is then rendered by browser’s rendering engine.
There is a set of standards defined by the W3C consortium that specify how the DOM should be rendered. The job of rendering is very hard: it needs to be fast, efficient and standards compliant. There are currently several major browsers that all differ in rendering speed and accuracy.
Understanding the rendering
The task of a web developer is to produce a certain graphical layout by using HTML, CSS and Javascript. Doing this well requires an understanding of how the rendering engine interprets the DOM.
In reverse, understanding how a certain layout was achieved (by a third party) can be difficult as well. Because HTML and CSS are flexible, many different solutions are available to achieve a certain layout. One really needs to look at the code to be completely sure how the layout is achieved.
There are tools that make it easier to see the relationship between the code and the graphical representation. For example, Firebug enables you to inspect and compare the code and the graphical representation of that code in the browser simultaneously.
Firebug is a very handy tool for web developers, but it also has a limitation: only one element can inspected at the same time. This can be problematic in some situations. For example, when there are many wrapping elements, it can be laborious to figure out what elements contain markup and how these properties affect the layout as a whole.
I want to introduce a new way of visualizing the code in the graphical representation. This approach allows a web developer to inspect multiple elements at the same time.
Before a browser displays a web page, it loads HTML, Javascript and CSS. The code is interpreted and a Document Object Model is constructed. The DOM represents the data and functionality of the web page and is loaded in RAM memory so that it can be quickly accessed and manipulated. A graphical representation of the DOM is then rendered by browser’s rendering engine.
There is a set of standards defined by the W3C consortium that specify how the DOM should be rendered. The job of rendering is very hard: it needs to be fast, efficient and standards compliant. There are currently several major browsers that all differ in rendering speed and accuracy.
Understanding the rendering
The task of a web developer is to produce a certain graphical layout by using HTML, CSS and Javascript. Doing this well requires an understanding of how the rendering engine interprets the DOM.
In reverse, understanding how a certain layout was achieved (by a third party) can be difficult as well. Because HTML and CSS are flexible, many different solutions are available to achieve a certain layout. One really needs to look at the code to be completely sure how the layout is achieved.
There are tools that make it easier to see the relationship between the code and the graphical representation. For example, Firebug enables you to inspect and compare the code and the graphical representation of that code in the browser simultaneously.
Firebug is a very handy tool for web developers, but it also has a limitation: only one element can inspected at the same time. This can be problematic in some situations. For example, when there are many wrapping elements, it can be laborious to figure out what elements contain markup and how these properties affect the layout as a whole.
I want to introduce a new way of visualizing the code in the graphical representation. This approach allows a web developer to inspect multiple elements at the same time.
A solution: visualizing the DOM hierarchy on the z-axis
The graphical representation of the DOM is confined to two dimensions. The third dimension is effectively not used in web pages (only to remove element from flow). This leaves the third dimension available to visualize the DOM hierarchy. When the graphical representation is extended to use the third dimension, the web page effectively becomes a 3D object.
The x and y positions of elements are defined by the rendering engine. The z position is deduced from the DOM hierarchy. The higher the number of ancestors, the higher the z value.
As there is distance between parent and child elements, it is easy to visually distinct between elements and what markup applies to those elements. The 3D representation is also viewable from different perspectives. This allows for an interaction in which the user can choose to focus on particular parts of the representation by looking at the representation from a certain angle and distance.
For example, when there are several wrapping elements it is hard to quickly see what element contains what markup. In a 3D representation all relevant elements and their markup can be viewed at the same time. This makes the web developer’s job easier
Small HTML snippet styled with CSS.
Same snippet, but visualized through DomScape. The DOM elements are exploded over the z-axis. Padding style is highlighted with yellow.
Plan
There are several aspects to this thesis that need to be researched and developed. First of all, it needs a theoretical foundation. There are standards defined for both HTML and CSS. It needs to be clear on what assumptions this idea relies and whether they are right assumptions.
For example, the CSS attribute ‘overflow’ breaks the pyramidical representation. As this attribute allows an element to be bigger than its parent element, it is harder visualize in a 3D view. It is important to investigate whether there are any other CSS attributes that make a 3D visualization harder or even impossible.
Second, in order to get insight into actual use of such as visualization, it is important to do early testing with prototypes. As this is a new way of visualizing web pages, it will probably pose issues that cannot be imagined at this moment. Prototyping will help identify those issues. Usability testing with potential users will shows possible use cases and functional needs. The goal is to create a few prototypes, that demonstrate the concept.
Third, to make a 3D visualization useful it needs to offer the user more interaction and information than just that. It should visualize certain types of mark up, such as padding and margin, directly in the 3D representation. Also important are the HTML and CSS code and in what lines they apply to an element.
Fourth, it needs to be investigated how such a tool can be implemented. Ideally, the tool would function as a third party plugin to a popular browser, such as Safari, Chrome or Firefox. The tool will need access to the rendering engine to deduce x and y positions of elements, their styling properties and level of ancestry.
For example, the CSS attribute ‘overflow’ breaks the pyramidical representation. As this attribute allows an element to be bigger than its parent element, it is harder visualize in a 3D view. It is important to investigate whether there are any other CSS attributes that make a 3D visualization harder or even impossible.
Second, in order to get insight into actual use of such as visualization, it is important to do early testing with prototypes. As this is a new way of visualizing web pages, it will probably pose issues that cannot be imagined at this moment. Prototyping will help identify those issues. Usability testing with potential users will shows possible use cases and functional needs. The goal is to create a few prototypes, that demonstrate the concept.
Third, to make a 3D visualization useful it needs to offer the user more interaction and information than just that. It should visualize certain types of mark up, such as padding and margin, directly in the 3D representation. Also important are the HTML and CSS code and in what lines they apply to an element.
Fourth, it needs to be investigated how such a tool can be implemented. Ideally, the tool would function as a third party plugin to a popular browser, such as Safari, Chrome or Firefox. The tool will need access to the rendering engine to deduce x and y positions of elements, their styling properties and level of ancestry.
Geen opmerkingen:
Een reactie posten