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