Since we cannot parse and discard a white space token after the ':' in a
custom property declaration, we instead explicitly skip over it when
parsing a non-custom property's value.
This adds support for custom properties on the remainder of the
CSSStyleDeclaration methods.
A shorthand that was specified using a variable reference is serialized
to its originally specified value, rather than by concatenating the
serializations of its longhand components.
A shorthand that was not specified using a variable references but which
has a component longhand that was is serialized to the empty string.
This adds CSS parser error reporting for parsing of custom properties
and normal properties that have variable references.
When re-parsing a normal property that had a variable reference, we
report any parse error to be at the beginning of the property value.
This is because it is difficult to keep track of where exactly each
variable substitution came from to point to the particular value
that would have caused the parse error. For example, with this:
:root {
var-a: 1px 2px;
var-b: 3px var(a);
}
p {
margin: var(a) var(b);
}
we would end up resolving the value of 'margin' to:
" 1px 2px 3px 1px 2px"
In this string, the parse error occurs when we encounter the final
"2px", but by this point we don't know where that value came from.
So instead we just point to the line on which 'margin' was declared.
We extend ErrorReporter with an OutputError overload that takes the
specific line and column number to use in the error report to get this
right, and we store the line and column number for each token stream
we parse on the nsCSSValueTokenStream object.
This re-parses property values at computed value time if
they had a specified value that was a token stream. We add
a function nsRuleNode::ResolveVariableReferences that looks
at all the values in the nsRuleData and calls in to a new
nsCSSParser::ParsePropertyWithVariableReferences function if they have a
token stream value.
We add a nsCSSExpandedDataBlock::MapRuleInfoInto function that will
take the re-parsed property value and copy it back into the nsRuleData.
nsRuleNode::ResolveVariableReferences returns whether any variables
were attempted to be resolved, so that nsRuleNode::WalkRuleTree wil
recompute the rule detail in case any became 'inherit'.
This adds a new eCSSUnit_SharedList type for nsCSSValue, which is a
reference counted object that contains an nsCSSValueList. We need this
so that nsStyleDisplay::mSpecifiedTransform can hold a strong reference
to a specified transform list value. When 'transform' is specified
using a variable reference, the resulting nsCSSValue does not stick
around in the Declaration object, so we wouldn't be guaranteed that
it lives long enough for nsStyleDisplay to keep referencing it.
This adds functionality to nsCSSParser to recognise properties with
variable references and store their recorded token stream as an
eCSSUnit_TokenStream nsCSSValue.
This stores on the nsCSSParser whether we are somewhere in the middle
of parsing an @supports condition. Because @supports condition parsing
uses the scanner recording function (to save its conditionText), and
variable reference containing values also need it, we can't do both at
once. Luckily, if we're parsing an @supports condition, we don't really
need to store the token stream text; we only need to know if it was
valid, and we don't need its actual value later. So we use this flag
later to see if we can skip turning on scanner recording while parsing
variable reference containing values.
This adds functions to nsCSSParser and nsCSSScanner that let us save the
current input position (and corresponding information like line/column
number) and parser pushback, and be able to restore it later. We'll use
this when rewinding the scanner after we first encounter a property with
a variable reference and go back to reparse it as a token stream.
We add a new class CSSVariableResolver whose job is to take the
inherited computed variables and the specified variable declarations and
to perform cycle removal and resolution of the variables, storing the
result in the CSSVariableValues object on an nsStyleVariables. We use
CSSVariableResolver in nsRuleNode::ComputeVariablesData.
The variable resolver does this:
1. Asks the CSSVariableValues and CSSVariableDeclarations objects
to add their variables to it.
2. Calls in to a new nsCSSParser function
EnumerateVariableReferences that informs the resolver which
other variables a given variable references, and by doing so,
builds a graph of variable dependencies.
3. Removes variables involved in cyclic references using Tarjan's
strongly connected component algorithm, setting those variables
to have an invalid value.
4. Calls in to a new nsCSSParser function ResolveVariableValue
to resolve the remaining valid variables by substituting variable
references.
We extend nsCSSParser::ParseValueWithVariables to take a callback
function to be invoked when encountering a variable reference. This
lets EnumerateVariableReferences re-use ParseValueWithVariables.
CSSParserImpl::ResolveValueWithVariableReferences needs different
error handling behaviour from ParseValueWithVariables, so we don't
re-use it.
CSSParserImpl::AppendImpliedEOFCharacters is used to take the
value returned from nsCSSScanner::GetImpliedEOFCharacters while
resolving variable references that were declared using custom
properties that encountered EOF before being closed properly.
The SeparatorRequiredBetweenTokens helper function in nsCSSParser.cpp
implements the serialization rules in CSS Syntax Module Level 3:
https://dvcs.w3.org/hg/csswg/raw-file/3479cdefc59a/css-syntax/Overview.html#serialization
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.
* * *
bug 798843 - recompile svg.woff font to pick up the updated glyph definitions
* * *
bug 798843 - update property_database.js to match the new property names
* * *
bug 798843 - recompile svg.woff font to pick up the updated glyph definitions
* * *
bug 798843 - update property_database.js to match the new property names
