This defines a class CSSVariableValues which is used to store
computed variable values. We store them a bit differently from
CSSVariableDeclarations -- here we have a hash table of variable names
to integer IDs, and then an array of variables where the array index
is the ID. This is because later on we'll want a stable order for the
variables to return from DOM APIs.
In addition to the string value of the variable, we store the type
of the first and last token of the variable value. This information
will be used when resolving entire variable reference containing
values, to determine when to insert "/**/" before and after a resolved
var(blah) token.
We add a CSSVariableValues member to nsStyleVariables.
This adds an enum to nsCSSScanner.h that represents the types of tokens
we need to consider when pasting together two adjacent tokens during
serialization or variable resolution. For example with:
var-a:orange;
var-b:red;
color:var(a)var(b);
we need to generate the string "orange/**/red" to parse for the value of
'color'.
This adds a CSSVariableDeclarations object to nsRuleData and adds a
MapRuleInfoInto function to CSSVariableDeclarations so the can copy
variable declarations into a nsRuleData's object. We call that from
Declaration::Map{Normal,Important}RuleInfoInto.
We make HasImportantData return true if we have important variables
but no important non-custom properties on a declaration, since that
is used to determine whether we have a rule node for important
declarations. This means MapImportantRuleInfoInto can no longer
assume that mImportantData is non-null.
This adds an nsStyleVariables on which computed variable values
will be stored. We don't actually have any properties assigned to
nsStyleVariables; eCSSPropertyExtra_Variables which we added earlier
isn't a real property. To avoid compiler errors for gVariableFlags
being a zero length array, we stick a dummy entry in there.
nsRuleNode::ComputeVariablesData does nothing for the moment.
nsStyleVariable nsChangeHint calculations always return 0, as later
we will compare the actual properties that reference variables to
see what changes are required for them.
This bumps up nsStyleContext::mBits to a uint64_t so that it can fit
another style struct. If we're going to need to keep at least 27 style
structs, it might be better to split mBits up into two uint32_ts: one
for the flags and one for the style struct bits.
Patch co-authored by Emmanuele Bassi <ebassi@gmail.com>
This defines a CSSVariableDeclarations class that holds a set of
variable declarations. This is at the specified value stage, so values
can either be 'initial', 'inherit' or a token stream (which is what you
normally have). The variables are stored in a hash table. Although
it's a bit of a hack, we store 'initial' and 'inherit' using special
string values that can't be valid token streams (we use "!" and ";").
Declaration objects now can have two CSSVariableDeclarations objects
on them, to store normal and !important variable declarations. So that
we keep preserving the order of declarations on the object, we inflate
mOrder to store uint32_ts, where values from eCSSProperty_COUNT onwards
represent custom properties. mVariableOrder stores the names of the
variables corresponding to those entries in mOrder.
We also add a new nsCSSProperty value, eCSSPropertyExtra_variable, which
is used to represent any custom property name.
nsCSSProps::LookupProperty can return this value.
The changes to nsCSSParser are straightforward. Custom properties
are parsed and checked for syntactic validity (e.g. "var(a,)" being
invalid) and stored on the Declaration. We use nsCSSScanner's
recording ability to grab the unparsed CSS string corresponding to
the variable's value.
