I'm looking at this section of the Style System Documentation:
https://developer.mozilla.org/en/Mozilla_Style_System_Documentation#Style_contexts_and_the_rule_tree
I realise this is a fairly old document (2003) and if you know a newer
version please let me know.
I wonder if the tree is the "happiest" metaphor for the structure of
the rule tree or if maybe its type should be further qualified/
clarified. When I think to a tree I think to a graph in which each
node has only one parent but may have many children. However, when I
think to a possible rule tree I can only think to a more generalized
directed graph, were a child -may- share more than one parent. In fact
it seems to me that the rule tree is dependent on the structure of the
document and this kind of messes up my brain because it seems to
suggest that every time the document structure changes the rule tree
must be refreshed too. Take these four rules:
1) div {background-color:red}
2) div.blue {color:blue}
3) div.pink {color:pink}
4) div#mark {border:1px solid orange}
To me, the rule tree of these four rules can take all sorts of
different shapes depending on the specifics of the document. Take the
following examples as isolated, in separate documents:
This uses rules 4 and then 1, the rule tree is a simple graph with one
segment:
<div id="mark" />
Uses rules 4, 3 and finally 1, the rule tree is a simple graph with
two consecutive segments:
<div id="mark" class="pink" />
My understanding is that in this case the rule tree is effectively a
diamond, with rule 1 at the top, rule 4 at the bottom and rule 2 and 3
being children of 1 and parents of 4:
<div>
<div id="mark" class="pink" />
<div id="mark" class="blue" />
</div>
Am I correct? Does the rule tree change shape depending on the
structure of the document? Is it true that children rules may
potentially share parent rules? I'm trying to understand how the rule
tree is generated but all I can imagine is, rather than a tree, a
braid of rules, each strand starting with a document's element, each
strand ending at the "null" rule and each strand made of a list of
rules, some of which may or may not be shared by other strands.
Manu
The basic concepts in that section are still true; the comments at
the top of nsRuleNode.h and nsStyleContext.h might be a little more
up-to-date on the details.
> I wonder if the tree is the "happiest" metaphor for the structure of
> the rule tree or if maybe its type should be further qualified/
> clarified. When I think to a tree I think to a graph in which each
The rule tree is is a tree. Every node in the rule tree has exactly
one parent, except for the root, which has none.
> 1) div {background-color:red}
> 2) div.blue {color:blue}
> 3) div.pink {color:pink}
> 4) div#mark {border:1px solid orange}
>
> To me, the rule tree of these four rules can take all sorts of
> different shapes depending on the specifics of the document. Take the
> following examples as isolated, in separate documents:
>
> This uses rules 4 and then 1, the rule tree is a simple graph with one
> segment:
> <div id="mark" />
No, in this case (assuming there are no other elements and no other
style rules) the rule tree has three nodes:
A. the root
B. a node pointing to rule (1), child of (A)
C. a node pointing to rule (4), child of (B)
and the style context for the div points to rule node (C).
> Uses rules 4, 3 and finally 1, the rule tree is a simple graph with
> two consecutive segments:
> <div id="mark" class="pink" />
This case is similar, with 4 nodes.
> My understanding is that in this case the rule tree is effectively a
> diamond, with rule 1 at the top, rule 4 at the bottom and rule 2 and 3
> being children of 1 and parents of 4:
>
> <div>
> <div id="mark" class="pink" />
> <div id="mark" class="blue" />
> </div>
>
> Am I correct? Does the rule tree change shape depending on the
No. There can be multiple rule nodes in the rule tree pointing to
the same rule, and in this case there are (both (D) and (F) point to
rule (4)). In this case the rule tree has six nodes:
A. the root
B. node pointing to rule (1), child of (A)
C. node pointing to rule (2), child of (B)
D. node pointing to rule (4), child of (C)
E. node pointing to rule (3), child of (B)
F. node pointing to rule (4), child of (E)
The style context for the outer div points to rule node (B). The
style context for the class=pink div points to rule node (D). The
style context for the class=blue div points to rule node (F).
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
A follow up question: when are rule nodes and style contexts
instantiated and who is responsible for the instantiation? I can see
in the source code where the root rule node is created but I can't
quite see where all the others are!
And a closely related question: where's the starting point for the
whole layout process? That is, when at least the initial portion of a
webpage and all auxiliary files (i.e. external stylesheets) have been
loaded, what's the source file/code that determines what happens next?
I tried to get there from the function main() but needless to say I
got a little bit lost!
Finally a bit of a broad question: say you had a magic wand and you
could rewrite the whole presentation architecture without asking
anybody, including rewriting the DOM and CSSOM specifications the way
you'd like them. What would you change? How would you simplify them?
Thank you again!
Manu
The former happens in nsRuleNode::Transition; that's called while
computing the right rulenode for a new nsStyleContext in nsStyleSet.
Style contexts are instantiated by whoever feels like getting the style
for some node; the most common case is nsCSSFrameConstructor.
nsStyleSet is where all such calls end up.
> And a closely related question: where's the starting point for the
> whole layout process? That is, when at least the initial portion of a
> webpage and all auxiliary files (i.e. external stylesheets) have been
> loaded, what's the source file/code that determines what happens next?
> I tried to get there from the function main() but needless to say I
> got a little bit lost!
Does https://developer.mozilla.org/en/The_life_of_an_HTML_HTTP_request
help a bit? It's a little out of date, but correct in broad strokes if
you ignore the nsIRenderingContext part.
-Boris
Thank you!
> Doeshttps://developer.mozilla.org/en/The_life_of_an_HTML_HTTP_request
> help a bit? It's a little out of date, but correct in broad strokes if
> you ignore the nsIRenderingContext part.
Yes it does, thank you very much!
Manu