layout/style/nsIStyleRuleProcessor.h@8bccb770b82d
layout/style/nsIStyleRuleProcessor.h
Wed, 31 Dec 2014 13:27:57 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Wed, 31 Dec 2014 13:27:57 +0100
- branch
- TOR_BUG_3246
- changeset 6
- 8bccb770b82d
- permissions
- -rw-r--r--
Ignore runtime configuration files generated during quality assurance.
1 /* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
2 /* This Source Code Form is subject to the terms of the Mozilla Public
3 * License, v. 2.0. If a copy of the MPL was not distributed with this
4 * file, You can obtain one at http://mozilla.org/MPL/2.0/. */
6 /*
7 * internal abstract interface for containers (roughly origins within
8 * the CSS cascade) that provide style rules matching an element or
9 * pseudo-element
10 */
12 #ifndef nsIStyleRuleProcessor_h___
13 #define nsIStyleRuleProcessor_h___
15 #include "mozilla/MemoryReporting.h"
16 #include "nsISupports.h"
17 #include "nsChangeHint.h"
19 struct RuleProcessorData;
20 struct ElementDependentRuleProcessorData;
21 struct ElementRuleProcessorData;
22 struct PseudoElementRuleProcessorData;
23 struct AnonBoxRuleProcessorData;
24 #ifdef MOZ_XUL
25 struct XULTreeRuleProcessorData;
26 #endif
27 struct StateRuleProcessorData;
28 struct PseudoElementStateRuleProcessorData;
29 struct AttributeRuleProcessorData;
30 class nsPresContext;
32 // IID for the nsIStyleRuleProcessor interface
33 // {c1d6001e-4fcb-4c40-bce1-5eba80bfd8f3}
34 #define NS_ISTYLE_RULE_PROCESSOR_IID \
35 { 0xc1d6001e, 0x4fcb, 0x4c40, \
36 {0xbc, 0xe1, 0x5e, 0xba, 0x80, 0xbf, 0xd8, 0xf3} }
39 /* The style rule processor interface is a mechanism to separate the matching
40 * of style rules from style sheet instances.
41 * Simple style sheets can and will act as their own processor.
42 * Sheets where rule ordering interlaces between multiple sheets, will need to
43 * share a single rule processor between them (CSS sheets do this for cascading order)
44 *
45 * @see nsIStyleRule (for significantly more detailed comments)
46 */
47 class nsIStyleRuleProcessor : public nsISupports {
48 public:
49 NS_DECLARE_STATIC_IID_ACCESSOR(NS_ISTYLE_RULE_PROCESSOR_IID)
51 // Shorthand for:
52 // nsCOMArray<nsIStyleRuleProcessor>::nsCOMArrayEnumFunc
53 typedef bool (* EnumFunc)(nsIStyleRuleProcessor*, void*);
55 /**
56 * Find the |nsIStyleRule|s matching the given content node and
57 * position the given |nsRuleWalker| at the |nsRuleNode| in the rule
58 * tree representing that ordered list of rules (with higher
59 * precedence being farther from the root of the lexicographic tree).
60 */
61 virtual void RulesMatching(ElementRuleProcessorData* aData) = 0;
63 /**
64 * Just like the previous |RulesMatching|, except for a given content
65 * node <em>and pseudo-element</em>.
66 */
67 virtual void RulesMatching(PseudoElementRuleProcessorData* aData) = 0;
69 /**
70 * Just like the previous |RulesMatching|, except for a given anonymous box.
71 */
72 virtual void RulesMatching(AnonBoxRuleProcessorData* aData) = 0;
74 #ifdef MOZ_XUL
75 /**
76 * Just like the previous |RulesMatching|, except for a given content
77 * node <em>and tree pseudo</em>.
78 */
79 virtual void RulesMatching(XULTreeRuleProcessorData* aData) = 0;
80 #endif
82 /**
83 * Return whether style can depend on a change of the given document state.
84 *
85 * Document states are defined in nsIDocument.h.
86 */
87 virtual bool
88 HasDocumentStateDependentStyle(StateRuleProcessorData* aData) = 0;
90 /**
91 * Return how (as described by nsRestyleHint) style can depend on a
92 * change of the given content state on the given content node. This
93 * test is used for optimization only, and may err on the side of
94 * reporting more dependencies than really exist.
95 *
96 * Event states are defined in mozilla/EventStates.h.
97 */
98 virtual nsRestyleHint
99 HasStateDependentStyle(StateRuleProcessorData* aData) = 0;
100 virtual nsRestyleHint
101 HasStateDependentStyle(PseudoElementStateRuleProcessorData* aData) = 0;
103 /**
104 * This method will be called twice for every attribute change.
105 * During the first call, aData->mAttrHasChanged will be false and
106 * the attribute change will not have happened yet. During the
107 * second call, aData->mAttrHasChanged will be true and the
108 * change will have already happened. The bitwise OR of the two
109 * return values must describe the style changes that are needed due
110 * to the attribute change. It's up to the rule processor
111 * implementation to decide how to split the bits up amongst the two
112 * return values. For example, it could return the bits needed by
113 * rules that might stop matching the node from the first call and
114 * the bits needed by rules that might have started matching the
115 * node from the second call. This test is used for optimization
116 * only, and may err on the side of reporting more dependencies than
117 * really exist.
118 */
119 virtual nsRestyleHint
120 HasAttributeDependentStyle(AttributeRuleProcessorData* aData) = 0;
122 /**
123 * Do any processing that needs to happen as a result of a change in
124 * the characteristics of the medium, and return whether this rule
125 * processor's rules have changed (e.g., because of media queries).
126 */
127 virtual bool MediumFeaturesChanged(nsPresContext* aPresContext) = 0;
129 /**
130 * Report the size of this style rule processor to about:memory. A
131 * processor may return 0.
132 */
133 virtual size_t SizeOfExcludingThis(mozilla::MallocSizeOf mallocSizeOf) const = 0;
134 virtual size_t SizeOfIncludingThis(mozilla::MallocSizeOf mallocSizeOf) const = 0;
135 };
137 NS_DEFINE_STATIC_IID_ACCESSOR(nsIStyleRuleProcessor,
138 NS_ISTYLE_RULE_PROCESSOR_IID)
140 #endif /* nsIStyleRuleProcessor_h___ */
