Confirm, emeritus
969
edits
Changes
Update for the nsStyleContext -> ComputedStyle rename
The computed style data for an element/frame are exposed to the rest of
Gecko through a the classmozilla::ComputedStyle (previously calledcalled nsStyleContext). Rather than having a member variable for each
CSS property, it breaks up the properties into groups of related
properties called style structs. These style structs obey the rule that
properties; we call these inherited structs) or all are not inherited by
default (we call these reset structs). Separating the properties in
this way improves the ability to share the structs between similar stylecontexts ComputedStyle objects and reduce the amount of memory needed to store the style data.The nsStyleContext ComputedStyle API exposes a method for getting each
struct, so you'll see code like
<code>sc->GetStyleText()->mTextAlign</code> for getting the value of the
text-align CSS property. (Frames (see the Layout section below) also
have the same
GetStyle* methods, which just forward the call to the frame's stylecontextComputedStyle.)
The style contexts ComputedStyles form a tree structure, in a shape somewhat like thecontent tree (except that we coalesce identical sibling style contextsComputedStyles
rather than keeping two of them around; if the parents have been
coalesced then this can apply recursively and coalasce cousins, etc.;
we do not coalesce parent/child style contextsComputedStyles).The parent of a style context ComputedStyle has the style data that the style contextComputedStyle
inherits from when CSS inheritance occurs. This means that the parent
of the style context ComputedStyle for a DOM element is generally the style contextComputedStyle
for that DOM element's parent, since that's how CSS says inheritance
works.
pointer to a rule, but since a rule may appear in many sequences, there
are sometimes many rule nodes pointing to the same rule. Once we have
this list we create a style context ComputedStyle (or find an appropriate existing
sibling) with the correct parent pointer (for inheritance) and rule node
pointer (for the list of rules), and a few other pieces of information
depend on inherited values or on data from other style structs, then we
can cache it in the rule tree (and then reuse it, without recomputing
it, for any style contexts ComputedStyles pointing to that rule node). Otherwise, westore it on the style context ComputedStyle (in which case it may be sharedwith the style contextComputedStyle's descendant style contextsComputedStyles).
This is where keeping inherited and
non-inherited properties separate is useful: in the common case of
relatively few properties being specified, we can generally cache the
non-inherited structs in the rule tree, and we can generally share the
inherited structs up and down the style context ComputedStyle tree.
The ownership models in style sheet structures are a mix of reference
counted structures (for things accessible from script) and directly
owned structures. Style contexts ComputedStyles are reference counted, and own their
parents (from which they inherit), and rule nodes are garbage collected
with a simple mark and sweep collector (which often never needs to run).
