design.rendering

monqueror一个很具有参考价值的源玛

Some thoughts about khtml's new arcitecture:

Old HTML*Impl classes will be split so that all layouting and
rendering methods (layout(), updateSize(), calcMinMaxWidth(),
setAvailableWidth(),  print(), printObject()...) will be moved to
new rendering classes. There will be a  rendering class for each
value of css2 'display' attribute. Some others (#text, replaced
elements...) will also get their own rendering classes.

All attribute values used for layouting and rendering are kept in
the style objects. Style objects are implemented as copy-on-write
objects. The values are shared with the styles parent style as long
as no values are changed. The values are divided to groups 
( box, text, border, table...) and only when a value within a group is 
changed, that groups data object is copied.


<lars>
We have to do an additional division here. Some properties are inherited, 
some others aren't. So we only have to copy the values, which get 
inherited from the parent. Others will get set, if a style sheet
defines a value for it, otherwise one should use the default values.
For example the background color/image isn't inherited, so the style
derived from the parent elements style shouldn't have it set. We should 
only have inherited values in the "copy on write" classes, since we
might run into trouble otherwise.
</lars>

<antti>

A background color is not inherited, but it is cascaded. After
P { background-color: red } all P elements have red background, whether
or not they have align=left or right. It certainly makes sense to
have only one copy of bg attributes for all P elements in the document.

Style objects are not meant to be the same thing as style sheets. They
are simply data objects for the rendering system and are constructed
and filled by other objects. It might make sense, however, to have
copy operation based on css inheritance rules in addition to simple
copy constructor.

</antti>

<lars>
One big problem we have is, that usually (in almost all cases), only
computed values are inherited, not the defined ones.

So if e.g. an indent is set to 2.5em, then one has to convert the
2.5em to pixels, and only the pixel value is inherited.

For some properties the calculation is trivial and can be done directly.
In this case, the values in style.h can be absolute pixel values instead 
of Length type values. For some others, like margins, the calculation might
be more complex, and might have to be done at layouting time. Then
Length type values are more appropiate.
</lars>

<antti>

The rendering subsystem operates only with pixel and 
percentage values (otherwise big changes are required). Everything 
else is converted to this form before the style object is constructed. 
The conversion should probably be done by CSS2 classes that make
the style objects.

</antti>


The base parent style is defined by the documents style sheet, or
document types default style sheet. This style is then used as a
base for element specific styles and these are futher modified by
local style definitions, element attributes or by  scripts. 

<lars>
I will provide a method, which returns the style object to use given
the parents style object, and the sum of all style sheets. So the 
renderer/parser will just have to do a  CSSObject->getStyle(this)
to receive the correct style object. This is IMO the cleaner
solution, and it's also more flexible, since the Selector used 
in the style sheet might be something weird ( table.special td[bgcolor=red] 
for example). So the style object might have to look up parent elements and
attributes, to be able to decide if a certain rule applies to the element
or not.
</lars>

<antti>
Yep, this is ok. I was not trying to explain the implementation, only
what should generally happen. I was thinking that this could be somehow
analogous to the (old) rendering system; instead of painter, CSS2 tree 
"renders" itself to a style object. The element type/classes act as
coordinates. (might be reeeeally far of...:)

</antti>

Every rendered DOM object has a pointer to a rendering object.  When
a HTML DOM  object is added to the document tree, it gets a style
object that matches its class,  parses its attributes and modifies
the style object accordingly. Then it sends the style object to its
parent elements rendering object. The rendering object reads the
value of 'display' and constructs and adds a suitable child
rendering object(s).  The pointer to created rendering object is
returned to the HTML DOM element, and is stored.

All data needed to layout an element is kept in the style objects.

The layouting and rendering in the rendering tree works pretty much
as it used to with *Impl objects. In the beginning of layout()
frequently accessed attribute values  may be fetched and temporaliry
stored to the rendering object. In the end the possible calculated
attribute values are stored back to the style object.

<lars>
Don't think we will need that. Attribute values are never modified by
the layouting process. What gets calculated is the actual geometry
of the element. I would store this information in the rendering object.
</lars>

<antti>
You are probably right about this
</antti>

Scripting and event are done in the DOM (not rendering) tree. The
DOM objects may for example ask element position from their
rendering objects to invoke  mouse events. Modification to element
attributes by a script are done by modifying the elements style
object. Similary, the attribute values can be read from the  style
object. However if value of elements 'display' attribute is changed,
the rendering tree must be at least partially reconstructed.

<lars>
The attribute values need to be stored in the DOM only. We'd be
asking for trouble if we started storing them in the style objects.
Attributes are not inherited, just the influence they might have
on rendering is. So the way to do this is to store them in the DOM, 
and everytime an attribute gets modified, it'll look if it has to modify
style object, and if yes, force a relayouting.
</lars>

<antti>

Yes, this is correct. The modification should be done to DOM object 
and then reflected to style object if needed.

</antti>

/// Replaced elements? Text elements?


  Antti



Example:

<html>
    <head>
    	<style> P { color: red } </style>
    </head>
    <body>
    	<p align=center> Jee </p>
    </body>
</html>

The default style for the p element is defined by the html4 default
stylesheet. The document stylesheet modifies this default style.

    Style* pStyle = new Style( defaultStyles->style("P") );
    pStyle->setColor(QT::Red); docStyles->setStyle("P",pStyle);

When the DOM P element is constructed it gets the document
style for P

    _style = docStyles->styleFor("P");

The element attributes modify this style object further

    _style->setTextAlign(CENTER);

This style object is then passed to nodes partent's (BODY) rendering
object, which constructs the rendering object for the P element.

    _parent->renderer()->add(_style);

<lars>
Unfortunately it's not that easy due to the complex selection rules one 
might have. But see my proposal above for getting the right style object.
</lars>